Auditing MCP server permissions is now core to AI agent security

At a glance

What this is: This is a guide to auditing MCP server permissions for enterprise AI agents, with the central finding that most organisations do not know what their agents can actually access.

Why it matters: IAM, PAM and NHI teams need this because AI agent access now sits on the same governance fault line as service accounts and other machine identities, but changes at machine speed.

Context

MCP server permissions are the access grants that determine what an AI agent can call, read, write or trigger through connected tools, databases and external services. The governance problem is not the protocol itself but the gap between how much access agents accumulate and how little most organisations can actually account for.

For enterprise identity programmes, this is an NHI governance problem first and an AI problem second. The article's core claim is that scoped authorisation, inventory and review now decide whether agentic AI remains controllable or becomes a hidden privilege layer inside production systems.

Key questions

Q: What breaks when MCP servers are left unscoped?

A: Unscoped MCP servers let agents reach more tools and data than their task requires, which turns a small integration into a broad access path. The result is credential exposure, unauthorized data access, and poor auditability. Access scoping has to be explicit, enforced, and reviewable.

Q: Why do over-privileged AI agents create higher business risk than ordinary users?

A: Over-privileged agents can execute many more actions than the task actually requires, so one bad decision can cascade into wrong approvals, refunds, data movement, or API calls. The risk is not just misuse. It is that the agent can act quickly, repeatedly, and without the human timing constraints that limit user mistakes.

Q: What signs show that MCP permissions are too broad?

A: The clearest signs are shared tokens, server-wide access grants, and a lack of tool-level logging or approval separation. If support, engineering, and other teams can all reach the same MCP server but their capabilities are not differentiated, the environment is already over-permissioned. The risk is that one interface masks many different privilege levels.

Q: How should teams govern access when AI agents and service accounts share the same business systems?

A: Treat them as different identity subjects with the same governance obligation. Create one access model that covers ownership, entitlement scope, review cadence, and offboarding across human and non-human identities, then apply role-appropriate controls to each class. The goal is not separate programmes. It is one risk model that can follow access across systems and workflows.

Technical breakdown

Why MCP authorization, not authentication, is the real control point

Authentication only proves that an agent connected to the MCP server. Authorization determines what that agent may do once connected, and that is where the risk sits. In the article's model, agents can be properly authenticated and still hold excessive permissions across tools, APIs, databases and file systems. That makes the authorization layer the actual security boundary, because the harmful action is not the login itself but the ability to invoke production functions beyond the task the agent was meant to perform.

Practical implication: Treat MCP authorization as the primary control surface and inventory every grant that survives beyond the task it was meant to support.

How permission sprawl turns agentic AI into an access problem

The article describes a common pattern: grants accumulate faster than they are removed, so the agent fleet develops permission sprawl. Broad tool access, reused credentials, dormant grants and legacy integrations all widen the reachable set of systems without adding business value. Once that happens, least privilege is no longer a design principle, it becomes a missing control. The technical problem is compounded when multiple agents share the same identity, because attribution, review and revocation all become ambiguous.

Practical implication: Build a permissions matrix that maps each agent to its exact tools, data sources and business justification, then collapse unused grants.

Why context-aware controls matter for MCP-connected tools

RBAC gives consistency, ABAC adds attributes such as environment and data sensitivity, and context-aware policy evaluates request timing, source, sequence and risk. That progression matters because agent behaviour is dynamic: the same request can be benign in one context and dangerous in another. The article's point is that static grants are too coarse for MCP environments where agents can chain tools, move laterally and trigger actions in production. Continuous review only works when policy can see both identity and runtime context.

Practical implication: Use context-aware policy to block risky tool calls when the request path, environment or sequence no longer matches the approved use case.

Threat narrative

Attacker objective: The attacker wants to use the agent's existing MCP permissions to reach data, tools and production actions that the human operator never intended to expose.

1. Entry begins when an attacker compromises or manipulates an AI agent that already has MCP-connected access to internal tools and services.
2. Credential or permission abuse follows when the agent's broad authorization lets the attacker invoke tools, databases or external APIs beyond the intended scope.
3. Escalation and lateral movement occur as the compromised agent uses valid MCP connections and shared access paths to reach other systems without triggering normal alarms.
4. Impact appears as data exposure, unauthorized actions or production changes that look like ordinary agent activity rather than a visible intrusion.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Permission inventory is now the minimum viable governance layer for agentic AI. Once an AI agent can call tools, databases and production workflows through MCP, governance can no longer rely on assumed scope. The article shows that many organisations lack a usable inventory of what those agents can actually reach. The practitioner implication is simple: if the inventory is incomplete, the control plane is incomplete.

