AI Agent Access Reviews: Who Reviews What an AI Agent Can Do?

Enterprises are beginning to give AI agents something traditional software did not possess in the same way: delegated agency. An agent may search enterprise data, invoke APIs, select tools, create tickets, modify records, trigger workflows, or take actions across multiple systems without a human explicitly approving every individual step.

If you are a CISO or IAM leader, the question is therefore no longer simply whether an AI agent has been approved for enterprise use. The question is whether you can continuously establish who owns the agent, what it can access, which tools it can invoke, whose authority it is acting under, and whether those capabilities should continue.

That is the practical purpose of AI agent access reviews. They extend non-human identity governance beyond service accounts and workloads into identities that can reason, select tools, and initiate actions.

Microsoft now recommends treating agents as first-class principals with lifecycle-managed identities, explicit roles, tightly scoped permissions, controlled tool access, and end-to-end auditability. Microsoft

The access-review question consequently evolves from:

Does this identity still need this permission?

to:

Should this agent still be allowed to perform this action, using this tool, against this resource, under this authority?

An AI agent is not simply another service account

There are similarities between service accounts and AI agents.

Both are non-human identities. Both may authenticate to enterprise resources. Both need owners, credentials, entitlements, lifecycle controls, and auditability.

But there is an important difference.

A traditional service account usually supports a relatively predictable application or process.

An AI agent may dynamically determine how to accomplish an objective.

For example, an employee may ask:

"Investigate why this customer's payment failed and resolve the issue."

The agent might:

Retrieve customer record → Query payment system → Search logs → Open support ticket → Update CRM → Trigger refund workflow → Notify customer

The individual permissions may appear reasonable.

The combination of permissions and the agent's ability to chain them together creates a different governance problem.

The Cloud Security Alliance similarly distinguishes autonomous agents from traditional machine identities because agents can plan tasks, select tools, call APIs across systems, and adapt their actions based on objectives and context. Cloud Security Alliance

This is why agent access reviews cannot simply copy the service-account certification model.

The agent itself needs an identity

Before an agent's access can be reviewed, the enterprise needs to know which agent performed the action.

An agent should therefore be represented as an identifiable principal rather than disappearing behind a shared service account or common API credential.

Microsoft's current guidance explicitly recommends giving each agent its own identity so that its actions remain attributable and its access can be granted, reviewed, and revoked independently. Microsoft Learn

A useful governance model is:

Human Sponsor → Agent Identity → Credential → Entitlement → Tool → Resource → Action

Consider:

Agent: Finance-Reconciliation-Agent
Owner: Finance Operations
Sponsor: Head of Finance Operations
Purpose: Investigate reconciliation failures
Tool: Payment API
Permission: Read transactions
Resource: Production Payment Platform
Action: Retrieve transaction details

Now compare that with:

Agent: Unknown
Credential: Shared API key
Permission: Payment API access

The second model may technically work.

It is extremely difficult to govern.

Without a distinct identity, the organization struggles to answer:

Which agent acted? Why was it authorized? Who owns it? What permissions should be revoked if it is compromised?

Identity therefore becomes the foundation for meaningful agent certification.

Every AI agent needs an accountable human

An autonomous agent should not mean an unaccountable agent.

Every enterprise agent should have a human sponsor or owner accountable for its purpose and lifecycle.

Microsoft Entra's agent-governance model follows this principle by requiring human sponsorship for agent identities. Microsoft also provides mechanisms to transfer sponsorship if the sponsor leaves the organization, preserving human accountability for the agent's lifecycle and access. Microsoft Learn

That creates a useful governance principle:

An agent may operate autonomously, but responsibility for its authority should remain attributable to a human.

An agent record should therefore answer:

• Who owns the agent?
• Who sponsors its use?
• What business purpose does it serve?
• What applications can it reach?
• What data can it access?
• What tools can it invoke?
• Which MCP servers can it connect to?
• What actions can it perform?
• Does it act autonomously or on behalf of a user?
• What credentials does it use?
• When was its access last reviewed?
• When should the agent be retired?

If these questions cannot be answered, the organization may have an AI inventory.

It does not yet have AI identity governance.

What exactly should an AI agent access review certify?

This is where agent certification becomes more interesting than traditional access review.

A human review may ask:

Does Rahul still need Salesforce?

