T45: Insufficient Isolation of MCP Server Permissions

Definition

An MCP server granted excessive permissions on the host system or network violates the principle of least privilege at the server process level. If the server is compromised, the attacker inherits permissions far broader than those needed for the server’s defined function. This differs from T3 Privilege Compromise, which focuses on agent roles; T45 focuses on the server process’s own OS-level permissions.

What it looks like in practice

An MCP server deployed to expose a document search tool is launched under the same user account used for system administration, giving it full read-write access to the host file system, the ability to install software, and network access beyond the database it is designed to serve. An attacker exploits a vulnerability in the MCP server process (for example, via a malformed JSON-RPC request) and gains code execution in the server process context. Because the process runs with administrative rights, the attacker immediately has full host control: they can exfiltrate files outside the document search scope, install a persistent backdoor, and pivot to other services on the same host. All of this stems from an initial foothold in the MCP server.

Why it’s dangerous in multi-agent context

MCP servers are infrastructure components that agents depend on for tool and resource access. As MCP servers are increasingly deployed to expose sensitive organisational data and tools to AI agents, the scope of damage from an over-privileged server compromise (the blast radius) grows correspondingly. T43 (Network Exposure of MCP Server) compounds the risk: a server exposed on an unauthorised network and running with excessive permissions combines wide reachability with a broad damage scope. The blast radius of a single server compromise extends beyond the MCP resource scope to the entire host.

Detection signals

An over-privileged server process is detectable before compromise through configuration audits, and its exploitation becomes visible through process behaviour anomalies that exceed the server’s expected resource scope.

The MCP server process’s effective UID matching root or a shared system-administration account rather than a dedicated service account. Run ps -eo pid,user,cmd on the server host or check the container’s process manifest; flag any match against a privileged user list.
A Linux capability audit (getpcaps <pid>) showing capabilities beyond cap_net_bind_service for a server that only needs to serve HTTP. Enumerate granted capabilities at deployment and alert if any unexpected capability is present.
The MCP server process opening file descriptors outside its defined working directories. A file descriptor scan (ls -la /proc/<pid>/fd) or an auditd rule on open() syscalls outside the permitted path set will surface lateral file access.
A new child process spawned from the MCP server’s PID that is not part of the expected process tree (e.g., a shell, a package manager, or a network utility). Process-tree monitoring via auditd execve rules or an EDR (Endpoint Detection and Response) agent will catch unexpected child spawns.
Outbound network connections from the MCP server process to addresses outside the database or API endpoints it is designed to contact. Enforce an egress allowlist in the container network policy and alert on any deny event.

Mitigations

Run each MCP server process under a dedicated, minimal service account with no interactive login rights and no permissions beyond those required to access the specific files, databases, and APIs the server is designed to serve.
Containerise MCP servers with a minimal base image; drop all Linux capabilities not required for the server’s function using container security profiles.
Apply OS-level mandatory access controls (AppArmor, SELinux) to constrain the server process’s file system and network access to its defined scope.
Conduct a least-privilege audit for every MCP server before production deployment; treat any deviation from the minimum required permission set as a blocking issue.

Relation to base threat (T1–T17)

T45 extends T3 Privilege Compromise. Where T3 addresses overly broad agent roles at the application level, T45 addresses the OS-level permissions of the MCP server process itself. T43 (Network Exposure of MCP Server) is the deployment-layer precursor: network exposure grants initial access, while T45’s excessive permissions determine how far the attacker can move once inside.

OWASP Top 10 for Agentic Applications 2026

The Agentic Top 10 (ASI01 through ASI10) is a separate practitioner-facing publication that maps onto the master Threats & Mitigations threat numbering. T45 is covered by the following Top 10 entries:

ASI03 Identity & Privilege Abuse related

When an agent acts on a user's behalf it inherits that user's credentials and permissions for the duration of the task. Attackers exploit this by manipulating delegation chains, role inheritance, or agent-to-agent trust, turning a narrowly scoped instruction into a credential that can chain every permission the principal holds, concurrently, in a single agent turn.

OWASP LLM Top 10: LLM06:2025 LLM01:2025 LLM02:2025

Source: OWASP Top 10 for Agentic Applications 2026 (Dec 2025) · the Top 10 is a compass into the master Threats & Mitigations taxonomy, not a replacement for it.

Design principles at stake

When T45 is present, these security design principles are the ones being violated or tested. Each links to the full principle; the mitigations below are how you restore them.

Defence-in-Depth Network-level exposure (T43) grants initial access to the MCP server; what T45 determines is how far the attacker can move once inside. Running the server process under an administrative account means the depth collapses at the first layer: there is no second boundary between the MCP resource scope and full host control. Depth here means the server process is itself a constrained layer: a dedicated minimal service account, container security profiles that drop unnecessary Linux capabilities, and OS-level mandatory access controls (AppArmor or SELinux) each independently limit what a process-level compromise can reach. A pre-deployment least-privilege audit treats any permission beyond the minimum required as a blocking issue before the server is promoted to production.
Least Privilege An MCP server launched under an administrative account holds a standing grant to the entire host file system, software installation, and network access well beyond its defined scope: so an attacker who gains code execution in the server process inherits that full grant immediately, with no further escalation required. Least privilege counters this by confining the server process to a dedicated minimal service account with no interactive login rights and no permissions beyond the specific files, databases, and APIs it is designed to serve. Containerisation with a minimal base image and dropped Linux capabilities enforces the same boundary at the OS layer, so even a successful exploit yields only the narrow footprint the server legitimately needs.

