MCP servers are expanding AI agent attack surface and trust risk

At a glance

What this is: This is an explanatory guide on MCP servers and the Model Context Protocol, with the key finding that they shift AI security from simple connectivity to governed access and audit control.

Why it matters: For IAM and NHI practitioners, MCP turns AI integrations into a trust-boundary problem where permissions, visibility, and lifecycle governance must be designed before agent workflows reach production.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Xygeni's guide to MCP servers and Model Context Protocol security

Context

MCP, or Model Context Protocol, defines how AI systems request structured context from external tools and services. The security issue is that the protocol does not remove trust, it relocates it into the MCP server, where access scope, validation, and logging now determine whether AI activity stays governed or becomes operationally unsafe.

For identity teams, that makes MCP an NHI governance problem as much as an application integration problem. Any AI agent, service account, token, or API key behind an MCP workflow must be treated as part of the same access chain, because the model can only act safely if the surrounding identities are tightly scoped and continuously auditable.

The article's starting position is typical for current AI projects: teams want capability first and governance later. That order is exactly what creates blind spots when MCP servers become the policy layer between models, tools, and sensitive internal systems.

Key questions

Q: How should security teams govern MCP servers used by AI coding assistants?

A: Treat MCP servers as privileged trust boundaries, not simple data sources. Security teams should classify each server by the authority it can influence, sanitize any user-generated or third-party content before delivery, and limit the agent’s tool access so malicious context cannot easily become destructive action.

Q: Why do MCP servers increase non-human identity risk so quickly?

A: MCP servers connect directly to enterprise services using credentials such as API keys, tokens, and service accounts, so every new deployment expands the number of identities that can reach sensitive systems. The risk rises quickly when those servers are unofficial, locally installed, and invisible to security teams. That combination turns convenience into unmanaged access.

Q: What do teams get wrong about AI agent access in MCP environments?

A: Teams often focus on the agent interface and ignore the identity objects that actually authorize actions. The common mistake is assuming the protocol replaces credential governance, when in fact it depends on it. If ownership, rotation, and revocation are not defined, the organisation inherits hidden access paths that are hard to audit and harder to remove.

Q: How do security teams decide when an MCP deployment is production-ready?

A: A deployment is production-ready when identity is centralized, access is group-scoped, tool calls are logged, revocation is tested, and sensitive data is filtered before it reaches model context. If those controls are missing, the system may be functional but it is not yet governable.

Technical breakdown

How MCP servers mediate model access to tools and data

An MCP server sits between the model and the external system, translating a request for context into a controlled retrieval or action. That architecture matters because it replaces direct tool access with a policy checkpoint. The server can scope which resources are visible, constrain what actions can be requested, and log the interaction for later review. In practice, the security boundary is no longer the model itself but the server implementation, its permissions, and the trust granted to the surrounding identities.

Practical implication: treat each MCP endpoint as an access-control surface, not just an integration endpoint.

Why MCP security depends on secrets, tokens, and service identity

MCP implementations still rely on secrets, tokens, and service credentials to authenticate requests between agents, servers, and backend systems. That makes the control problem familiar to identity teams even when the workload is AI-driven. If a server exposes broad credentials, or if secrets are reused across tools, the protocol cannot compensate for weak entitlement design. The model may look intelligent, but the failure mode is still classic non-human identity sprawl: too much standing access, too little separation, and weak evidence about what was touched.

Practical implication: scope MCP credentials per tool and per workflow, then review them like any other NHI.

How auditability changes when AI workflows use shared context layers

MCP promises structured interactions, but auditability only exists if every request, response, and permission decision is recorded in a form security teams can reconstruct. Without that, the organisation knows an AI agent acted but cannot prove what data it saw or why it was allowed to act. That is especially important in environments where multiple MCP servers expose code, documents, and operational services. The architecture can improve visibility, but only when logging, policy enforcement, and identity lineage are designed as one control plane.

Practical implication: align MCP logging with IAM and SIEM review requirements before the first production rollout.

Threat narrative

Attacker objective: The objective is to turn a trusted AI integration layer into a path for unauthorized data exposure and unsafe tool use.

1. Entry occurs through a legitimate MCP integration path where the model reaches tools and internal data through an approved server rather than a direct connection.
2. Escalation happens when the MCP server exposes broader context or actions than the task requires, allowing the AI workflow to move beyond its intended scope.
3. Impact follows when the workflow can leak data, misuse tools, or trigger unsafe actions across connected systems without sufficiently granular oversight.

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 governance is really NHI governance in disguise. The protocol changes how context is requested, but it does not change the underlying truth that access is still mediated by identities, secrets, and entitlement scope. Once AI workflows touch internal systems, the governing question becomes which non-human identities can reach which data, through what server, and with what evidence. Practitioners should stop treating MCP as a model feature and treat it as an access boundary.

