Every production agent needs to authenticate as something. Most teams answer that question in an afternoon: spin up a service account, hand it the same permissions the human user has, move on to the actual agent logic. That decision is quietly becoming the biggest security liability in the deployment. Not the prompt. Not the model. The credential.
The ratio problem nobody budgeted for
Non-human identities already outnumber human ones inside most enterprises by a wide margin. A recent analysis of 27 million enterprise NHIs found a ratio of 144 to 1. That number alone should change how you think about identity, but the more revealing figure is governance maturity: only about 22% of organizations treat agents as independent identity principals. The rest bolt agent access onto an existing human account and hope nobody notices the difference between a person clicking through a UI once a minute and an agent looping through API calls a thousand times a minute.
This isn't a hypothetical gap. It's the default state of most agent deployments running today, including plenty that have already shipped to production. The identity model was never designed for a principal that acts autonomously, in bursts, without a human in the loop confirming each step.
Why the service-account shortcut feels safe and isn't
Most authorization models assume a human completing tasks one at a time, with a human's judgment gating each action. When you attach an agent to that same model, you inherit all of its assumptions while removing the thing that made those assumptions tolerable: a person deciding, in the moment, whether an action is a good idea.
The path of least resistance looks like this: full-scope tokens, inherited permissions, standing service accounts that never expire. The agent gets access to everything the human could touch, because scoping it down looked like extra work with no clear payoff. Then the agent's task list grows. Someone adds a new tool. Someone points it at a new data source. Nobody revisits the token, because revisiting the token was never anyone's job.
A broad-scope agent token that lets the agent do anything the user could do is a least-privilege violation even when the agent's current task is completely benign.
That's the framing practitioners have converged on, and it matters because it separates the security question from the behavior question. You don't need the agent to misbehave for the setup to be wrong. The exposure exists the moment the token is broader than the task, independent of whether anything bad ever happens with it. Most teams only notice this after an incident, a compromised dependency, a leaked key, a prompt injection that convinces the agent to call a tool it technically had permission for. The permission was the mistake, not the trigger.
What the fix actually looks like
Microsoft published a Pattern & Practice guide on least privilege for agents a few weeks ago, and it's worth reading not for the branding but for the framing: this is treated as an architecture problem with a concrete checklist, not a policy memo asking teams to be more careful. The checklist closes four specific gaps:
- Ownership: every agent identity has a named human or team accountable for it, not a shared account nobody owns
- Scope: the agent's credential covers only the actions its current task requires, not everything its parent system could do
- Tool allowlists: the agent can call a defined, reviewed set of tools, and nothing outside that set resolves
- Fast revocation: access can be pulled immediately, without waiting on a deploy cycle or a support ticket
None of this is novel security theory. It's the same least-privilege discipline that's existed for service-to-service auth for a decade. What's new is that it's being applied explicitly to agents, as their own category, instead of being inherited implicitly from whatever human or system account they were bootstrapped from.
OAuth already has the mechanism, most teams just aren't using it
The interesting infrastructure development this year isn't a new protocol, it's the repurposing of an existing one. RFC 8693, OAuth Token Exchange, was designed for exactly this problem: swapping a broad credential for a narrow, short-lived token scoped to a specific task. An agent doesn't need to hold the same standing credential for its entire lifecycle. It needs to request a token scoped to the task in front of it, use it, and let it expire.
This is the mechanism underneath the MCP authorization spec, developed as a collaboration involving Anthropic, Arcade.dev, Microsoft, Okta and Auth0, among others. The spec defines OAuth-based audience binding through Resource Indicators (RFC 8707) and delegation through Token Exchange (RFC 8693). Practically, that means a client can request a token that's bound to a specific resource server and scoped to a specific delegated action, instead of a single API key that works everywhere the agent might ever need to go.
For a team building agents against MCP servers, this is the difference between one API key that unlocks the whole toolbox and a set of narrow, expiring grants issued per task. The second pattern costs more to set up. It also means a compromised or misbehaving agent can only do damage within the boundary of whatever task it was mid-execution on, not everything it was ever capable of doing.
Shadow agents are now a documented category, not an edge case
Identity is only half the problem. The other half is discovery: knowing which agents exist at all. A 2026 NHI Reality Report found that 78% of organizations have no documented policy for creating or removing AI identities. That number implies something specific: agents are being spun up by individual teams, given credentials by whoever had admin access at the time, and left running with no central registry tracking them.
This has produced a new product category in the last few weeks: shadow-agent discovery tools that scan for agents, MCP servers, and exposed credentials that were adopted informally and never folded into governance. The pitch is blunt because the problem is blunt. Security teams don't know what agents are running in their own environment, what they can touch, or who approved them. That's not a tooling gap you close with better prompts or a smarter model. It's an inventory problem, and inventory problems only get solved by someone actually building the inventory.
Audit trails as compliance infrastructure, not a debugging nicety
The last piece of this discipline is the one most teams skip until a client or regulator asks for it directly: proving after the fact what an agent did. Emerging guidance defines an AI agent audit trail as a chronological record of every action an agent takes, including file operations, API calls, and reasoning steps, kept for accountability and compliance documentation, not just for debugging a failed run.
That's a meaningfully higher bar than the logging most agent stacks ship with today. Application logs tell you what happened. An audit trail has to tell you what the agent was authorized to do, what credential it used, what it actually did, and why it decided to do it, all tied back to a specific identity and a specific delegated scope. If your agent is running under one shared service account, you can't answer that question cleanly even if you have perfect logs, because the logs can't distinguish one task from another when they all ran under the same credential.
What this looks like in a real build
In practice, the pattern that holds up under scrutiny is narrower than most teams start with. Each agent gets its own identity, not a shared account. Credentials are short-lived and scoped to the task at hand, issued through token exchange rather than handed out as standing API keys. Tool access is an explicit allowlist tied to that identity, reviewed when the agent's responsibilities change, not left open by default. And every action the agent takes is attributable, after the fact, to a specific identity, a specific scope, and a specific reason, without having to reconstruct it from application logs that weren't built for that purpose.
None of this is exotic. It's the same discipline that service-to-service architectures adopted years ago, applied to a new kind of principal that acts with less human oversight and at higher velocity than anything that came before it. The teams that treat agent identity as its own line item, distinct from the model, the prompt, and the tool architecture, are the ones who won't be scrambling to explain what an agent had access to after something goes wrong. The teams that don't will find out the hard way that a service account with full scope was never really