A service-account review may ask:

Does svc-payment-prod still require database write access?

An AI agent review may need to ask several questions simultaneously:

Should this agent still exist?

Should it still access this application?

Should it still have this entitlement?

Should it still be allowed to invoke this tool?

Should that tool permit this particular action?

Should the agent be able to perform the action autonomously?

These are different governance decisions.

Consider an HR agent.

The agent may legitimately need access to the HR system.

But that does not mean it should automatically have permission to:

Read employee record → Modify employee record → Change compensation → Terminate employee → Export employee data

The application access may be justified while several capabilities are not.

The certification unit therefore needs to move from:

Agent → Application

toward:

Agent → Tool → Permission → Resource → Action

Microsoft's recent agent-governance guidance makes a similar point: agent risk is strongly determined by the tools available to the agent and what those tools allow it to do. Connectors, plugins, skills, and MCP servers can all effectively extend an agent's reach. Microsoft Learn

Agent access reviews need tool context

Suppose a reviewer sees:

Agent: Finance Agent
Application: SAP
Access: Approved

That tells the reviewer very little.

A more meaningful certification might show:

Agent: Finance-Reconciliation-Agent
Owner: Finance Operations
Application: Payment Platform
Tool: Payment API
Allowed Actions: Read Transactions, Create Reconciliation Case
Restricted Actions: Modify Payment, Issue Refund
Environment: Production
Last Used: 2 hours ago
Granted: 7 months ago
Agent Risk: Medium
Decision: Approve / Modify / Revoke

The reviewer can now make a governance decision based on capability, not merely connectivity.

Useful context can include:

Context	Why it matters
Agent owner/sponsor	Who is accountable?
Business purpose	Why does the agent exist?
Applications	What systems can it reach?
Tools/MCP servers	What capabilities can it invoke?
Effective permissions	What can those tools actually do?
Read/write/admin	What is the potential impact?
Delegated user	On whose behalf is it acting?
Credential	How does it authenticate?
Last activity	Is the capability still being used?
Risk level	How much scrutiny is required?
Agent version	Has the reviewed agent materially changed?
Approval requirements	Which actions require human intervention?

This is the difference between reviewing an AI application and reviewing an AI actor.

Who should certify an AI agent?

An employee has a manager.

An AI agent does not.

The person who built the agent may understand its architecture but may not be the appropriate person to approve its business authority.

The business owner may understand its purpose but may not understand the technical significance of every tool.

Security may understand the risk but not whether the capability is operationally necessary.

Agent certification may therefore involve different reviewers:

Agent Capability	Potential Certifier
Business purpose	Business sponsor
Application access	Application owner
Data access	Data owner
MCP/tool access	Tool or platform owner
Privileged capability	Security/IAM
High-impact autonomous action	Business + Security
Agent lifecycle	Agent owner/sponsor

This creates a strong use case for multi-level certification.

For example:

Agent Sponsor → Application/Tool Owner → Security for High-Risk Capabilities

Not every tool permission needs three reviewers.

A knowledge agent retrieving approved internal documents may need relatively lightweight certification.

An agent capable of modifying identities, changing production infrastructure, processing payments, accessing secrets, or deleting records deserves considerably stronger scrutiny.

The certification workflow should therefore reflect the agency and potential impact of the agent.

Least privilege becomes least agency

Traditional identity governance applies the principle of least privilege:

Give an identity only the access required to perform its role.

For agents, that principle needs to extend further.

An agent should have only the agency required to accomplish its approved objective.

Microsoft recommends task-based roles, explicit resource and operation boundaries, approved tool sets, separation of read and write capabilities, and stronger controls around high-impact operations. Microsoft

Consider a customer-support agent.

It may need:

Read customer record

It may reasonably need:

Create support ticket

It might occasionally need:

Initiate refund

It probably should not automatically receive:

Delete customer → Change bank account → Modify IAM role → Export entire customer database

The governance question therefore becomes:

What is the minimum combination of data, tools, permissions, and autonomous actions required for this agent to perform its purpose?

That is least agency.

And an agent access review should periodically challenge whether that boundary is still correct.

Tool combinations can create risks that individual permissions do not show

Agent governance also introduces a form of access risk similar to Segregation of Duties.

Consider an agent that has:

Tool A: Read employee information