Context sharing creates a new trust concentration point. MCP servers centralise the decision about what an AI system may see and do, which means a single policy lapse can expand impact across multiple tools and datasets. That makes the server a high-value control plane for attackers and a high-consequence governance point for defenders. The implication is that IAM, logging, and service-to-service authorisation now need to be designed together.

Least privilege becomes harder when the model's request path is dynamic. The request may be predictable, but the downstream tool sequence is not always obvious once the model starts chaining context across systems. That makes static provisioning assumptions weaker than they look on paper. Runtime context privilege: when context access is granted to a model at execution time rather than authored as a fixed workflow, entitlement boundaries must be narrower and more observable. Practitioners should re-evaluate where static role design is silently over-trusting AI workflows.

MCP does not remove secret hygiene pressure, it multiplies it. The article's emphasis on code, dependencies, infrastructure, and CI/CD is a reminder that the security model still depends on standard NHI controls around key rotation, dependency integrity, and deployment pipeline trust. The field should read MCP as a reason to harden identity and secret governance around AI systems, not as a reason to invent a separate security discipline.

AI adoption is pulling identity teams into application security whether they planned for it or not. MCP servers sit at the junction of AI behavior and enterprise control, so mis-scoped access becomes both an architecture flaw and an identity failure. That convergence means practitioners need shared ownership across IAM, AppSec, and platform teams. The programme implication is simple: if MCP is going live, identity governance must be in the design review from day one.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• 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.
• AI Agents: The New Attack Surface report shows that 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented policies to do so.

What this signals

Runtime context privilege: MCP adoption will push identity teams toward finer-grained, request-level governance because static role assignments do not describe what an AI workflow actually does once it starts chaining tools. The operational test is whether you can prove who or what accessed which data, through which server, and for what task.

With 48% of organisations lacking complete audit visibility into AI agent data access, the governance gap is already visible in the control plane, not just in the model. Teams that wait for a mature AI programme before tightening identity and logging will inherit an evidentiary gap they cannot reconstruct after the fact.

For practitioners

• Map every MCP server to an identity owner Assign explicit ownership for the service accounts, API keys, and tokens that authenticate MCP traffic. Require a documented business purpose, a named system owner, and a revocation path for each credential used by the server.
• Split broad MCP functions into narrow trust zones Separate servers by domain, tool class, or data sensitivity so one workflow cannot inherit another workflow's privileges. Limit each endpoint to the minimum action set and avoid shared credentials across unrelated AI use cases.
• Instrument request-level logging for AI context access Record which model or workflow requested context, what data was returned, and which policy decision approved it. Feed those records into SIEM and access review processes so security teams can reconstruct the path after an incident.
• Review secrets and dependencies as part of MCP change control Include package provenance, secret exposure checks, and deployment pipeline controls in every MCP release review. Treat a vulnerable dependency or leaked token as a direct path to tool misuse, not a secondary implementation issue.
• Reassess static privilege assumptions for AI workflows Compare granted access with actual task scope and remove permissions that only exist for convenience. Where the model can chain multiple tools, verify that no single credential can reach more systems than the workflow genuinely requires.

Key takeaways

• MCP shifts AI security into the identity plane because servers, secrets, and scopes now decide what the model can actually do.
• The major operational risk is not protocol failure, but overbroad trust and weak auditability around the MCP server and its surrounding non-human identities.
• Practitioners should harden access boundaries, logging, and secrets governance before agent workflows move from experimentation into production.

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• 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.
• Runtime context privilege: Runtime context privilege is the effective access an AI workflow accumulates while executing a task, based on what data and tools it can reach through the server. It matters because static provisioning often understates the real blast radius once a model starts chaining requests.
• Tool Access Boundary: A tool access boundary is the limit around what external systems an AI agent may query or control. It matters because every integration can expand the agent's privileges, expose sensitive data, and increase the chance of unintended actions if permissions are not tightly scoped.

What's in the full article

Xygeni's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step guidance for building an MCP server with tighter access boundaries and safer request handling.
• Practical implementation advice on logging, validation, and access controls for production AI workflows.
• Security coverage around the code, dependencies, IaC, and CI/CD layers that support MCP deployments.
• The vendor's own explanation of how its tooling fits around MCP without replacing the protocol itself.

👉 The full Xygeni article covers MCP server design, security controls, and implementation details for AI projects.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.