AI agent governance: what to control after an agent's access is approved
Approving an AI agent's access is the start of governing it. Learn how to own, scope, review and constrain what agents do with direct and delegated access.
- An approved entitlement says what an agent can reach, not what it should do.
- Every agent needs a named owner, dated credentials and a place in access reviews.
- Count direct and delegated access separately; org-wide consent means anyone.
- Governance controls and runtime controls are different layers. Know which you are buying.
Approving an AI agent's access answers one question: what can it reach? It does not answer what the agent should do with that access, on whose behalf, or who is accountable when it does something unexpected. AI agent governance is the work that continues after approval: ownership, scoped reach, reviews and guardrails on actions.
This guide is for security and identity leaders who already have agents in their tenant, or are about to. It covers what changes once an agent has access, how to inventory and own agents, why delegated access matters more than direct access, and how to separate governance controls from runtime controls when you evaluate tools.
It is about governing AI agents as identities. For AI doing identity governance work, see the AI identity governance buyer checklist.
Approved access is not the end of agent risk
An agent with legitimate access can still do the wrong thing: act for someone it should not, touch data outside its purpose, or keep running after its owner has moved on. These are not access failures. They are governance gaps.
- The agent can reach these systems
- These scopes were consented
- The request was signed off once
- A named person answers for it
- Its reach is counted and reviewed
- Its actions run under set guardrails
Inventory agents and give each one an owner
You cannot govern agents you have not found. Agents arrive through many routes: low-code agent builders, assistants added to collaboration tools, automations with AI steps, and custom agents registered as applications.
For each agent, record:
- its platform, and the identities that back it
- a named owner who answers for what it does
- its credentials, with created, last-used and expiry dates
- its status, including whether it is still in use
Agents with no owner should be a named group with a severity, worked down like any other risk, not a note in a spreadsheet. The same ownership workflow applies as for other non-human identities; see assigning owners to unowned non-human identities.
Direct versus delegated agent access
Agents hold access in two ways, and the difference matters.
- Direct access belongs to the agent's own identity. It is usually small, countable and reviewable.
- Delegated access is borrowed. The agent acts on behalf of the people who consented, and inherits what they can reach.
Keep direct and delegated access separate in every view. An agent with six permissions of its own and forty borrowed is not an agent with forty-six, and collapsing the two hides where the real reach comes from.
Put agents in access review campaigns
Agents should be certified in the same access reviews as your applications and people, not exempted because they are new. A reviewer should see the agent's owner, its direct and delegated reach, and when it was last used.
If an agent stops being used, keep its record. You should always be able to answer what an agent used to reach, even after it is gone.
Guardrails on what agents may do
Governing an agent's identity is one layer. The other is deciding which actions it may take without asking. A simple model sets a level per action:
| Setting | What happens | Typical use |
|---|---|---|
| Auto-approve | The action runs without asking. | Low-risk reads and routine updates |
| Guarded | Runs only while set conditions hold. | Routine changes for a known population |
| Needs approval | A person approves each time. | Removals and admin changes |
| Blocked | The action is never taken. | Anything outside the agent's purpose |
The safe default is that an action with no setting needs approval. Silence should never be read as permission.
Governance controls versus runtime controls
Vendors use "AI agent governance" for different layers. Separate them when you evaluate tools.
- GovernanceWho and whatOwners, reach, reviews, deactivation.
- PolicyWhich actionsPer-action guardrails and approvals.
- RuntimeThis sessionLive session revocation, prompt and tool filtering.
Governance controls decide who owns an agent, what it can reach, whether that is still right, and when to deactivate it. Runtime controls act on a live session: cutting off an agent mid-task, filtering prompts or brokering each tool call. Both are useful, but they are different products. Ask each vendor which layer it covers, and do not assume one covers the other.
Questions to ask in an agent governance demo
- Show me every agent in our tenant, including ones built on agent platforms.
- Show direct and delegated access separately for one agent.
- Show an agent with org-wide consent. How is it flagged?
- Show an agent with no owner. What happens next?
- Show an agent inside an access review campaign.
- Which actions can run without a person, and what is the default?
- Which controls act on a live session, and which act on the identity?
How Ploy governs AI agents
Ploy's agent governance finds the agents running in your tenant, maps what each one can reach and names every person it is allowed to act as. Direct and delegated access stay separate on every screen, and an org-wide consent is labelled as any signed-in user. Every agent carries an owner, credentials with their dates and a place in your access reviews. Agents with no owner start as a control segment with a severity.
For Luna's own work, each action sits in one of four states: auto-approve, guarded, needs approval or blocked. An action with no setting waits for you.
Ploy governs agents as identities: ownership, reach, review and deactivation. It is not a runtime session broker or prompt filter. To see an agent's direct and delegated reach and its review, book a demo.
Frequently asked questions
What is AI agent governance?
It is the practice of owning, scoping, reviewing and constraining AI agents that act on your systems. It covers the agent's identity and access, and the actions it is allowed to take, not just the initial approval.
What is the difference between direct and delegated agent access?
Direct access belongs to the agent itself. Delegated access is borrowed from the people who consented, so the agent can do what they can do. Delegated access is usually much larger, and org-wide consent means the agent can act as anyone who signs in.
Should AI agents be included in access reviews?
Yes. Review them in the same campaigns as people and applications, with their owner, reach and last use visible. Exempting agents leaves the fastest-growing group of identities unreviewed.
Is AI agent governance the same as runtime security?
No. Governance decides ownership, reach, review and deactivation. Runtime controls act on a live session, such as cutting it off or filtering prompts. Many organisations need both, often from different tools.