Tool B: Modify payroll

Tool C: Approve workflow

Each tool may have been approved independently.

Together, they may allow the agent to execute an entire sensitive business process without independent oversight.

Microsoft specifically warns that multiple individually reasonable roles or tool permissions can combine into higher-impact action chains. Microsoft

This means agent certification should eventually evaluate:

Individual Tool Risk + Combined Capability Risk

That creates an agent-governance equivalent of SoD.

The question becomes:

What can this agent accomplish by chaining everything it is allowed to use?

This is substantially more valuable than reviewing each permission independently.

MCP changes the access-review boundary

Model Context Protocol introduces another important governance layer.

An agent may connect to an MCP server exposing multiple tools.

For example:

GitHub MCP Server

could expose:

Read repository → Create issue → Modify file → Create branch → Merge pull request

Certifying:

Agent has access to GitHub MCP

is therefore too broad.

The meaningful review is:

Which tools exposed through this MCP server should this agent be permitted to invoke?

The access chain becomes:

Agent → MCP Server → Tool → Resource → Action

This is why AI agent and MCP governance should eventually operate alongside traditional identity and entitlement certification. Astranova Labs

Microsoft's current guidance similarly treats MCP servers, connectors, skills, and plugins as tools that expand an agent's ability to reach data and perform actions. Microsoft Learn

MCP tool access deserves a deeper certification model of its own, which we will address separately in this series.

Autonomous and delegated agents should not be reviewed identically

Another important distinction is whose authority the agent is using.

An autonomous agent may act under permissions directly assigned to its own identity.

A delegated agent may act on behalf of a human.

The resulting chains look different:

Autonomous

Agent → Tool → Resource

Delegated

Human → Agent → Tool → Resource

Microsoft's guidance recommends keeping these identities distinct and making clear whether the agent is operating under its own authority, delegated user authority, or another application identity. Microsoft Learn

That distinction matters during certification.

Suppose an employee has permission to approve a payment.

Does that automatically mean an AI agent acting for that employee should also be able to approve the payment?

Not necessarily.

Organizations may decide:

Human can approve → Agent can prepare → Human must confirm

The underlying entitlement is therefore only one part of the governance decision.

Agent certification also needs to evaluate delegation and autonomy.

High-impact actions should receive stronger certification

Not every agent capability deserves the same review frequency or approval model.

A risk-based model might look like this:

Agent Capability	Possible Governance Approach
Read public/internal knowledge	Periodic review
Read sensitive enterprise data	More frequent certification
Create drafts/tickets	Periodic review
Modify production data	Higher scrutiny
Access secrets	High-risk certification
Modify identities/permissions	Multi-level review
Execute financial transactions	Human approval + certification
Delete resources	Restricted/high-risk review
New MCP tool added	Event-driven review
Agent owner leaves	Immediate ownership review

The objective is not to review every agent action manually.

That would defeat the purpose of automation.

The objective is to decide which classes of actions the agent may perform autonomously and where human authority must remain in the loop.

Agent access should be reviewed when the agent changes

Traditional access reviews primarily focus on changes to the identity or entitlement.

Agents introduce another trigger:

The agent itself can change.

Its model may change.

Its system instructions may change.

Its tools may change.

A new MCP server may be connected.

Its workflow may expand.

It may move from read-only recommendations to autonomous remediation.

An agent originally approved to:

"Summarize security alerts"

may later evolve to:

"Investigate and automatically remediate security alerts."

Those are materially different levels of agency.

Microsoft recommends mandatory re-approval when an agent's workflow changes materially. Microsoft

This suggests an important governance principle:

A material change in an agent's capabilities should challenge its previous certification.

Useful event-driven review triggers include:

• new tool assigned
• new MCP server connected
• write capability introduced
• privileged permission added
• autonomous execution enabled
• owner or sponsor changes
• target application changes
• new sensitive data source added
• credential changes
• model or workflow materially changes
• agent becomes dormant
• unusual risk behavior appears

The calendar should not be the only reason an agent's authority gets reconsidered.

Kill-switch capability should be part of agent governance

Human access can usually be disabled through the identity provider or application.

Agents can be more complicated.

An agent may have multiple credentials, sessions, tools, tokens, downstream integrations, and delegated permissions.

Organizations therefore need to know:

