MCP Tool Access Reviews: Governing What AI Agents Can Actually Execute

AI agent governance does not end when an organization registers an agent, assigns an owner, and approves its application access. The most consequential question often sits one level deeper: what can the agent actually do once it connects to a tool?

If you are a CISO or IAM leader, knowing that an AI agent can connect to an MCP server is not enough. You need to establish which tools that server exposes, which of those tools the agent can invoke, what resources those tools can reach, what operations they permit, and whether that authority should continue.

That is the practical purpose of MCP tool access reviews. They extend AI agent governance from governing the identity of the agent to governing its actual capabilities.

Microsoft describes tools as the capabilities that allow agents to reach data or take action in another system. Connectors, skills, plugins, and MCP servers can all expand what an agent is able to accomplish. The security boundary therefore increasingly moves from simply asking which system can this agent access? to asking which actions can this agent perform through that system?

The access-review question evolves from:

Should this agent have access to this MCP server?

to:

Should this agent still be allowed to invoke this particular tool, perform this operation, against this resource, under these conditions?

MCP servers are capability gateways, not just integrations

Traditional application integration tends to be relatively predictable.

An application connects to another application through an API. The permissions assigned to that integration determine what it can do.

MCP introduces a more dynamic model.

An MCP server may expose a collection of tools that an AI agent can discover and invoke while performing a task.

For example, a GitHub-related MCP server might expose capabilities such as:

Read repository → Search code → Create issue → Create branch → Modify file → Create pull request

A service-management MCP server might expose:

Read ticket → Create ticket → Modify ticket → Assign ticket → Close ticket

A database MCP server might expose:

Query data → Insert record → Update record → Delete record

Approving the MCP server therefore does not necessarily mean every exposed tool should be available to every agent.

Microsoft's current Agent 365 approach similarly introduces centralized registration and approval of MCP servers and visibility into the tools they declare. Administrators can approve or reject MCP-server registrations and block servers centrally when necessary.

That is an important governance foundation.

But enterprise access governance eventually needs to go deeper.

The governance unit should eventually become the tool

Consider two AI agents connected to the same HR MCP server.

Agent A: HR Knowledge Assistant

Purpose:

Answer employee questions about policies and benefits.

Appropriate capabilities may be:

Read policy → Search benefits → Retrieve employee's own information

Agent B: HR Operations Agent

Purpose:

Support HR operations workflows.

Appropriate capabilities may include:

Read employee → Update employee → Initiate workflow

Both agents may legitimately connect to the same MCP server.

But giving both agents every tool exposed by that server creates unnecessary agency.

Microsoft's current guidance makes the same underlying point: the risk of an agent depends heavily on the tools available to it and what those tools permit it to do. An agent that can retrieve information presents a materially different risk from one that can send, modify, delete, deploy, or transact.

The certification unit therefore needs to evolve from:

Agent → MCP Server

toward:

Agent → MCP Server → Tool → Operation → Resource

That is where MCP access review becomes meaningful.

An MCP access review needs more than a tool name

Suppose a certification campaign presents:

Agent: Finance Agent
MCP Server: Finance MCP
Tool: Payment
Decision: Approve / Revoke

The reviewer still does not know enough.

What does "Payment" mean?

Can it read transactions?

Can it create a payment?

Can it modify beneficiary information?

Can it approve a transaction?

Can it cancel one?

A stronger review might show:

Agent: Finance-Reconciliation-Agent
Owner: Finance Operations
MCP Server: Payment Operations MCP
Tool: get_transaction
Operation: Read
Resource: Production Payment Platform
Data Scope: Assigned business unit
Last Used: 3 hours ago
Invocations in 90 days: 417
Risk: Low
Decision: Approve / Modify / Revoke

and separately:

Agent: Finance-Reconciliation-Agent
Tool: issue_refund
Operation: Financial Transaction
Maximum Value: ₹50,000
Human Approval Required: Yes
Last Used: 84 days ago
Risk: High
Decision: Approve / Modify / Revoke

The same agent and MCP server are involved.

The governance decisions are completely different.

Read, write, delete, and execute should not be treated equally

One of the simplest ways to improve MCP governance is to classify tools by what they allow an agent to do.

A practical hierarchy could be:

