Ask an IT director how many AI agents are operating against their environment and you will usually get a number. Ask how that number was arrived at and the answer is almost always "the ones we set up." That is a different question, and the gap between the two is where the work is.
An agent — whether it is a vendor's assistant wired into your document store, a scheduled job that reads tickets and drafts replies, or something a developer assembled from an SDK on a Thursday — does three things that make it a security subject rather than a feature. It authenticates. It holds credentials over time. It takes actions that leave records. Every other thing in your environment that does those three things is in your directory, has an owner, and shows up in an access review. Agents mostly are not, do not, and do not.
The impersonation problem
The most common way agent access is built is also the most damaging: the agent borrows a human's identity.
It starts reasonably. A connector needs to read a user's mail or their files, so it uses an OAuth flow and gets a token on that user's behalf. Fine — that is what delegated access is for. The trouble arrives when the same pattern is used for an agent that is not acting for one person at one moment, but running continuously, for many people, on a token granted once by someone who has since changed roles.
Three things break at once.
Your logs lie. The audit trail says a person read those documents. A reviewer cannot tell whether a human opened a file or a scheduled process enumerated ten thousand of them. Incident response depends on answering that, and now you cannot.
Your least-privilege work is undone. The agent inherits everything the human can reach, which is a far wider set than the agent needs. You spent real effort scoping that person's access to their role. The agent operates at the full extent of it, and then keeps operating at the full extent of it after the person moves to a different team.
Deprovisioning does not deprovision. The human leaves. The account is disabled. Either the agent stops working for reasons nobody can diagnose, or — worse — the refresh token keeps working and you have a live credential belonging to a former employee.
Connectors are grants, not features
The same reasoning applies to the connectors that link an assistant to your systems, including MCP servers. The interface makes them look like plugins. In access terms they are nothing of the sort: enabling one establishes a standing authorization for software to reach a system on someone's behalf, until somebody revokes it.
That deserves the process any standing grant gets. Which means, concretely:
- A named owner. A person, not a team alias, who is accountable for the connector continuing to exist.
- A scope written down before it is enabled. Which systems, which operations, read or write. "Access to SharePoint" is not a scope. "Read-only, to these three document libraries" is.
- An expiry. Grants that never expire become permanent by default. Grants that expire get renewed by someone who has to look at them.
- Admin consent, not user consent. If an individual can authorize a third-party application against organizational data from a dialog box, your access policy is being set by whoever clicks fastest. This is a setting in every major identity platform, and turning it on is one of the highest-value afternoons available to a mid-market IT team.
What to do instead
Give agents their own identities.
Every agent gets a distinct service principal or workload identity in the same directory that governs your people. It is scoped to exactly the resources that particular agent needs — not the union of what its users can reach. It authenticates with short-lived, workload-bound credentials rather than a long-lived secret in a configuration file. And it appears in your access reviews next to everything else, so that when nobody can explain what it does, it gets removed.
None of this requires a new platform. For most organizations in the 500-to-3,000 user range, the identity provider you already pay for does all of it. What is missing is not capability. It is the decision that agent enrollment goes through the same door as everything else, made early enough that the first agent sets the pattern rather than the exception.
The alternative is the situation many organizations are already in: a set of integrations that work, that nobody can fully enumerate, each holding credentials of unknown scope, granted by people who may no longer be here.
The sequencing point
There is a version of this argument that says: fix identity first, then adopt AI. That is not what I am arguing, and organizations that try it never start.
The point is narrower. Whatever you do first — a pilot, a connector, an assistant for one department — do it through an identity you can name, scope and revoke. That single constraint costs almost nothing on the first project and saves you the retrofit on the twentieth. Identity is the only control that spans your cloud services, your on-premises systems and every agent that talks to either.
Make it the control plane before you have twenty agents. Not after.