Identity without scoped authorization is operationally meaningless for agents. The article separates authentication from authorization in the right place. An authenticated agent can still be dangerously over-privileged, which means identity proofs alone do not bound risk. In NHI terms, this is the same failure mode as any machine identity with standing privilege, except the action rate is machine-speed and the blast radius is larger.

Least privilege for AI agents is not a policy statement, it is a runtime boundary. The article's examples of broad tool access, dormant grants and shared credentials show how quickly permission sprawl outpaces annual review cycles. That means the decisive issue is not whether a policy exists, but whether authorization is continuously enforced against actual tool use. Practitioners should treat agent access as a living authorization graph, not a static entitlement record.

Shadow MCP is becoming the new shadow identity problem. Uncatalogued servers on endpoints and in cloud accounts create an access layer security teams cannot govern if they cannot see it. That is the same structural issue that made shadow IT hard to contain, except the consequence now extends into autonomous tool use and delegated production actions. The implication is that discovery and ownership must move ahead of scale, or the environment becomes unreviewable.

Permission review for agents now sits at the intersection of NHI governance and AI governance. The article correctly ties inventory, review cycles and compliance reporting to frameworks such as NIST AI RMF and ISO 42001. For practitioners, the important point is not the checklist itself but the governance model shift: agent permissions must be provable, reviewable and revocable on the same lifecycle that governs other non-human access.

From our research library:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Ephemeral agent access still needs an authorization boundary. The problem is not that AI agents connect to more systems, but that their tool access often expands faster than governance can review it. Once that happens, access review becomes a lagging record of a privilege state that has already changed.

Permission sprawl is the operational signature of immature MCP governance. When multiple agents share credentials, dormant grants linger and approvals are missing, the issue is not isolated misconfiguration but a broken lifecycle model for non-human access. That is why the governance answer has to combine discovery, revocation and continuous monitoring.

Shadow MCP will increasingly look like shadow identity. Uncatalogued servers and hidden agent connections make it impossible to attribute actions cleanly, which weakens both incident response and compliance evidence. The practical response is to treat MCP discovery as an identity control, not just an infrastructure inventory task.

For practitioners

• Inventory every MCP server and connected agent Build a live register of servers, tools, data sources, owners and linked identities across cloud accounts, endpoints and on-premises systems.
• Remove standing access that is not business-justified Compare granted permissions with actual tasks and revoke tool, database and file access that no longer maps to current use.
• Separate shared credentials by agent Replace multi-agent credential sharing with unique identities so you can trace actions, review grants and revoke access cleanly.
• Move from annual review to continuous oversight Use live discovery, usage telemetry and anomalous access detection so permission changes and new grants are reviewed as they happen.

Key takeaways

• AI agent access through MCP only remains governable when permissions are inventoried, justified and kept under continuous review.
• The main failure mode is permission sprawl, where broad or shared access turns a single compromise or misuse event into wider data and action exposure.
• The control that matters most is scoped authorization backed by live discovery, because annual audits cannot keep pace with agentic tool use.

Key terms

• MCP authorization: MCP authorization is the control layer that decides whether an agent or client may use a specific tool in a specific context. In secure deployments, it must go beyond token claims and incorporate user identity, resource ownership, and policy at request time.
• Permission Sprawl: Permission sprawl is the accumulation of unnecessary or outdated access across identities over time. In cloud and NHI environments, it grows through automation, rapid deployment, and weak offboarding, leaving more standing privilege than the business actually needs.
• Shadow MCP: Shadow MCP is an unauthorized or ungoverned use of the Model Context Protocol inside an organization. It appears when AI agents, scripts, or tools connect to data or actions through MCP servers without security review, inventory, policy control, or monitoring. This creates hidden access paths, data exposure, and weak accountability.
• Context-Aware Authorization: Context-aware authorization evaluates signals such as device posture, time, resource sensitivity, and request type before allowing access. It moves IAM away from static permission checks and toward decisions that reflect current risk, which is essential in cloud-native environments with frequent identity changes.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.