Capability	Example	Typical Risk
Read	Retrieve customer record	Lower
Search	Search knowledge base	Lower
Create	Create support ticket	Medium
Modify	Change customer record	Higher
Execute	Trigger deployment	High
Transact	Initiate payment	High
Permission Change	Add user to admin role	Critical
Delete	Delete infrastructure/resource	Critical
Secret Access	Retrieve credential	Critical

This distinction matters because access to data is not the same as authority to change it.

Microsoft's MCP policy-governance model reflects this type of separation by evaluating resource paths and operations such as read, create, update, delete, and action, allowing organizations to apply different policies to different classes of operations.

An MCP access review should therefore not merely ask:

Does the agent need this tool?

It should ask:

Which operations within this capability does the agent actually require?

Least privilege becomes least tool access

The principle of least privilege remains relevant to AI agents.

But MCP introduces another practical interpretation:

Least Tool Access

An agent should receive only the tools required for its approved purpose.

Consider an IT support agent.

Its approved purpose may be:

Diagnose employee account-access problems.

It might legitimately require:

Search user → Read group membership → Check account status → Read authentication logs

It may not require:

Reset MFA → Add administrator role → Delete identity → Create credential

The fact that all of these capabilities are exposed by the same MCP server should not automatically make them available to the agent.

Microsoft's Zero Trust guidance for AI similarly recommends explicit authorization and minimum rights for users, agents, plugins, and callable tools, with stronger approval around irreversible or high-impact actions.

The governance principle becomes:

Do not grant an agent an MCP server. Grant the agent the minimum capabilities required to perform its approved task.

Tool combinations can create risks that individual reviews miss

MCP governance becomes particularly important when an agent can chain multiple tools together.

Consider an agent with three capabilities:

Tool 1: Read supplier information

Tool 2: Modify supplier bank details

Tool 3: Initiate supplier payment

Each tool may have a legitimate use.

Together, they create an entirely different risk.

The same issue appears in identity governance through Segregation of Duties.

For AI agents, an equivalent concept is capability combination risk.

The review should therefore consider:

What can this agent accomplish by combining all of its approved tools?

An agent with:

Read Employee + Reset Password

is different from an agent with:

Read Employee + Reset Password + Add Administrator Role + Retrieve Secret

The risk does not necessarily exist in a single permission.

It emerges from the chain.

This is where Segregation of Duties concepts can begin extending into agentic workflows.

Who should certify MCP tool access?

This is another area where the traditional manager-review model becomes inadequate.

Who understands whether an AI agent should have access to update_payment_instruction?

The agent's business sponsor may understand why the agent exists.

The MCP server owner understands what the server exposes.

The tool owner may understand exactly what the operation does.

The application owner understands the target system.

Security understands the risk.

The appropriate certifier therefore depends on the capability.

MCP Capability	Potential Certifier
Read-only knowledge retrieval	Agent/business owner
Application data access	Application or data owner
Write/update operation	Application owner
Financial transaction	Business/process owner
Privileged administration	Security/IAM + resource owner
Secrets retrieval	Security/platform owner
Identity modification	IAM/security
Destructive operation	Resource owner + security

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

For example:

Agent Owner → Tool/Application Owner → Security for Critical Operations

Not every tool requires three certification levels.

The depth of review should increase with the consequences of the capability.

MCP server approval and MCP access certification are different controls

This distinction is important.

An enterprise might approve an MCP server because it is trustworthy, properly authenticated, maintained by an approved publisher, and suitable for enterprise use.

That answers:

Can this MCP server exist in our environment?

It does not necessarily answer:

Should Agent A be able to invoke Tool X through that MCP server?

Microsoft's Agent Tools model currently provides centralized visibility, registration, approval, rejection, and blocking of MCP servers. That is useful governance at the server level.

Identity governance adds another layer:

Server Governance

Is this MCP server approved for enterprise use?

Tool Governance

Which capabilities exposed by this server are permitted?

Agent Access Governance

Which agents may invoke those capabilities?

Runtime Authorization

Is this particular invocation permitted right now?

These controls complement each other.

They should not be collapsed into a single "MCP approved" checkbox.

Runtime authorization and periodic certification solve different problems

Access review is not runtime enforcement.

Suppose an agent is certified to use a refund tool.

That certification means the organization has determined that the capability remains appropriate.

It does not mean every refund should automatically be permitted.

Runtime controls may additionally evaluate:

• transaction amount
• customer
• environment
• requesting user
• agent identity
• time
• resource
• approval status
• geographic context
• policy
• rate limits

