An AI agent built to summarize expense reports doesn't need to see payroll data. Most enterprises give it access anyway. Nobody sat down and decided the agent should reach payroll. It got wired into a shared service account during a sprint, or it inherited whatever permissions the engineer who built it happened to hold, or it connected to a database through a tool nobody bothered to scope down.
The access accumulated on its own, and now it sits there, unused most of the time, waiting for the one prompt injection or the one compromised session that turns it into a real problem. This is over-permissioning, and it has quietly become the default condition of enterprise AI. Gartner puts the ratio of machine identities to human identities at 82 to 1, and the vast majority of those machine identities, agents included, launch with far more access than their actual job requires.
Security teams have a name for the habit that causes this: provisioning "just in case," so nobody has to file a ticket six weeks from now when the agent needs one more table or one more endpoint. It's a reasonable shortcut for a static application. For an autonomous agent that can chain tool calls, retrieve documents, and act without a human reviewing each step, it's a standing liability.
Solving this takes more than a stricter provisioning checklist. It takes a model of access control designed for identities that act on their own, act on behalf of someone else, and change what they're doing several times within a single session. Here's what that model actually requires.
Why agents end up over-permissioned in the first place
Most agent deployments trace their permission problems back to three habits, and all three feel efficient right up until an incident report proves otherwise.
The first is the shared service account. Instead of giving an agent its own scoped identity, teams route it through a generic API key or a bot account that already has broad database and application access, because that account exists and the alternative means requesting new credentials for every new use case. The agent now carries whatever that account can do, regardless of what the agent was actually built to do.
The second is retrieval that doesn't check the requester. A RAG pipeline pulls whatever documents match the query's embedding, without asking whether the person or agent making the request is authorized to see those specific documents. An engineer's question about deployment timelines can surface a chunk of a document that also contains unreleased financial projections, because the retrieval layer only cares about semantic relevance, not authorization.
The third is unrestricted tool access through MCP. Model Context Protocol has made it trivially easy for an agent to discover and call tools, but discovery and authorization are two different problems. If every tool an agent can technically reach is a tool it's allowed to invoke, you've built a system where the agent's effective permissions are defined by your infrastructure's topology rather than by policy. None of these habits look reckless in isolation.
Together, they explain why an agent quietly ends up capable of far more than its use case demands, and why almost nobody in the organization can say, with confidence, exactly what any given agent can currently touch. Fixing that gap means rethinking access control for autonomous systems from the ground up, rather than patching the provisioning process that created it.
Why the access control you already have doesn't fix this
Traditional identity and access management answers one question well: who is this, and are they allowed to log in? Okta, Entra ID, and Ping Identity all excel at that question. Where legacy identity platforms fall short with agents is the question that actually matters once an agent is inside a session: what is this identity doing right now, and should it be allowed to keep doing it?
That gap shows up clearly with role-based access control. RBAC assigns permissions to a role, and once an identity holds that role, it holds every permission attached to it, for as long as the role assignment exists. An agent granted a "customer support" role gets whatever that role includes, whether it's actively resolving a billing question or has drifted into a task the role was never scoped for.
Attribute-based access control improves on this by factoring in context, department, location, and resource sensitivity, but it still evaluates access at a fixed point, usually when a session opens, rather than continuously as the session unfolds. Comparing role based models against policy driven ones makes it clear why static role assignments break down the moment an agent starts acting instead of just logging in.
Agents break both models because a single session can shift intent multiple times. An agent might start by answering a benign question, then call a tool that queries a database, then hand a result to a second agent that takes a different action entirely. Evaluating authorization once, at login, and treating everything downstream as pre-approved is precisely how an agent ends up doing something nobody would have approved if they'd been asked in the moment.
This is the real distinction between identity management and authorization enforcement. Knowing who an agent is, and knowing what it's currently allowed to do, are separate problems, and closing the second one requires a policy engine that evaluates access at runtime, not just at the door.
The five points where access actually needs to be enforced
If you accept that authorization has to happen continuously rather than once, the next question is where. PlainID's approach, built around what it calls Full-Flow AI Guardrails, breaks an agent's workflow into four distinct control points. Mapping out the guardrails every agent needs starts with recognizing that each one closes a gap the others can't.
The first is the input stage. Before an agent retrieves anything, the system checks whether the category of question being asked is one this identity is authorized to ask at all. An engineer's question about deployment infrastructure gets processed. The same engineer asking for unreleased financial forecasts gets blocked before a single document is touched, because the block happens on intent, not on the content of a response that hasn't been generated yet.
The second is data retrieval itself. Even when a question passes the input check, the documents or database rows an agent pulls back have to be filtered against what the requesting identity can see, before that data ever enters the model's context window. This is the pre-retrieval filtering PlainID emphasizes over after-the-fact redaction, and the distinction matters: once sensitive data has entered a prompt, it can influence the response even if you later try to mask the output. Keeping unauthorized data out of the flow entirely is a fundamentally stronger guarantee than cleaning up after it's already there.
The third is tool invocation through MCP. Every MCP tool an agent can reach gets classified by business category, automatically, and policies get written against those categories rather than against individual tool names. Keeping tool calls in check as MCP scales matters operationally: when a new tool gets added to an agent's toolkit, it inherits the policy for its category immediately, with no manual policy update required. An agent with access to a "financial reporting" category of tools doesn't get to call a newly connected tool just because nobody wrote a rule against that specific tool yet.
The fourth is action and API runtime authorization. Knowing that an agent is allowed to invoke an MCP tool is only half the battle; the system must also authorize the actual API calls and execution payloads that tool triggers. At this stage, PlainID evaluates the request at the API gateway or microservice level before any change takes effect. It inspects the action payload using enriched runtime context, verifying whether the composite identity (the agent and the user it represents) is authorized to perform that specific operation, such as modifying a record or triggering a financial transaction. This prevents agents from bypassing tool-level restrictions by executing unauthorized downstream API actions
The fifth is output masking. After the agent generates its response, sensitive fields, PII, confidential figures, anything the requester isn't cleared to see, get identified and masked before the response reaches the user. This is the safety net, not the primary control, because catching a leak after generation is a weaker position than never retrieving the data at all. But it matters for the cases where sensitivity depends on context the earlier stages couldn't fully resolve.
Enforcement doesn't stop once a session passes these checkpoints. It runs continuously, so an agent can be interrupted mid-session if its behavior shifts into territory its policy doesn't cover.
Binding the agent to the human it acts for
A CFO using an HR chatbot to check a company-wide benefits question shouldn't get that chatbot to surface individual employee salary data, even though the CFO's own role would normally clear them for compensation information. The HR agent, meanwhile, shouldn't expose employee-level financial detail just because the person prompting it happens to hold a senior title. Neither the human's permissions alone, nor the agent's permissions alone, produce the right answer. The right answer comes from evaluating both together.
PlainID calls this composite identity authorization: binding the human identity and the agent identity into a single access decision, evaluated at their intersection rather than independently. It solves the "agent superpower" problem, where an agent effectively gains permissions its creator never intended just because it's acting on behalf of someone with broad access. It also covers the reverse case, where an agent's own permissions would otherwise let it do something the requesting human has no business asking for.
This kind of binding extends to agent-to-agent chains too. When one agent hands a task to another, the authorization decision needs to track the full chain, human plus originating agent plus every agent downstream, rather than resetting to a fresh, unconstrained context at each hop. Getting agent permissions right from the start is what makes composite identity authorization work at scale, rather than bolting it on after an incident forces the issue.
Trading standing access for decisions made at the moment of use
The deepest fix for over-permissioning isn't a better list of who gets what. Removing standing access from agents entirely is what Zero Standing Privileges actually means: an agent holds no persistent, pre-assigned access at all. Every time it needs something, that need gets evaluated against policy at the exact moment of the request, using the agent's current context, not a permission it was handed weeks earlier and never had revoked.
This only works if changing a policy is fast enough to matter. If updating an access rule takes a development cycle and a deployment window, security teams end up tolerating overly broad standing access because tightening it is too slow to be practical. PlainID's platform enforces policy changes in under 60 seconds, which turns access control into something a security or compliance team can adjust directly, in plain-language policy or code, without waiting on an engineering queue. Policy-based access control, PBAC, is what makes this possible: instead of hardcoding permissions into application logic, policies live in a centralized layer and get evaluated dynamically against identity, context, and business attributes every time access is requested.
The audit side matters just as much as the enforcement side here. When every decision runs through a centralized policy engine, you get a full record of who accessed what, when, and against which specific policy, explainable in business language rather than buried in application logs. That record, PlainID calls it the Authorization Graph, turns "prove to the auditor that this agent couldn't have seen that data" from a forensic exercise into a query.
Where to start
You don't need to redesign your entire authorization architecture before your first agent ships safely. Building your authorization roadmap step by step starts with discovering what your agents can currently reach: the tools, the data sources, the APIs, before you decide what they should be allowed to reach. Most teams are surprised by the gap between the two.
From there, put the input guardrail in place first. Blocking unauthorized questions before retrieval happens is the highest-leverage, lowest-friction control to add, and it doesn't require touching your existing RAG pipeline or tool integrations. Layer in data-level filtering next, especially for any agent that touches regulated or customer-sensitive information. MCP tool classification and output masking can follow once the first two controls are proven out.
If you're building on LangChain or LangGraph, look for authorization libraries that plug into the framework you're already using rather than asking your engineers to rebuild agent logic around a new authorization layer. And if your agents are ephemeral, spun up for a single task and torn down afterward, write policy against the agent's attributes and behavior rather than against a static agent ID that won't exist by the time anyone reviews it. An agent registry, something like Microsoft's Entra Agent ID, gives you a way to trust and verify that identity in the first place. The design principles worth building around early tend to save the most rework, especially around agent identity and policy scope, before you've got dozens of agents running in production.
The agents you're deploying today will only multiply. Getting access control right before that scale hits is considerably cheaper than retrofitting it after an agent has already done something you can't fully explain to a regulator.
