In nearly every company that adopted an AI assistant in the last two years, there's an account named something like "AI-finance" or "bot-support," with a password that circulates over chat between whoever needs to use it. Nobody decided this formally. It happened because setting up an individual login for each person felt like too much work for a tool that was "just a trial."
The problem is that stolen identity isn't a hypothetical risk — according to IBM's threat intelligence index, it's the attacker's preferred way in. IBM X-Force's 2025 report found that identity abuse was responsible for 30% of incidents recorded in 2024, alongside a booming underground market for stolen credentials.
A password shared by several people, with no individual owner, is exactly the kind of credential that market values most: broad reach, concentrated use, nobody noticing quickly when it leaks.
The habit nobody questions
The logic behind the shared account is seductive: create one login, hand out the password to whoever needs it, move on. The cost of that choice only shows up later, and almost always at the worst possible moment.
According to IBM, the top five credential-stealing programs — so-called infostealers — logged more than 8 million credential listings for sale on the dark web in a single year, a 12% jump from the year before. Each listing can bundle hundreds of credentials in practice, making the real volume even larger than the already-high headline number.
A compromised personal credential affects one person and a known set of systems. A compromised shared credential affects everyone who uses it, all at once, and nobody can say for certain how many people that really includes — because the list of who "has the password" almost never exists in writing, only in the memory of whoever passed it along.
There's a second, quieter effect too. When several people use the same account, the same password tends to resurface elsewhere: pasted into a personal password manager, reused on some other service, typed on a machine that isn't the work computer. Each of those copies is one more leak point, and none of them show up in any company security inventory — because, officially, that password "only exists" inside the AI tool.
Why stolen identity is the attacker's favorite target
Verizon publishes one of the most respected annual studies of how data breaches actually happen, drawn from thousands of real investigated incidents. For nineteen straight years, the most common way in was always the same: a stolen credential. That changed only in the most recent edition, published in May 2026: for the first time, exploiting system flaws overtook stolen credentials as the most common way to break in, accounting for nearly a third of all breaches analyzed.
The right way to read that shift isn't "stolen credentials stopped being a problem." It's the opposite: according to the report itself, stolen credentials are now so easy to buy ready-made on the underground market that, in many cases, an attacker no longer needs to break in at all — they simply purchase access from a broker who specializes in reselling compromised accounts. Exploiting flaws grew because attackers made it faster using AI of their own; credentials still fuel the next stage of a large share of those attacks, especially the ones that end in ransomware.
And the cost of ignoring this keeps rising, not falling. According to IBM, the global average cost of a data breach hit $4.99 million in 2026, and breaches that involved some malicious use of AI by the attacker cost $6 million on average — about a million dollars more than the overall average. An AI account with a shared password, with no identity behind it at all, is a particularly attractive target precisely because nobody watches it the way they'd watch an executive's account.
Add to that a detail that rarely makes it into the conversation: a generic account is also harder to defend afterward. If a security analyst has to decide, in the middle of an incident investigation, whether suspicious activity came from legitimate use or an intruder, an account with individual identity gives an answer in minutes. An account shared by six people, with no record of who was logged in at any given moment, turns that same question into a guessing game.
What has to be in place
Fixing this isn't about writing one more password policy. It's about changing where the agent's identity comes from in the first place.
Sign-in with corporate identity, sourced from the company directory. Instead of a one-off account created just for the AI tool, access is born from the same directory that already controls email and internal systems. The person signs in with their own network login — not a new password to memorize and pass around.
A personal credential per connected tool. Each person who uses an integration — a payment system, a spreadsheet, a support platform — uses their own credential inside that tool, not a generic key borrowed hand to hand. What the agent can do on someone's behalf is limited to what that specific person can do.
Access scoped to each person's role. Nobody gets the entire tool just because they needed one function of it. If an integration has thirty functions and someone's routine uses two, those are the two that get unlocked.
Offboarding that propagates instantly. When someone leaves the company and loses access in the corporate directory, that same cut reaches the AI at the same moment — with no separate "who had the password" list that someone has to remember to update on the side.
This is why Skyller was built with federation to the company directory from day one: identity comes from a single place, and leaving that place means leaving everything, the AI included.
What changes day to day for the team
In practice, swapping the shared account for individual identity tends to feel less disruptive than it sounds. The person signs in with the same login they already use for everything else — one less step, not one more. What changes is what gets recorded behind the scenes: every action the agent takes carries the name of who asked for it, instead of dissolving into "someone on the team, not sure who."
This also fixes a problem every IT department has lived through without realizing it was the same problem: someone leaves the company, and months later it turns out they could still get into a tool because that account's password was never rotated — it just got "forgotten" when handoffs happened. With identity sourced from the corporate directory, that kind of late discovery stops happening, because there's no hidden second list for anyone to forget.
Three questions to bring to your next meeting
Before assuming the team is covered, it's worth putting three concrete questions to IT about every AI tool in use:
- If we asked right now who has access to this AI account, is there an up-to-date list — or does the answer come back as "a few people on the team"? If it's the second, the real control doesn't exist, only the impression of it.
- When this account does something sensitive, what authorization is that based on? If the answer points to a shared password rather than a specific person with a defined role, there's no way to safely answer "who authorized this."
- If one of these people left the company tomorrow, would their access to this AI tool drop with them — or would it keep working until someone remembered to change the password? If it's the second, that's the next incident waiting to happen, not a theoretical risk.
