A procurement team at a mid-sized insurer builds a contract assistant during a two-day hackathon. The engineer registers it in Entra ID as an app registration and grants it read access across the company’s SharePoint sites so it can find vendor agreements. He lists himself as the owner. The assistant works well enough that buyers start using it every day. Four months later, a junior buyer asks it to summarize recent agreements with a logistics vendor. The response includes terms from a draft acquisition agreement stored on the corporate development team’s site. Nobody in corporate development knew the assistant existed. The engineer who built it had moved to the data platform team in month two. The quarterly access review certified the app registration twice, because the reviewer saw a familiar app name and a valid owner field and clicked approve.
Your organization probably has a version of this agent running right now. It had an identity, an owner and a certification record, so by most identity governance checklists it counted as governed. It lacked any control that evaluated the acquisition draft at the moment the agent reached for it, on behalf of a buyer who had no reason to see it. The governance program described the agent accurately and protected nothing.
AI agent identity governance is the practice of deciding which agents may exist, who answers for each one, and controlling what every agent can access, do, and expose in real time . It then enforces those decisions at the moment the agent acts, for as long as the agent runs. Identity governance and administration (IGA) teams know the first half of that definition well. Most programs stop short on the second half, and the second half decides whether governance keeps sensitive data out of an agent’s context window or only records who should have kept it out.
Scale turns this from a hygiene issue into a data exposure issue. Gartner puts the ratio of machine identities to human identities at 82 to 1, and AI agents grow that count faster than any review cycle built for employees can follow. A platform team can deploy a dozen agents in a sprint, each with credentials, tool access and a path to documents. Each one also carries the same risk as the contract assistant: broad standing access, an owner who may have moved on, and permissions that mean something different depending on who is typing the prompt.
This guide covers five controls that govern an agent before it touches sensitive data. It also explains how the work divides between your IGA platform and a runtime authorization layer, and how to prove the program operates when an auditor or regulator asks.
Why traditional identity governance falls short for AI agents
IGA programs grew up around people. Your HR system creates a record, a joiner workflow provisions access, a mover event adjusts it, and a leaver event removes it. Certification campaigns ask managers every quarter whether each person still needs each entitlement. The model assumes an identity with a stable job, a manager who understands that job, and entitlements that map to the work the person does.
AI agents break each of those assumptions. No HR record exists for an agent, so engineers create agents in CI pipelines, notebooks and orchestration frameworks, often outside any request workflow. Lifetimes range from a sub-agent that exists for eight seconds to an assistant that runs for years. The entitlements an agent holds tend to be broad, because its job changes with every prompt. A contract assistant might look up a vendor’s payment terms in one conversation and search for a renewal clause in the next, and the engineer grants a wide scope so the agent doesn’t fail on either.
Certification fails the hardest. A reviewer looking at the contract assistant sees “Sites.Read.All: approved, owner present” and has no basis to say no, because the honest answer to “should this agent hold this entitlement” depends on who the agent is working for and what they asked. A procurement buyer and a corporate development analyst can send the same agent the same question and deserve different answers. An entitlement review can’t capture that difference, since the entitlement is identical in both cases.
Dormancy adds a quieter risk. An agent nobody has used in three months still holds a live credential and live access, and an attacker who finds that credential inherits everything the agent can reach. PlainID has written about where legacy IAM loses track of agents, and the pattern holds across IdPs and IGA platforms. These tools answer the question of who got in. Governing an agent requires answering what it may do once it’s inside, request by request.
Move the governance point to the moment of access
Identity governance for AI agents works when you treat approval and enforcement as two halves of one control. Your governance process decides the agent’s purpose, its owner and the categories of data and tools it may touch. A runtime authorization layer turns those decisions into an allow or deny at each access, evaluated against the agent, the human it serves and the request in front of it. Approval without enforcement leaves you with the contract assistant. Enforcement without approval leaves engineers writing access rules nobody in risk or compliance ever reviewed.
The test for your program is concrete. Pick a sensitive record, such as a draft acquisition agreement, a customer’s medical claim or a board forecast. Then check whether your controls can stop an agent from reading it before the read happens, based on who the agent is serving and what the agent was approved for. A role, a certification or a log entry after the fact doesn’t count. If the answer is no, your agents are governed on paper. The shift toward authorization for machine identities and AI agents comes down to closing exactly this gap.
The five controls below follow the order an agent meets them, from creation through its first sensitive request to retirement. Each one stands on its own, and each one fails in a recognizable way when it’s missing.
Five controls that govern an AI agent before it touches sensitive data
1. Register every agent and name the human who answers for it
You can’t govern an agent you haven’t found. Start with discovery across your agent frameworks, MCP servers, cloud AI platforms and identity providers, and expect to find agents and tools nobody registered. Hackathon projects, vendor-built assistants and sub-agents spawned by orchestration frameworks all turn up in a first inventory. Tooling for discovering the identities, tools and data in your environment gives you a baseline list, and running discovery on a schedule keeps new agents from slipping past governance after the first sweep.
Each registered agent needs an AI agent identity your authorization layer can verify, and it needs attributes that policy can read. Record the accountable owner, the business function, the environment, the framework, and the data and tool categories the agent is approved for. An agent registry such as Microsoft Entra Agent ID anchors that identity, so the authorization layer can confirm a request comes from the agent it claims to be. That confirmation blocks one agent from impersonating another to borrow its access.
Ownership needs a rule attached to it. In the opening scenario, the owner field stayed valid long after the owner stopped paying attention. Tie the owner attribute to your HR data so a transfer or departure triggers reassignment, and suspend the agent’s access if nobody accepts ownership within a set window. PlainID’s guide to getting agent permissions right from the first deployment covers the identity groundwork in more depth.
2. Approve a data scope by category instead of a role
The approval decision is the heart of AI agent governance, and most programs record it in the wrong form. A role or an entitlement grant tells you what the agent can reach. It says nothing about what the business intended. Ask the business owner to approve a scope expressed in data and tool categories. For the contract assistant, that scope would be vendor contracts and procurement policies, read-only, with no access to corporate development, HR records or customer PII. The approval becomes a policy your authorization layer enforces, and that policy is the record of what the business intended.
Categories need classification underneath them. Structured data usually carries classification already through schemas, tags or data catalogs. Unstructured content in SharePoint, file shares and vector stores often has none, so you need a process that scans documents and assigns categories. Tools need the same treatment, with each MCP tool and API tagged by business function and sensitivity. A new tool tagged “vendor contracts: read” then falls under the contract assistant’s existing policy automatically. A new tool tagged “M&A: read” stays out of reach without anyone editing a rule.
Category-based scope also handles ephemeral agents. A sub-agent spawned for one task can’t go through an approval workflow, but it can carry attributes from its parent, such as “function: contract research, parent: contract-assistant, scope: vendor contracts.” Your policies govern it by those attributes for the seconds it exists. Intent extends the model further. A request’s purpose, inferred from the prompt and task, becomes one more input to the decision, and PlainID explains how intent shapes agent access decisions on top of policy-based access control.
3. Tie every agent request to the person behind it
Most agent actions happen on someone’s behalf, and governance that looks at the agent alone misses half the decision. If the agent’s own scope decides the outcome, a junior employee can reach anything the agent can reach. If the user’s entitlements alone decide it, a senior executive can pull sensitive data through an agent nobody designed to handle it.
Composite identity authorization evaluates both identities together, along with the task. The buyer in the opening scenario works in procurement and has no entitlement to corporate development material. The contract assistant has no approval for M&A documents either. Either fact alone should block the acquisition draft, and composite evaluation applies to both. A corporate development analyst using the same assistant also wouldn’t see the draft through it, since the assistant’s approved scope excludes that category no matter who is asking.
Agent-to-agent chains follow the same logic. An orchestrator that hands work to a specialist agent passes the originating user’s identity along with the request through each hop. A three-agent pipeline then can’t widen access beyond what the person who started it holds. Fully autonomous agents with no human in the loop still get governed, through agent-only policies built on their registered attributes and approved scope.
4. Stop unauthorized data before retrieval
The acquisition draft reached the buyer because nothing stood between the agent’s retrieval step and the document. Governance has to act at that boundary, and ideally one step earlier. An input check at the prompt stage evaluates the question itself. A buyer asking the contract assistant about pending acquisitions gets stopped before the agent searches anything, because procurement users aren’t approved for that category of question.
The data step comes next. Pre-retrieval filtering decides which documents, rows and columns enter the agent’s context window, using metadata filters for unstructured content and row and column controls for structured sources. The corporate development site never shows up in the assistant’s search results, so the model never sees the draft. Redacting after retrieval is weaker. Once a document lands in context, the model can leak it through paraphrase or summary, and your records show restricted data entering a flow it shouldn’t have, even if the final answer looked clean.
Tool calls and responses close the remaining paths. Governing which MCP tools an agent can call, with which parameters, stops an agent from writing or sending what it shouldn’t. Masking at the output stage catches sensitive values that legitimately entered the flow but don’t belong in this user’s answer. PlainID details the guardrails each agentic system needs at all four stages. For governance, the input and data steps carry the most weight, because they keep sensitive data from ever reaching the agent.
5. Govern change, review and retirement continuously
Agents change faster than human roles. A new tool gets connected, a prompt template gets rewritten, or the business owner widens the scope for a new project. Treat every scope change as a policy change. That means versioning it, getting it approved by the business owner, and recording it, an approach that works well when you’re managing access rules as versioned code with promotion between environments. Speed matters during incidents. If a tool is compromised or a new regulation lands, the revised policy should reach every agent in scope within minutes.
Recertification looks different once policy carries the approval. Reviewers stop rubber-stamping entitlements and start reviewing two things they can judge: the approved scope written in business terms, and the decisions the agent made last quarter. A risk owner can read “contract assistant: approved for vendor contracts, denied 41 requests for M&A material in Q3” and make a real call about whether the scope still fits.
Dormancy and retirement get easier under zero standing privileges. An agent holds no persistent access between requests, so an idle agent’s credential reaches nothing, and an attacker who steals it inherits an identity with no grants attached. PlainID covers the mechanics of removing standing access from agents in a dedicated piece. Retiring an agent then comes down to removing its registry entry. Policies reference categories and attributes instead of the agent’s name, so no orphaned rules stay behind for someone to clean up.
How IGA and runtime authorization divide the work
AI agent governance doesn’t need a parallel control stack. It needs each layer of your identity stack doing the job it was built for, with data flowing between them. Your IGA platform, whether SailPoint, Saviynt or another, owns the agent as an identity object: the request to create it, the approval, the owner, periodic review and deprovisioning. Your identity provider, such as Entra ID, Okta or Ping Identity, authenticates the agent and often hosts the agent registry.
Runtime authorization sits after both and answers the question neither can. It evaluates every access against the approved scope, the human the agent serves and the context of the request, and it does so at the moment the agent reaches for data. The handoff runs in both directions. Approvals and ownership from IGA become attributes that runtime policy reads. Decision data from runtime enforcement flows back into reviews, so certifiers see what the agent did instead of what it was entitled to do. PlainID extends the IAM and IGA investments you already run in this way, adding the enforcement layer they were never designed to provide.
Proving AI agent governance to auditors and regulators
Auditors and regulators test whether a control operates continuously, and a policy document can’t show that by itself. The evidence they accept is a record of decisions. For any agent action, you should be able to show which agent acted, which person it acted for, what it touched, which policy version applied and what the result was. Regulators working under the runtime obligations the EU AI Act introduces, and examiners applying SOX or GLBA, will ask for that chain.
Chain questions need a relational view across decisions. A risk committee will want to know which agents can reach M&A documents, which employees accessed customer PII through any agent last month, and whether last week’s policy change widened access anywhere. A graph that links identity provider, application, agent, tool and data answers each of those in one query instead of five log searches. Monitoring tools play a supporting role, but agent observability stops short of producing decisions tied to approved policy.
Denials make the strongest evidence. A record showing the contract assistant refused a procurement buyer’s request for acquisition material, citing the policy and version, proves the control fired. Explain those records in business language your second line of defense can read without an engineer translating, which is a big part of why policy-based controls simplify identity audits.
How PlainID governs AI agent identities
PlainID built its Runtime Authorization Platform to govern human, non-human, and AI agent identities through one policy layer that controls what every identity can access, do, and expose. That layer covers each of the five controls above. PlainID discovers agents’ associated data, tools and APIs, and it trusts agent registries such as Microsoft Entra Agent ID to verify agent identity. It also supports policies written against agent attributes, so ephemeral sub-agents stay governed without static IDs. Composite identity authorization binds each agent to the person it serves, across human-to-agent, agent-to-agent, and agent-to-MCP chains.
For scope, PlainID classifies MCP tools and unstructured documents into business categories on a schedule, so new tools fall under existing policy with no manual edits. Compliance and risk owners can author policy through a no-code builder while developers work in code, with versioning and promotion through CI/CD. Enforcement runs through PlainID’s Full-Flow AI Guardrails at input, data, MCP tools, and output, with pre-retrieval filtering as the default data control. Pre-built Authorizers deliver it, including authorization libraries for LangChain and LangGraph, the PlainID MCP gateway, and a SQL Authorizer. 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 every access decision as a chain from identity provider to application, agent, tool and data, and explains each decision in business language. PlainID was recognized by KuppingerCole as a Market Leader and Product Leader in policy-based access management. It also 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.
Where to start with identity governance for AI agents
Pick the one agent that worries your CISO most, usually the one closest to regulated data, deal documents or payment tools. Run discovery around it so you know every tool and data source it can reach. Confirm its owner, sit down with the business sponsor, and write its approved scope in categories. Put input and data enforcement in front of it before anything else, since those two steps keep sensitive content out of its context window. Then test it the way the opening scenario failed. Have a user outside the approved scope ask for restricted material, and confirm the request is blocked at the prompt and appears in the decision record with a readable reason.
Bring AI engineering into the process from the start. Enforcement libraries that plug into the frameworks your teams already use let developers ship agents with governance in place from the first commit. Centrally managed policy also turns a security review into a scope review the business owner can sign off in an afternoon. PlainID’s blueprint for governing AI agents lays out how security and AI teams can split that ownership.
Expand by category after the first agent. Once vendor contract, customer PII and M&A categories have approved policies, every new agent that touches those categories inherits them on its first day in production. Each agent after the first then costs less to govern than the one before it.
