A pattern is now common across enterprise deployments: an AI agent is given a task, and to complete it, the agent uses someone’s credentials. Sometimes it is the developer’s API key left in a configuration file. Sometimes it is an OAuth token minted for a user and copied into the agent’s runtime. Sometimes it is a shared service account that several systems quietly depend on. In each case the agent is authenticating as something it is not, and every downstream control inherits that fiction.
The immediate attraction is obvious. Borrowed credentials work. The agent reaches the systems it needs without a new integration, a new registration or a change request. The cost is deferred and structural.
Why impersonation breaks the audit story
Authentication answers who is acting. Authorisation answers what they may do. Borrowing a credential collapses the two. When an agent uses a human token, the resource sees a legitimate user with legitimate rights and no reason to question the request. Logs attribute the action to the sponsor. Behavioural analytics baseline it against human patterns until the agent’s machine-speed volume becomes indistinguishable from a compromised account, at which point genuine incidents are buried in expected noise. Least privilege becomes unenforceable because the agent’s effective permission set is whatever the lender happened to possess.
The harder problem: long-lived tokens travel
Tokens are bearer instruments. Anyone holding one is treated as entitled to it. An agent that stores a user’s refresh token in a vector store, a prompt context, a log or a memory file has created a copy of standing authority that no revocation process is designed to catch. Revoking the user’s session does not necessarily invalidate the agent’s copy. Removing the agent from the deployment does not necessarily remove the token. In agentic architectures, where intermediate components pass context between models, tools and retrieval stores, the surface for token sprawl is larger than in any previous generation of automation.
Delegation done properly
The alternative is explicit, scoped delegation. The user consents to a specific agent acting for a specific purpose, and the authorisation server issues a credential that carries both facts rather than a copy of the user’s rights. Token exchange standards, including the OAuth on-behalf-of pattern standardised in RFC 8693, allow a service to present a subject token and receive a downstream token whose scope is narrowed to the intended call. Cross-application access profiles extend the same logic to third-party applications, giving the target service a verifiable statement of who the agent represents and what it was asked to do, without granting broad standing access.
Practical migration steps
Start by finding the borrowing. Instrument outbound calls and flag any credential used by an automated component that was issued to a person or shared across services. That list is usually longer than expected. Second, register agents as first-class identities with owners, purposes and expiry. Third, replace static secrets with runtime issuance so that access is measured in minutes rather than months. Fourth, constrain what the agent can do with the authority it holds: irreversible actions, bulk exports and privilege changes are the ones worth gating. Fifth, make revocation testable, so that disabling an agent demonstrably ends its access everywhere rather than merely stopping its process.
The uncomfortable part is cultural. Borrowed credentials persist because they remove friction from teams under pressure to demonstrate value, and because the risk they create materialises later, somewhere else, attributed to someone else. Fixing it means slowing a deployment to establish who the agent is, which is exactly the conversation most programmes would rather postpone.