MCP security exposes the weak link in AI agent access control

At a glance

What this is: This article argues that MCP shifts AI risk from the prompt layer to the execution layer, where weak tool boundaries and URI handling can expose credentials and enable system compromise.

Why it matters: IAM, PAM, and NHI teams need to treat AI agents and MCP servers as governed identities because tool access, delegated authority, and environment scoping now determine blast radius.

By the numbers:

• A scan of 7,000+ MCP servers found that 36.7% shared this exact flaw.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read AppSOC's analysis of MCP security risks and AI agent access control

Context

MCP, or Model Context Protocol, connects AI agents to tools and data sources, which makes it an identity and authorisation problem as much as a model problem. In practice, the issue is not whether the model can be persuaded to say something unsafe, but whether the agent can be made to take unsafe actions through trusted connectors and delegated execution.

For IAM and NHI programmes, the key gap is that tool access often looks like ordinary application integration while behaving like runtime privilege. Once an agent can invoke file operations, repository actions, or metadata endpoints, the control plane must handle that identity like a governed non-human actor, not a simple API client.

The article’s starting position is typical for fast-moving agentic AI deployments: capability is arriving faster than boundary design. That makes MCP security a governance problem for the entire identity stack, not a niche concern for AI teams alone.

Key questions

Q: How should teams govern AI agents that use MCP?

A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle. The practical control set is familiar: least privilege, secret rotation, access expiration, and auditability across the systems the agent can reach.

Q: Why do MCP-based agents create more risk than ordinary API integrations?

A: Because the agent is choosing actions, chaining tools, and preserving context across steps. Ordinary API controls assume predictable request patterns, while MCP can turn one legitimate session into a route for data exposure or privilege escalation. The risk increases when identity, context, and tool access are not governed together.

Q: What do security teams get wrong about AI access risk?

A: Many teams focus on the model while ignoring the identity path that reaches it. If a service account or token can invoke AI infrastructure, then that credential becomes the real control point. The mistake is treating AI risk as a model problem instead of an access governance problem.

Q: How do security teams know whether MCP server governance is working?

A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact. If those answers are unclear, governance is not working. The signal is not just fewer alerts, but clear attribution and scoped access across the fleet.

Technical breakdown

Why MCP turns prompt risk into execution risk

MCP is a protocol layer that lets agents call tools, fetch context, and execute actions across systems. That means the security boundary moves from text generation to runtime authorisation. A prompt injection becomes more dangerous when it can influence a tool call, because the agent is no longer just producing output, it is exercising delegated capability. In that model, the important question is not whether the model was fooled, but whether the tool boundary prevented the resulting action from crossing into sensitive systems or secrets stores.

Practical implication: treat every MCP tool as a separately governed entitlement with explicit scope, not a generic extension of the agent.

How SSRF and repository abuse become identity failures

The examples in the article show two common failure modes. A tool that can write to sensitive directories can expose private keys, while a tool without URI restrictions can be coerced into server-side request forgery against cloud metadata endpoints. Both are identity problems because the attack succeeds only when the agent inherits enough privilege to reach protected resources. The weakness is not just code execution, it is the absence of context-aware restriction on what the agent is allowed to touch, where, and under which trust boundary.

Practical implication: constrain tool destinations, filesystem paths, and cloud metadata access at the identity layer, not only in app code.

What access scoping means for MCP servers

Access scoping in MCP is the difference between a general-purpose agent and one that can only reach approved tools in approved environments. The article’s defence-in-depth model is effectively a policy stack for agentic identity: authenticate the caller, authorise the tool, limit the environment, and observe the runtime behaviour. Without that stack, an MCP server becomes a privileged deputy that can be redirected into actions the operator never intended. This is why MCP governance belongs in the same conversation as PAM and NHI lifecycle control.

Practical implication: define tool, environment, and session scopes together so an agent cannot move from low-risk tasks into production-sensitive actions.

Threat narrative

Attacker objective: The attacker aims to turn a trusted AI assistant into a privileged execution path that exposes secrets, cloud credentials, or controlled system actions.

1. Entry occurs when an attacker uses prompt injection or a malicious input path to influence a trusted AI agent through an MCP-enabled workflow.
2. Escalation follows when the agent is induced to call a tool with excessive reach, such as a repository action, file operation, or metadata endpoint request.
3. Impact is credential exposure, sensitive file access, or broader system compromise once the tool executes with delegated privileges.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP creates a runtime authorisation problem, not just a model safety problem. Prompt filters only address what the model says. They do not govern what the agent can do once it holds delegated tool access, which is where the real compromise path begins. Practitioners should treat MCP as part of the identity control plane, not as a content safety layer.