Microsoft Foundry's MCP governance approach, for example, supports routing MCP traffic through an AI gateway to enforce authentication, rate limits, IP restrictions, policies, and audit logging.

The responsibilities therefore divide naturally:

IGA / Access Review

Should the agent retain this capability?

Runtime Policy

Is this particular invocation allowed?

Application

Can the operation be executed on this resource?

Audit

What actually happened?

A mature architecture needs all four.

MCP access should be reviewed when tools change

One important challenge with MCP is that the server itself can evolve.

An MCP server approved six months ago may expose additional tools today.

Suppose the original server exposed:

Search ticket → Read ticket

A new release adds:

Close ticket → Delete ticket → Change assignment

The agent's server-level access has not changed.

Its potential capability has.

This creates an important governance principle:

A material change in the capabilities exposed by an MCP server should challenge existing access decisions.

Useful review triggers could therefore include:

• new tool exposed
• existing tool materially modified
• read tool gains write functionality
• tool begins accessing a new resource
• new sensitive data scope introduced
• new privileged operation added
• MCP server ownership changes
• authentication mechanism changes
• agent receives a new tool
• agent's business purpose changes
• tool becomes unused
• tool risk classification increases

Periodic certification remains useful.

But the calendar should not be the only reason MCP access gets reconsidered.

Usage should influence certification

Suppose an agent has access to twelve MCP tools.

Telemetry shows:

8 tools used regularly
2 tools used once
2 tools never used

That is useful governance information.

The certification campaign can ask:

If this agent has never invoked these tools, are they actually required?

Unused access should not always be automatically removed.

Some capabilities may exist for emergency scenarios or infrequent workflows.

But usage provides evidence.

A useful MCP review can therefore combine:

Granted Capability + Actual Usage + Business Purpose + Risk

For example:

High Risk + Never Used + No Documented Dependency = Strong Revocation Candidate

while:

High Risk + Infrequent + Documented Emergency Purpose = Review and Retain with Controls

This is much stronger than asking the agent owner to approve an inventory of tool names.

Human approval should remain around consequential actions

Not every approved tool needs to operate autonomously.

An organization can certify that an agent is allowed to prepare an action without allowing it to execute that action independently.

Consider:

Agent prepares payment → Human reviews → Human approves → Tool executes

or:

Agent prepares infrastructure change → Engineer approves → Deployment tool executes

This is particularly useful for:

• financial transactions
• account termination
• privilege changes
• production deployments
• destructive actions
• sensitive external communication
• secret retrieval
• high-value purchasing

Microsoft's current AI security guidance similarly recommends fresh approval for high-impact or irreversible operations such as sending, deleting, purchasing, deploying, or changing permissions.

The certification decision should therefore be able to distinguish:

Allowed autonomously

from:

Allowed with human approval

from:

Not allowed

That is a significantly richer governance model than Approve/Revoke alone.

Emergency blocking is different from certification

There is another important distinction.

Certification asks:

Should this access continue?

Incident response may ask:

How quickly can we stop this capability right now?

If an MCP server or tool is compromised, waiting for an access-review campaign is obviously inappropriate.

Organizations need a containment path.

That may include:

Disable Agent → Block Tool → Block MCP Server → Revoke Credential → Terminate Session

Microsoft's Agent 365 model supports centrally blocking an MCP server so agents can no longer invoke it.

That is valuable emergency control.

But broad server blocking may affect many agents and legitimate workflows.

This reinforces the need for more granular governance over time:

Agent → Tool → Action

The more precisely authority is modeled, the more precisely it can be removed.

Audit evidence should reconstruct the complete tool chain

For human access, an auditor may ask:

Why did Rahul have access to Salesforce?

For an AI agent using MCP, the question can become:

Why was this agent allowed to invoke this tool, what operation did it perform, against which resource, under whose authority, and what happened?

The evidence chain therefore needs to become:

Human/User → Agent → MCP Server → Tool → Operation → Resource → Result

A defensible governance record should preserve:

• agent identity
• owner and sponsor
• MCP server
• MCP server owner
• tool
• tool description
• permitted operations
• resource scope
• authentication method
• delegated identity where applicable
• business purpose
• risk classification
• certification decision
• certifier
• reassignment history
• approval requirements
• usage history
• policy decisions
• remediation
• timestamps

This aligns with the broader objective of audit-ready identity governance.

An MCP inventory tells you:

