Who can your AI actually reach?
Every person who connects a business tool to their own AI creates an access path that nobody is tracking. It sits outside your identity provider, outside your offboarding checklist, and outside any inventory you could produce if an auditor asked. This is what that costs, and what fixing it structurally looks like.
The access path nobody created on purpose.
Nobody decided to do this. It accumulated. Someone connected a CRM to Claude to save an afternoon, someone else pointed ChatGPT at a shared drive, and it worked well enough that it never became a decision anyone had to make. The connections were made by individual people, under individual accounts, one at a time.
That is why the record does not exist. Your identity provider knows who has a seat. It does not know which of those people handed an AI a token to your customer database.
Verizon's 2026 Data Breach Investigations Report found frequent AI use by employees rose from 15% to 45% in a single year, and now ranks shadow AI, meaning employees using unapproved AI tools at work, as the third most common non-malicious data-leakage activity (Verizon, 2026). The tools in that path are usually approved. The path is not.
Four ways ungoverned access goes wrong.
These look like four problems. They are one problem, seen at four moments in an employment lifecycle.
Revoke sprawl
Their AI still holds a live login to your CRM. The connection was made by them, under their account, so your offboarding checklist never saw it. You revoked the SSO seat. You did not revoke the thing the seat authorized.
Onboarding drag
A new hire waits days for tool access. Eventually somebody grants more than the role needs, because doing it properly means thirteen separate consoles and doing it fast means one broad grant.
Contractor over-access
A contractor needs one system for one project. The only grant available is all-or-nothing, so they get keys to the stack and you get no record of what they touched.
Least-privilege agents
An autonomous agent runs on a person's full OAuth scope, because that was the only way to give it access at all. It now has the reach of a senior employee and the judgment of a program.
Onboarding and offboarding are the same fact seen from two ends.
Most companies treat these as separate problems owned by separate people. They are the same problem. Both are asking: where does access live, and who controls it?
When access lives with the individual, both ends break. Granting means visiting every console in turn, which is slow, so somebody over-grants to save time. Revoking means remembering every console, which is unreliable, so something gets missed. The slowness at one end and the leakage at the other have one cause.
When access lives centrally, both ends collapse into one instruction. We provisioned a teammate into every system he needed in under ten minutes. That is not a feat of tooling. It is the natural consequence of not having thirteen separate places to grant access, and the same structure is what makes revoking reliable.
You cannot revoke what you never centrally granted.
An agent is not a user, and should not borrow one.
The fourth failure is the one that scales worst. When an autonomous agent needs access, the path of least resistance is to run it on a person's credentials. It works immediately. It also means the agent now carries that person's entire reach, indefinitely, without a person watching.
The alternative is to scope the agent to exactly the tools and objects its job needs. One label, one object, nothing more. This is the same discipline as least privilege for humans, applied to something that acts faster and never gets tired.
If you want the implementer's version of this, we wrote up how scoping actually works in practice in the Claude Code MCP scopes reference. It is the mechanics under this argument.
We hold ourselves to it. In the 84 days to 2026-08-09 we promoted fourteen processes into scheduled agents, running 2,423 automated jobs and 25,720 tool calls across 133 tools. Every one of those agents is scoped to its own tools rather than to a human account, because at that volume a borrowed credential stops being a shortcut and becomes the whole risk surface.
What scoped access actually looks like.
Four properties. If your setup has all four, this class of problem mostly stops happening.
- Connections are owned by the company, not the person. The credential belongs to the business. People and agents are granted use of it, never possession.
- Granting is one instruction. If provisioning someone into everything they need is a single act, nobody over-grants to save time.
- Revoking once revokes everywhere. The test is simple: can you name one action that ends all of a departed person's access, including anything their AI holds?
- Agents get their own scope. Never a borrowed human account. The agent's reach should be readable from its job description.
None of this requires banning AI, and attempts to ban it reliably produce more shadow AI rather than less. It requires making the governed path faster than the improvised one.
Common questions
What happens to AI access when an employee leaves?
In most companies, nothing. If the employee connected a tool to their own AI account, that connection lives under their credentials, outside your identity provider, and outside your offboarding checklist. Disabling their SSO seat does not necessarily revoke a token they granted directly. The fix is structural: connections have to live centrally, owned by the company rather than the person, so that revoking once revokes everywhere.
How do you limit what an AI agent can access?
By scoping the agent rather than the human. An agent should be granted the specific tools and the specific objects its job needs, not inherited from whichever person happened to set it up. If your only option is handing the agent a human OAuth scope, the agent has far more reach than its task requires, and nothing in the system knows the difference.
Is this the same as shadow IT?
It rhymes, but the shape is different. Shadow IT was people using unapproved software. This is people connecting approved software to an AI you did not approve, which means the data path is new even when every tool in it is sanctioned. Verizon calls the category shadow AI and now ranks it third among non-malicious data-leakage activity.
Do we have to stop people using AI to fix this?
No, and trying is how you get more shadow AI, not less. The goal is to make the governed path the easy path. When access is central and provisioning takes minutes, people stop building their own connections, because yours is faster than theirs.
Where this sits.
Access is one of four things that break when AI reaches business tools with nothing in between. The other three are visibility, consistency, and lock-in, and they share a cause. How we work covers all four and what one layer in the gap fixes.
Related reading: bring your own agent on why the governance layer matters more than the agent you pick, and for agencies if your version of this problem is contractor churn across many clients.
Want to know what your AI can currently reach?
Book thirty minutes. We will walk your actual connections and tell you what a departing employee would still have access to.