Recommended mitigations

Auto-generated from the mitigation catalog: every mitigation whose coverage map includes T45, sorted by maturity tier (Tier 1 production-canonical first, then Tier 2, then Tier 3 research-stage).

Tier 1 gVisor (gVisor sandbox — a user-space kernel that intercepts every syscall a container makes)

When an agent executes generated or retrieved code, that code runs as a process with access to the host kernel. A vulnerability in the generated code, or a deliberate exploit injected through the agent's prompt, can reach the kernel and affect other workloads or the host itself. gVisor prevents this by inserting a user-space kernel implementation between the container and the host: the container's syscalls go to the Sentry process, not to the host kernel, so the reachable attack surface from inside the container is structurally smaller.

why it helps Insufficient MCP server permission isolation at the execution layer means agent tool code can access host resources or peer-agent state beyond what its scoped tool is permitted. Running each agent's tool code inside a gVisor sandbox enforces that boundary at the kernel interface: the Sentry mediates every resource access, and the host grants only what the sandbox policy allows.
Tier 2 Cross-client isolation (Cross-client isolation — request-scope tenant boundaries in shared MCP server deployments)

A shared MCP server that accepts connections from multiple clients is a concentration point where one client's session state, credentials, and resource budget are physically co-located with every other client's. Without enforced isolation, a malicious or compromised client can read another session's cached credentials, consume shared resources to the point of denying service to other clients, or exploit aggregate server permissions that exceed its own declared scope. Cross-client isolation is the set of structural controls that close those paths: per-session state scoping, per-client permission evaluation, and per-client resource quotas enforced at the server layer.

why it helps Insufficient isolation of MCP server permissions is the named threat. Per-client permission scoping, where each client's tool calls are evaluated against that client's declared permission set rather than the server's aggregate permission set, is the direct structural mitigation.
Tier 2 RBAC/ABAC (RBAC and ABAC: role-based and attribute-based access control for agents)

Role-Based Access Control (RBAC) assigns every agent identity a named role that sets the outer limit on what it can reach. Attribute-Based Access Control (ABAC) narrows individual decisions inside that role by evaluating contextual attributes at request time. Used together, they enforce least privilege for non-human identities: the agent can only do what its role permits, and only when the request attributes satisfy the policy.

why it helps Overly broad MCP server permission scoping lets a single client accumulate the server's full permission set. RBAC/ABAC decisions evaluated per request ensure that each client receives only the subset its role permits: the server's aggregate permissions are never forwarded wholesale to any caller.

Multi-agent variants: OWASP MAS Guide

The OWASP OWASP MAS Threat Modelling Guide v1.0 catalogues 1 named multi-agent variant of T45, anchored to specific MAESTRO layers. Each is a concrete attack pattern that emerges when this threat compounds across agents.

CL Cross-Client Inference Interference extends T42, T45, T28

Shared inference infrastructure (T42: side-channel) allows a tenant to observe timing or cache patterns from a co-tenant session (T45: session isolation failure); incomplete sandboxing (T28) lets the attacker infer private prompt content across clients.

Source: OWASP MAS Threat Modelling Guide v1.0, §2 Overview of MAESTRO Framework — Extended Threat Scenarios + Cross-Layer table.

Red-team pivot: MITRE ATLAS techniques

MITRE ATLAS catalogues adversary techniques against AI systems. Where this OWASP threat has an attacker-perspective counterpart, the ATLAS technique is shown below. That is what a red team would actually be doing on the wire. Use this for detection-signal anchoring, threat-hunting hypotheses, and IR runbooks. Source: mitre-atlas/atlas-data v5.6.0.

AML.T0012 Valid Accounts view on ATLAS ↗

Adversary obtains and abuses legitimate user or service credentials for initial access, persistence, privilege escalation, or defence evasion.

Agentic angle: Agents often run under long-lived service accounts whose blast radius exceeds the original task scope.

AML.T0055 Unsecured Credentials view on ATLAS ↗

Adversary discovers credentials stored in plain configuration files, environment variables, or model context where they should not be exposed.

Agentic angle: Agent configuration files (system prompts, tool descriptors, MCP manifests) are a fresh credential exposure surface.

AML.T0098 AI Agent Tool Credential Harvesting view on ATLAS ↗

Adversary uses access to an AI agent to retrieve credentials stored in or accessible through the agent's connected tools: document stores, code repos, productivity platforms.

Agentic angle: Agent tools aggregate credentials from many integrated services; harvesting them grants lateral movement across the victim's entire connected toolchain.

References

OWASP MAS Threat Modelling Guide v1.0 (April 2025) §5 Anthropic MCP — Layer 6 Security and Compliance.

Sources

OWASP-MAS-Guide ↗ · 1.0 (Apr 2025) · §5 Anthropic MCP — Layer 6 Security and Compliance