Your internal audit team sends a request on a Tuesday morning. They want a list of every customer record the claims-processing agent read last quarter, which adjuster the agent was working for on each read, and the policy that allowed it. You have the agent’s logs from the LLM gateway, request logs from the API gateway, and query logs from the claims database, and none of them share an identifier. The agent ran under a service account called svc-claims-ai, so the database shows one identity making forty thousand queries. Nothing in any of the three systems records why a given query was permitted. Three engineers spend two weeks rebuilding a partial answer, and the auditor marks the control as ineffective anyway.
The enterprises where this happened did plenty right. They gave the agent a dedicated account, scoped its database role, and turned on logging everywhere. What they built was a set of permissions. The auditor wanted evidence of decisions, and permissions assigned at deployment can’t provide it, because no decision happens when the agent acts. The agent holds access, uses it, and leaves behind a trail of events with no policy attached.
An agentic AI permission control framework closes that gap. It treats each agent action as an authorization decision you can reconstruct later: which identity acted, on whose behalf, against what resource, under which policy, and with what result. You can build one in six layers, starting with agent identity and ending with the decision record your audit team needs. Each layer maps to a question an auditor or regulator will ask, which means you can test the framework against those questions before anyone outside your security team does.
Scale makes this urgent. Gartner puts the ratio of machine identities to human identities at 82 to 1, and agents push that count up faster than any access review cycle can track. A quarterly certification campaign designed for human employees has no way to keep pace with agents that a platform team can spin up in an afternoon.
Why agent permissions fail audits
Most agent permission setups borrow the model enterprises use for service accounts. An engineer creates a credential and grants it a role broad enough that the agent won’t hit errors during testing. Then the team ships. The role stays attached long after the pilot ends, and security teams know the result as standing privilege. Agents make standing privilege more dangerous than it is for a batch job, because an agent’s behavior shifts with each prompt. A nightly ETL job touches the same tables on every run. A support agent might query billing history for one customer, pull contract terms for another, and call a refund tool, all within one conversation and all under whatever the role allows.
Three audit failures follow from that design. The first is attribution: the agent acts under its own credential, so your logs lose the human who asked for the work. The second is justification. A role grant tells an auditor the agent could read the table, and it says nothing about whether this read was appropriate for this user at this moment. The third is fragmentation, because prompt logs, tool-call logs, API logs, and database logs sit in separate systems owned by separate teams. Stitching them together after the fact turns an audit question into a forensic project.
Identity providers and governance tools weren’t designed to close these failures. Your IdP authenticates the agent, and your IGA platform certifies that a role assignment exists, so both cover the question of who got in. Neither evaluates what the agent does once it’s inside, and PlainID has written in detail about the gaps legacy IAM leaves around agents for exactly this reason.
What an agent permission framework has to prove
Start from the audit and work backward. Internal audit, an external examiner working under SOX or GLBA, and a regulator applying the runtime controls the EU AI Act expects will all end up asking you the same five things. They want to know which agent acted and which human or process it acted for. They want to know what it touched, down to the record or field. And they want the policy that permitted or denied the action, along with proof that the policy was the approved version in force at the time.
A framework that answers those five questions for any agent action within minutes passes. A framework that answers them after a two-week reconstruction fails, even when the reconstruction turns out correct, because the auditor is testing whether the control operates continuously. That standard shapes every design choice in the layers below. You’re building a system that makes decisions and records them as it goes, rather than one that grants access and trusts the logs to fill in the story later.
Layer 1: Give every agent an identity you can verify
You can’t audit an actor you can’t name. Each agent needs its own identity, registered somewhere your authorization layer trusts, carrying attributes that policy can evaluate. Those attributes should include the agent’s owner, its business function, its environment, the data classifications it’s approved for, and the framework it runs on. An agent registry such as Microsoft Entra Agent ID gives you that anchor. Your authorization layer can then verify that a request comes from the agent it claims to be, which shuts down impersonation between agents. PlainID’s guide to getting agent permissions right from day one covers the identity groundwork in more depth.
Ephemeral agents complicate this. Orchestration frameworks spin up sub-agents for a single task and tear them down seconds later, and assigning each one a static ID and a static role is unworkable. Write policy against agent attributes instead. A temporary research sub-agent spawned by your finance assistant carries attributes like “function: research, parent: finance-assistant, data scope: public filings,” and your policies govern it by those characteristics for the few seconds it exists. The audit record still captures the instance ID, so you can trace the decision later without maintaining a role for something that lived for eight seconds.
Account for the agents your teams already deployed. Discovery has to come before governance, and most security teams who run an inventory find agents and MCP tools nobody registered. Tools built for surfacing agents and tools already running give you the baseline list that the rest of the framework governs.
Layer 2: Bind the agent to the human it acts for
Most agent actions happen on someone’s behalf. A sales rep asks an assistant to summarize an account, or a CFO asks an HR agent about headcount costs. If the agent’s own permissions decide the outcome, the agent becomes a privilege escalation path, because a junior employee can reach anything the agent can reach. If the user’s permissions alone decide it, a senior executive can pull anything they’re entitled to through an agent that was never designed to handle that data.
Composite identity authorization evaluates both identities together, plus the context of the task. The effective permission is the intersection: the agent’s approved scope, narrowed by the user’s entitlements, narrowed again by what this task requires. Your CFO using the HR agent sees headcount cost rollups, since the HR agent is approved for them and the CFO is entitled to them. That same CFO doesn’t see board financial projections through the HR agent, because nobody scoped that agent for financial planning data, and doesn’t see individual salary records, because the task doesn’t call for them.
Composite identity also fixes the attribution failure from the opening scenario. Each decision record names both identities, so the auditor’s question about which adjuster the claims agent was serving has a direct answer in the record. Agent-to-agent chains follow the same logic. An orchestrator handing work to a sub-agent passes the originating human’s identity along with the request through each hop, so a three-agent pipeline can’t launder a request into broader access than the person who started it holds.
Layer 3: Write policy against categories and intent
At this point the framework has two pieces: agents with verifiable identities, and decisions that account for the human behind each request. Neither produces an audit trail by itself. The next three layers cover policy, enforcement, and timing, and they determine whether each decision your framework makes is consistent, explainable, and provable against an approved policy version.
Policies written against individual tool names and agent names decay fast. Your teams add MCP tools weekly, and a policy listing twelve approved tools by hand goes stale the day someone registers the thirteenth. Classify tools and data into business categories such as customer PII, payment data, financial forecasts, HR records, and public content, then write policy against the categories. Once a new tool arrives and your classification process tags it “customer PII: write,” it falls under existing policy with no rule change and no gap between deployment and governance.
Policy-based access control gives you the structure, with rules that combine identity attributes, resource categories, and context into a decision. Intent adds the layer agents demand. An agent request carries a purpose you can infer from the prompt and the task, and your policy can evaluate that purpose. An engineer asking a coding assistant to summarize Q3 revenue forecasts gets blocked at the prompt, before the agent retrieves a single document, because engineering roles aren’t approved for that category of question. PlainID has a fuller explanation of how intent reshapes agent access decisions and where it sits on the RBAC to PBAC maturity curve.
Two practices make policy auditable. Version every policy and keep the history, so a decision record can point to the exact rule in force when the decision happened, an approach that works best when you’re managing policy as versioned code with promotion between environments. Write policy so the compliance and risk owners who understand the regulation can read it, too. A rule buried in Python inside an agent’s codebase is invisible to an auditor. A rule expressed in business terms, managed centrally, and changeable without a release cycle is something your second line of defense can review and sign off.
Layer 4: Enforce at the four points where an agent touches data
An agent workflow has four moments where access matters, and enforcing at one of them leaves the other three open. Input comes first: you evaluate the prompt and stop questions the user and agent aren’t cleared to ask. Retrieval is the second point, where filters decide which records, rows, columns, and documents enter the agent’s context window. Tool calls form the third, covering which MCP tools and APIs an agent may invoke and with what parameters for this user and task. The response is the last line, and masking there strips values the requester shouldn’t see before anything reaches the screen. PlainID breaks down the guardrails each agentic system needs at each of these stages.
Give pre-retrieval filtering priority. Redacting data after an agent has pulled it into context is weaker for two reasons. The model has already seen the data and can leak it through a paraphrase or summary, and your audit record shows sensitive data entering an unauthorized flow even if the final output looked clean. Filtering before retrieval keeps the unauthorized record out of the flow altogether, so the decision record shows a denial instead of a near miss. For RAG pipelines over documents, this depends on classifying unstructured content by category. For structured sources, row and column controls in the query path handle it.
Tool calls carry the highest stakes. A read permission can leak data, but a tool permission lets an agent move money, change records, or send email to customers. Your framework should govern which tools each user and agent pair can call and which parameters they can pass, and keeping MCP tool calls in check gets harder as your MCP server count grows.
Where you place enforcement matters for audit as well. Enforcement at the point where identity is known and access occurs, inside the agent framework, the MCP gateway, or the data layer, records each decision with full context. A proxy bolted on in front of the model sees traffic but tends to lose the user identity and the downstream data context, which reopens the attribution gap you closed in Layer 2.
Layer 5: Decide at runtime and keep nothing standing
Zero standing privileges means an agent holds no persistent access between tasks. Your framework evaluates each request at the moment it happens against current identity data, current policy, and current context, and the grant ends with the action. This changes the evidence you hand an auditor. Instead of showing that a role existed and someone certified it last quarter, you show a decision made at 14:32:07 on a specific date, with the inputs that drove it. PlainID covers the mechanics of stripping standing access out of agents in a dedicated piece.
Runtime decisions raise two practical concerns: latency and change speed. Agents make many calls per task, so your decision engine has to answer in milliseconds or your AI teams will route around it. Change speed matters during incidents. If a tool gets compromised or a regulator issues new guidance, you need the policy change enforced across every agent within minutes rather than on the next release train. Set both thresholds before you evaluate platforms and test each vendor against them.
Continuous enforcement belongs in this layer too. An agent session can run for an hour and drift from its original task. Evaluating each step in the session, and not just the opening request, lets you stop an agent mid-session the moment its behavior moves outside policy.
Layer 6: Record every decision with its policy attached
Your logging stack captures events today. An audit-ready framework captures decisions, and the difference lives in the fields. A decision record holds the agent identity and instance, the human identity it acted for, the requested action, and the resource down to its category and record. It also holds the policy and version evaluated, the attributes that drove the result, the result itself, and a timestamp. Store those records in one place and link them, so a single query can follow a request from the user through the agent, the tool, and the data. Monitoring tools fill a different role here, and it helps to understand where agent observability stops short of producing this kind of evidence.
Relationships matter as much as individual records. Auditors and incident responders ask chain questions. They want to know which users reached a dataset through any agent, which agents can call a payment tool, and which policy change last week widened access to HR records. A relational view connecting identity provider, application, agent, tool, and data answers each of those in one query instead of five log searches. Your team can also use it to spot gaps before an auditor does, such as an agent approved for a tool that exposes data categories the agent itself isn’t cleared for.
Explainability closes the loop. An auditor reading a decision record should understand it without an engineer translating. “Denied: user role Claims Adjuster Tier 1 not approved for category Medical Records under policy CLM-014 v3” is an audit answer, while a JSON blob of evaluated attributes is raw material someone still has to interpret. This is a big part of why policy based controls simplify identity audits, since the policy itself becomes the explanation.
Testing the framework before your auditor does
Run a mock audit once the layers are in place. Pick an agent in production, choose a user, and ask your team to produce the five answers for a sample of that user’s agent sessions over the past month. Time the exercise. If it takes longer than an hour, find the layer that broke. Missing composite identity shows up as unattributed actions. Missing versioning shows up as decisions you can’t tie to an approved rule, and fragmented enforcement shows up as mismatches between what the tool records show and what the data records show.
Then run the change test. Tighten one policy and measure how long it takes until every agent in scope enforces the new rule, and check that your decision records show the version switch. Finish with the negative path: have someone attempt a request the policy should deny at each of the four enforcement points, and confirm each denial appears in the record with a readable reason. Auditors trust denials more than grants as evidence, since a logged denial proves the control fired.
Map the framework to the standards your auditors already reference. The OWASP GenAI Threat Defense Compass, the CSA Agentic AI IAM framework, and Gartner’s AI TRiSM model all describe what agent controls should achieve. Your framework supplies the enforcement and the evidence those documents assume you have.
How PlainID supports each layer of the framework
PlainID built its Runtime Authorization Platform to cover this framework end to end, governing human, non-human, and AI agent identities through one policy layer. For identity, PlainID consumes user and agent data from Entra ID, Okta, Ping Identity, and agent registries, and it supports policies written against agent attributes so ephemeral agents stay governed. Composite identity authorization binds the agent and the person it serves into a single decision across human-to-agent, agent-to-agent, and agent-to-MCP chains.
On policy, PlainID discovers and classifies MCP tools and unstructured data into business categories on a schedule, so newly added tools land under existing rules with no manual edits. Compliance teams can author policy through a no-code builder while developers work in code, with versioning and environment promotion through CI/CD. Enforcement runs through PlainID’s Full-Flow AI Guardrails at all four control points (input, data, MCP tools, and output) using pre-built Authorizers, including authorization libraries built for LangChain and LangGraph, the PlainID MCP gateway, and a SQL Authorizer, with pre-retrieval filtering as the default data control. Decisions return in milliseconds, and policy changes reach every enforcement point in under 60 seconds without a development cycle.
For evidence, the PlainID Authorization Graph maps each access decision as a relationship chain from identity provider to application, agent, tool, and data, and it explains decisions in business language your auditors can read. PlainID was named a KuppingerCole market leader and Product Leader in policy-based access management, and appears as a representative vendor in Gartner’s Market Guide for Guardian Agents. The platform secures over 35 million identities and processes billions of authorization decisions daily for Fortune 500 enterprises in financial services and other regulated industries.
Rolling the framework out without stalling AI delivery
Start with one high-risk agent instead of the whole fleet. Choose the one touching regulated data, customer records, or payment tools. Inventory what it can reach, register its identity, write category-based policies with the business owner, and put enforcement at all four points for that agent alone. Run the mock audit on it. Your first agent takes the longest, because you’re building the categories and policy patterns that every agent after it reuses.
Bring AI engineering in early. The fastest way to kill a framework is to make it a gate engineers hit at the end of a project. Enforcement libraries that plug into the frameworks your teams already build on let developers ship with authorization in place from the first commit, and centrally managed policy turns a security review into a policy review instead of a code review. PlainID’s working blueprint for governing agents lays out how security and AI teams can split that ownership.
Expand by category after that, and let the agent count follow. By following this Discover → Manage → Enforce sequence, once your customer PII policies exist, each new agent that touches customer data inherits them on its first day in production. Every agent you add after the first costs less to govern, and the audit evidence for your whole fleet comes out of the same decision records, in the same format, answering the same five questions your auditor asked about the claims agent.