We have 37 MCP servers exposing 412 tools.

Governance should tell you:

Which agents can invoke those tools, why, against which resources, under whose authority, and whether that capability remains appropriate.

MCP tools should become first-class governed assets

This is ultimately the important architectural shift.

IGA traditionally governed:

Identity → Account → Entitlement → Application

Agentic environments increasingly require:

Human → Agent → MCP Server → Tool → Permission → Resource → Action

That does not mean every tool needs to become a traditional entitlement record.

It means the governance platform needs to understand the relationship well enough to answer:

• Which agents have access to this tool?
• Which MCP server provides it?
• Who owns the server?
• What does the tool allow?
• Which resources can it reach?
• Is it read-only or transactional?
• When was it last used?
• Who approved it?
• Is human approval required?
• Does it create a risky combination with another tool?
• Can access be revoked?
• Can the complete action chain be reconstructed?

Citadel Identity360's broader non-human identity governance model provides the foundation for extending these concepts across service accounts, workloads, API identities, and AI agents.

The logical next step is to bring MCP servers and their tools into that same governance graph.

What good MCP tool governance should change operationally

The goal is not simply to maintain a catalog of MCP servers.

It is to make every significant agent capability discoverable, attributable, appropriately scoped, reviewable, enforceable, and removable.

Organizations should expect to:

• maintain a registry of approved MCP servers
• discover the tools each server exposes
• establish ownership for servers and tools
• map agents to MCP servers and tools
• classify tools by capability and risk
• distinguish read, write, transact, administer, and delete operations
• restrict agents to the minimum required tools
• evaluate risky combinations of capabilities
• use stronger certification for consequential operations
• require human approval where appropriate
• incorporate tool usage into certification
• trigger reviews when server capabilities change
• preserve delegated user context
• connect certification with runtime policy enforcement
• support emergency blocking and revocation
• retain the complete agent-to-tool-to-resource evidence chain

The measure of maturity is therefore not:

How many MCP servers have we registered?

It is:

Can we explain exactly which agents can invoke which capabilities, why they need them, what those capabilities can affect, and how quickly we can withdraw that authority?

FAQ

What is an MCP tool access review?

An MCP tool access review is a certification process that determines whether an AI agent should continue to be allowed to invoke particular tools or capabilities exposed through a Model Context Protocol server.

Is approving an MCP server the same as approving its tools?

No. Server approval establishes whether the MCP server itself is permitted within the enterprise environment. Tool-level governance determines which capabilities exposed by that server should be available, while agent-level governance determines which agents should receive those capabilities.

Who should certify an agent's MCP tool access?

It depends on the capability. An agent owner may validate business need, an application or tool owner may validate the technical requirement, and security or IAM may provide additional review for privileged, destructive, financial, identity-changing, or secrets-related operations.

Should every tool exposed by an approved MCP server be available to an agent?

No. Least-privilege principles suggest restricting agents to the minimum tools and operations required for their approved purpose.

Should read and write tools be reviewed differently?

Yes. Reading information typically creates a different level of risk from modifying data, executing commands, processing transactions, changing permissions, retrieving secrets, or deleting resources. Review frequency and certification depth should reflect those differences.

What happens if an MCP server adds a new tool?

A new or materially changed capability can increase the authority of agents connected to the server. Depending on the risk, this should trigger review or require explicit authorization before the new capability becomes available.

Is MCP access review enough to secure tool invocation?

No. Certification determines whether an agent should retain a capability. Runtime authorization must still determine whether each specific invocation is permissible based on identity, resource, operation, context, and policy.

Can MCP tools create Segregation of Duties risks?

Yes. Individually reasonable tools may form a high-risk sequence when combined. For example, an agent capable of modifying beneficiary information and initiating payments may create a toxic capability combination even if each permission has a legitimate purpose separately.

Should consequential tool actions require human approval?

Often yes. Financial transactions, destructive operations, privilege changes, production changes, sensitive communications, and similar high-impact actions are strong candidates for explicit human approval even when the agent is authorized to prepare or initiate the workflow.

MCP tool access reviews ultimately need to answer more than:

Can this agent connect to this MCP server?

They should establish:

Which tools can this agent invoke, what operations can those tools perform, which resources can they affect, who approved that authority, what happens when capabilities are combined, when should human approval intervene, and can the authority be withdrawn immediately when it is no longer appropriate?

That is the standard modern MCP tool access governance should meet.