Privilege has to be scoped at the tool boundary or it does not really exist. The article’s examples show that a single unconstrained connector can expose private keys, cloud metadata, or destructive repository actions. This is why least privilege for AI agents must be expressed per tool, per environment, and per session, with no assumption that the agent will stay within the original task.

Shadow MCP is becoming the agentic equivalent of Shadow IT. The article notes that thousands of MCP servers are already visible on GitHub, which means discovery is now a governance prerequisite. If teams cannot inventory agent connectors, they cannot certify their blast radius, validate ownership, or enforce offboarding when a tool is retired.

The named concept here is execution-layer trust debt: organisations accumulate risk when they extend agent access faster than they design runtime boundaries. That debt shows up as permissive tools, weak URI handling, and overbroad environment reach. The implication is that identity teams must measure how much delegated power remains unchecked after the prompt has been accepted.

Agentic AI does not replace NHI governance, it intensifies it. MCP-linked agents still rely on secrets, tokens, and scoped access, but now those credentials can be exercised dynamically and recursively by software at runtime. That means NHI policy, PAM, and lifecycle controls must expand from static provisioning to behavioural containment.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• MCP security fits the broader pattern in 52 NHI Breaches Analysis, where uncontrolled non-human access becomes the fastest route from exposure to impact.

What this signals

Execution-layer trust debt: most organisations are still treating AI agent access as a software integration problem, even though the real control point is delegated privilege. With only 18% of MCP server deployments implementing access scoping, the next governance gap is not discovery alone but whether policy can keep pace with tool chaining and runtime context shifts.

For identity teams, MCP should now sit alongside workload identity, secrets management, and PAM in the same review cycle. If an agent can invoke tools without narrow environment scoping, the programme has already lost sight of where machine-to-machine authority begins and ends. That is exactly the kind of boundary collapse that links strongly to the patterns in Analysis of Claude Code Security and the OWASP Agentic AI Top 10.

For practitioners

• Inventory every MCP server and connector Build a continuous discovery process for all MCP servers, agent processes, and third-party connectors so shadow deployments do not bypass governance. Include ownership, data access, and environment reach in the inventory.
• Scope every tool to a narrow trust boundary Write authorisation rules for each MCP tool, including allowed operations, allowed destinations, and allowed environments. Block repository writes, metadata endpoints, and filesystem paths that the task does not explicitly require.
• Separate agent identity from human credentials Use delegated, task-scoped credentials for agents rather than sharing human secrets across tool chains. Apply short-lived access, explicit revocation, and clear ownership so the agent cannot inherit more privilege than intended.
• Add behaviour-based detection for abnormal tool use Monitor for SSRF patterns, unexpected outbound calls to internal metadata IPs, and tool usage that diverges from the expected task flow. Alert on runtime actions that indicate scope drift rather than waiting for a prompt-layer detection.

Key takeaways

• MCP turns AI agents into delegated executors, so the real control problem is runtime authorisation rather than prompt hygiene.
• The evidence points to a large governance gap, with insecure MCP implementations exposing secrets, cloud metadata, and overbroad tool reach.
• Practitioners need continuous discovery, narrow tool scoping, and behaviour-based detection before agentic access becomes normalised.

Key terms

• Model Context Protocol: Model Context Protocol is an open standard for connecting AI agents to tools and data sources. In security terms, it creates a runtime execution boundary that must be governed like delegated access, because the agent can act on systems beyond the prompt itself.
• Interaction-layer trust: The degree to which a security decision depends on what a session actually does, not just what it claims to be. In challenge systems, this means using timing, sequencing, and behavioural evidence to validate intent when browser metadata can be spoofed.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Delegated Execution: Delegated execution is when software is allowed to perform actions on behalf of a user, process, or business function. In NHI governance, the risk is that the delegated actor may chain actions beyond the original intent, so controls must focus on scope, approval, and revocation.

What's in the full article

AppSOC's full blog post covers the operational detail this post intentionally leaves for the source:

• The article’s step-by-step 7-step defence model for MCP environments, including discovery, authentication, and authorization.
• Specific examples of how adaptive guardrails and AI-DLP fit into an agentic security stack.
• The article’s discussion of observability-based threat detection for MCP sessions and metadata endpoint abuse.
• The open-source risk knowledge base concept for tracking weak MCP implementations and known CVEs.

👉 AppSOC's full post covers the Anthropic and Microsoft examples, the 7-step defence model, and the runtime controls it recommends.

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.