Your AI Agent Has More Access Than Any Employee You've Ever Hired

Most security teams can name every human who can reach production. Far fewer can name every tool an AI agent invoked last Tuesday, or what those tools were allowed to touch when they ran. That gap is structural, and it starts at the protocol layer.

What makes MCP different from a normal API integration

The Model Context Protocol (MCP), released as open source by Anthropic in November 2024, standardises how AI agents exchange structured messages with tools and data sources. It is now the de facto standard for that layer.

In a security assessment dated May 2026, analysing the 2025-11-25 revision, the NSA identified what separates MCP from ordinary integrations: it reverses the interaction pattern engineers have spent thirty years securing. In a conventional integration, a client asks a server for data. In MCP, the server frequently queries on the client's behalf - and sometimes executes actions for it.

Three properties compound it. Agents call new tools at runtime rather than following a fixed call graph. One component's output is assumed valid by the next without verification. Long-lived or overlapping context windows leak across tasks.

None of these are bugs to patch at an endpoint, which locates the fix somewhere specific: if the protocol cannot contain the behaviour, the environment running the server has to - what it reaches on the network, what the kernel lets it execute, what leaves the host. Those are properties of the infrastructure you deploy on, whether your own hardware or a PrivateAlps offshore VPS with root access and network policy under your control.

How MCP deployments have actually been exploited

Three documented cases, all cited in the NSA assessment.

Blanket repository access. With the GitHub MCP server, permission arrives at repository level across both private and public repositories rather than scoped to specific repos or operations. Invariant Labs demonstrated the consequence: a compromised tool reads private repository contents and publishes them into a public one, without the user's awareness or intent.

Behavioural switching after install. Researchers introduced a malicious MCP server alongside a trusted one in a WhatsApp MCP agent; connected to both, the client was manipulated by the malicious server's tool descriptions into exposing message data. The timing is the lesson - the malicious server advertised a benign instruction at installation and switched only after its second use. Install-time inspection would have passed it.

Old vulnerabilities in new toolchains. CVE-2025-49596 hit MCP Inspector: unverified input allowed remote code execution through crafted messages, fixed in 0.14.1.

None of the three is fixed by choosing a better tool. Each is contained, or not, by the environment the server runs in - a deployment decision made before any of this reaches you, which is why providers like PrivateAlps treat isolation guarantees as a published specification rather than a support-ticket answer.

Why AI agent permissions break traditional access control

Identity and access management was built around human operators and service accounts holding narrow, reviewable scopes. Agentic workflows do not fit, and the NSA assessment identified why at the protocol level: MCP had no way to exchange role-based access control permissions at instantiation, making access boundaries between tasks or services hard to enforce or even verify.

Some of that has changed, and the change deserves credit. The 2026-07-28 specification, the largest revision since launch, hardens authorization considerably. Clients must validate the iss parameter against the recorded issuer before redeeming an authorization code. Credentials are bound to the issuing authorization server - keyed by issuer, never reused, re-registered when the server changes. Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents. Hard requirements, not best-practice notes.

The same revision removed protocol-level sessions and the Mcp-Session-Id header outright, and deprecated Logging as a protocol feature.

That is coherent engineering - a stateless core scales on ordinary HTTP infrastructure in a way the session model never could - and it is a transfer of responsibility. Akamai's threat research team read it the same way: the update improves the foundation by removing protocol-level risks, and with the protocol going stateless while adding rich UIs and asynchronous tasks, the critical security boundaries now depend entirely on how developers build them.

Authentication is better than it was in May. What an agent may reach once authenticated, what state persists between calls, and what record exists afterwards are now decisions made in your deployment, not guarantees inherited from the spec.

What the NSA recommends for securing MCP deployments

The recommendations converge on one idea: separation must be enforced by the environment, because the protocol will not enforce it.

Agents, plugins, models, and users belong in distinct trust zones. Tools align with data classification, so anything touching regulated information stays segregated. Tool execution gets sandboxed at the OS level with seccomp, AppArmor, or SELinux. Agent processes are denied any file system, model file, or internal network path they do not need - at runtime, not by policy.

Two recommendations constrain where this can run at all. Private data should be processed on a local instance of the MCP server. Outbound connections should pass through a filtering egress proxy - Squid and tinyproxy are named - or an enterprise DLP solution, restricted to specific resource URLs and access methods.

Both assume you control the network boundary and the host. On a managed multi-tenant platform you frequently control neither: you cannot enforce kernel-level sandboxing you do not administer, or audit an egress path someone else configures. This is where provider choice stops being procurement and becomes architecture.

A starting checklist

Inventory every deployed agent and tool with versions and patch history. Scan your networks for servers you did not authorise - MCP servers change ports, so periodic differential scans beat one-off audits. Re-verify tools after installation, not only at it. Log every invocation into your existing SIEM.

The NSA's conclusion is that MCP's security posture depends on implementation discipline rather than protocol guarantees. Until that changes, the boundary you enforce yourself is the only one you can count on.

Common questions

Did the 2026-07-28 specification fix MCP's authorization problems?

Partly. It added hard requirements around issuer validation, credential binding, and client registration, which closes real attack paths. It also removed protocol-level sessions and deprecated Logging, moving state handling and audit trails into the implementer's deployment rather than the protocol.

Where should an MCP server run when it processes private data?

The NSA assessment recommends a local instance of the MCP server, with outbound connections passing through a filtering egress proxy such as Squid or tinyproxy, or an enterprise DLP solution, restricted to specific resource URLs and access methods.