If this agent becomes unsafe, can we actually stop it?

Microsoft recommends designing and testing shutdown procedures that disable agent identities and invalidate credentials and tokens, rather than assuming revocation will work when an incident occurs. Microsoft

An agent access review should therefore consider whether the organization has an effective revocation path.

For a high-risk agent, certification without the ability to disable it rapidly is incomplete governance.

This makes an AI kill switch an important operational control rather than merely a product feature.

Audit evidence needs to preserve the chain of authority

For a human identity, an auditor may ask:

Why did Rahul have access to this application?

For an AI agent, the question becomes more complicated:

Why was this agent permitted to perform this action, through this tool, against this resource, and under whose authority?

The evidence chain should therefore preserve:

Human Sponsor → Agent → Identity → Permission → Tool → Resource → Action → Decision

Microsoft similarly recommends logging agent identity, role, effective scope, resource, action, delegated user where applicable, timestamps, and correlation information across the agent-to-tool chain. Microsoft

A defensible agent certification record should include:

• agent identity
• owner and sponsor
• business purpose
• lifecycle status
• applications
• entitlements
• tools
• MCP servers
• allowed actions
• delegated authority
• credential information
• risk level
• certification decisions
• reviewer
• reassignment history
• policy exceptions
• remediation
• timestamps
• retirement or disablement evidence

That is what turns AI observability into AI governance.

What good AI agent access governance should change operationally

The goal is not simply to create an inventory of AI agents.

It is to ensure that every enterprise agent is identifiable, attributable, constrained, reviewable, and stoppable.

Organizations should expect to:

• register AI agents as governed identities
• assign accountable human sponsors
• document business purpose
• map agents to applications and resources
• inventory tools and MCP servers
• review permissions at the tool and action level
• distinguish autonomous from delegated authority
• apply least privilege and least agency
• identify risky combinations of capabilities
• use stronger certification for high-impact actions
• trigger reviews when agent capabilities change
• maintain a reliable kill-switch mechanism
• track remediation after revoke decisions
• preserve the complete human-to-agent-to-tool-to-resource audit chain

The measure of maturity is therefore not:

How many AI agents have we discovered?

It is:

Can we explain who authorized each agent, what it is allowed to do, why it still needs those capabilities, and how quickly we can remove that authority?

FAQ

What is an AI agent access review?

An AI agent access review is a certification process that determines whether an AI agent should continue to have access to particular applications, data, entitlements, tools, MCP servers, and actions.

Is an AI agent just another non-human identity?

An AI agent is a type of non-human identity, but its ability to select tools, chain actions, operate under delegated authority, and potentially act autonomously creates additional governance requirements.

Who should certify an AI agent's access?

The appropriate certifier depends on what is being reviewed. The agent sponsor may validate business purpose, an application or data owner may validate resource access, a tool owner may validate tool permissions, and security may review high-risk or privileged capabilities.

Should every AI agent have a human owner?

For enterprise governance, there should be an accountable human sponsor or owner responsible for the agent's purpose, access, lifecycle, and continued operation. Microsoft has adopted this principle in its agent identity governance model. Microsoft Learn

Should AI agents have permanent permissions?

Not necessarily. Baseline permissions should be narrow, with time-limited or just-in-time elevation considered for higher-risk activities where practical. Microsoft

Should access be reviewed when an agent gets a new tool?

Yes, particularly where the new tool materially increases what the agent can access or do. A new MCP server, write capability, sensitive data source, or privileged tool can change the agent's effective risk even when its original identity remains unchanged.

What is least agency?

Least agency extends least privilege beyond permissions. It means limiting not only what an agent can access, but also the tools, actions, autonomy, and delegated authority it can exercise to the minimum necessary for its approved purpose.

Why does an AI agent need a kill switch?

Because revoking one permission may not stop an agent that has multiple credentials, sessions, integrations, or downstream capabilities. High-risk agents should have a tested mechanism for rapidly disabling their authority.

AI agent access reviews ultimately need to answer more than:

Does this agent still need access?

They should establish:

Who owns this agent, what is it trying to accomplish, what resources can it reach, which tools can it invoke, what actions can it take, whose authority is it using, how much autonomy should it have, and can we stop it when that authority is no longer appropriate?

That is the standard modern AI agent access certification should meet.