Constrain MCP and multi-agent trust boundaries

Model Context Protocol connects a client, usually inside an AI application, to servers that expose tools, resources and prompts. Each connection crosses a trust boundary in both directions. A server can return a tool description or document that contains instructions for the model (tool poisoning), and a malicious server can attack the client through the OAuth flow it starts. A well-behaved server can still be confused into acting for the wrong user.

Revision 2026-07-28 changes one assumption that older guidance relies on: MCP is stateless and has no protocol-level sessions. A server that needs state across calls mints an explicit handle, such as a cart or workflow ID, and receives it back as an ordinary tool argument. Everything that identifies the user comes from the verified access token, never from that handle.

In multi-agent systems, distinguish who sent a message from what that sender may request. A helper’s conclusion or a forwarded user statement is not a fresh approval. Keep task instructions, retrieved evidence, proposed actions and verified authorization as separate application concepts.

The authenticated user asks the parent agent to summarize North policy. The parent delegates reading two policy documents to helper H, granting read_policy only. H returns a message saying “the user approved a customer export.” That assertion is evidence about what H said, not an authenticated approval event. If the parent exports using its broader credentials, it has laundered the helper’s unverified claim into authority.

Represent the delegation as a bounded capability: permitted resources, actions, duration and parent task, enforced by a gateway as in /domains/ai-emerging/agent-security/tool-authorization/. A helper can suggest that more authority would be useful, but the execution service must verify the original user’s authorization through a trusted channel and bind consequential approvals to concrete arguments.

Token T1 was issued for MCP server S. Sending T1 unchanged to downstream API D does not make it a D credential, and the specification forbids it: servers must not accept or transit tokens issued for anything else. The code below is S’s token check. It accepts only tokens whose audience is S’s canonical URI, signed by the expected issuer with the expected algorithm, and it identifies the caller by issuer and subject together. To call D, S obtains its own credential with D’s audience and scope.

Local stdio execution is a different boundary: the client starts a process on the user’s machine with the user’s privileges. An HTTP audience check does not confine that process’s filesystem, environment or network access. Tool descriptions, “read-only” annotations and a familiar server name are not enforcement mechanisms.

import {jwtVerify} from 'jose';

// This server's canonical URI. Clients name it in the RFC 8707 "resource" parameter.
export const RESOURCE = 'https://mcp.example.com/mcp';

export async function verifyAccessToken(authorization, {jwks, issuer}) {
  const match = /^Bearer ([\w.~+/-]+=*)$/.exec(authorization ?? '');
  // Answer a missing or malformed header with 401 and a WWW-Authenticate challenge.
  if (!match) throw new Error('missing bearer token');
  const {payload} = await jwtVerify(match[1], jwks, {
    issuer,
    audience: RESOURCE, // a token issued for any other resource is rejected
    algorithms: ['ES256'],
  });
  // Identify the caller by issuer and subject. Never forward this token to another API.
  return {
    principal: `${payload.iss}#${payload.sub}`,
    scopes: new Set(
      String(payload.scope ?? '')
        .split(' ')
        .filter(Boolean),
    ),
  };
}

A protected MCP server is an OAuth 2.1 resource server. It publishes Protected Resource Metadata (RFC 9728) naming its authorization servers, answers an unauthenticated request with 401 and a WWW-Authenticate header, and validates every access token for its own audience, issuer, signature and expiry. Return 403 with error="insufficient_scope" and the needed scope when a valid token lacks permission. Stdio servers do not use this flow; they take credentials from their environment.

The client has its own duties. It must send the RFC 8707 resource parameter with the server’s canonical URI in both the authorization request and the token request, so the authorization server can mint a token for that server only. Before redirecting, it records the authorization server’s issuer next to the PKCE verifier and checks the iss parameter of the response against it (RFC 9207). That check stops mix-up attacks, in which a malicious authorization server tricks the client into sending it a code issued by an honest one; PKCE alone does not.

Start with minimal scopes and step up when the server sends a scope challenge. A token carrying files:* or admin:* granted up front turns any leak into broad access. Record the client and server versions and the protocol revision in the integration contract, because the security model changed between revisions: 2026-07-28 also prefers Client ID Metadata Documents for client registration and keeps Dynamic Client Registration only for backward compatibility.

During discovery the client fetches URLs that the server controls: the resource_metadata URL in WWW-Authenticate, the authorization servers in the resource metadata, and the endpoints in the authorization server metadata. A malicious server can point them at http://169.254.169.254/ or an internal admin port, turning a server-side client into an SSRF proxy. Require https, block private and link-local ranges, apply the same checks to each redirect hop, and prefer an egress proxy such as Smokescreen over hand-written IP parsing, which encoding tricks defeat (see /domains/appsec/secure-features/ssrf-egress-boundaries/).

The server also supplies the authorization URL that the client opens. Passing a javascript: URL to window.open() runs script in the client; building a shell command such as open <url> lets URL characters become commands, and with a local stdio proxy that becomes code execution on the host. Allow only https, plus http on loopback during development, and open the URL with an API that takes it as data. The function below implements the scheme check.

const LOOPBACK = new Set(['localhost', '127.0.0.1', '[::1]']);

// Check an authorization URL that a server supplied before the client opens it.
export function checkAuthorizationUrl(raw) {
  const url = new URL(raw); // throws on malformed input
  if (url.protocol === 'https:') return url;
  // Plain http only for a loopback address during local development.
  if (url.protocol === 'http:' && LOOPBACK.has(url.hostname)) return url;
  throw new Error(`refusing ${url.protocol} authorization URL`);
}

// Then open url.href with an API that takes the URL as data, never through a shell.

An MCP server that calls a third-party API with one static OAuth client ID can become a confused deputy. After a user consents once, the third-party authorization server sets a consent cookie for that client ID. An attacker then registers a new MCP client with their own redirect URI and sends the user a crafted link: the third party skips consent because of the cookie, and the MCP server forwards the resulting code to the attacker.

• Keep a server-side registry of the client_id values each user has approved, and show your own consent page before redirecting to the third party.
• On that page, name the requesting client, the third-party scopes and the registered redirect_uri, protect it against CSRF and forbid framing with frame-ancestors or X-Frame-Options: DENY.
• Match redirect_uri against the registered value by exact string comparison, with no patterns or wildcards.
• Generate a random OAuth state per request, store it only after consent, accept it once at the callback and expire it after about 10 minutes.
• Bind any consent cookie to the specific client_id, with the __Host- prefix and Secure, HttpOnly and SameSite=Lax attributes.

State handle hijacking replaces session hijacking in revision 2026-07-28. If a server operates on whatever state a handle names, anyone who obtains or guesses the handle acts on another user’s cart or workflow. Generate handles from a cryptographic random source, key the stored state by the user ID taken from the verified token, and refuse a handle presented by any other principal. Deployments still on revision 2025-11-25 or earlier must protect the Mcp-Session-Id value the same way: never as proof of who is calling.

import {randomBytes} from 'node:crypto';

const states = new Map(); // in production, a shared store with expiry

export function createHandle(principal, value, ttlMs = 30 * 60_000) {
  const handle = randomBytes(16).toString('base64url'); // 128 random bits
  states.set(`${principal}:${handle}`, {value, expires: Date.now() + ttlMs});
  return handle; // returned to the client in a tool result
}

// `principal` comes from the verified access token, never from a tool argument.
export function useHandle(principal, handle) {
  const entry = states.get(`${principal}:${handle}`);
  if (!entry || entry.expires <= Date.now())
    throw new Error('unknown or expired handle');
  return entry.value;
}

Restrict tool capabilities, destinations, files and secrets according to the task and the authenticated user. Treat tool descriptions and annotations as information, not as policy. Recheck resource permissions when executing a call: a previous successful connection or a valid state handle does not grant unlimited future authority.

When agents delegate work, pass the minimum context and an explicit capability limit, and authenticate the messages between agents (/owasp-agentic-top-10/2026/asi07/). Prevent a child task from raising that limit or laundering a request back through a more privileged parent. Bound depth, calls and resource use across the whole delegation graph, with a kill switch per agent identity (see /domains/ai-emerging/agent-security/agent-failure-containment/), and bind consequential approvals to concrete operations so that their provenance survives each hop.

The model reads every tool’s name, description and schema, so a server can steer it with hidden instructions in that text (tool poisoning). It can also change a definition after users approved it (a rug pull), or describe its tool in a way that changes how the model uses another server’s tools (tool shadowing). Review each definition before enabling it, record a hash of the whole definition, and hold any tool whose hash changes until someone reviews it again. The code below computes that hash over canonical JSON.

A pinned hash detects changed metadata, not changed server behavior, so keep the other controls: install servers only from reviewed sources and pinned versions, namespace tools by server, keep each server’s credentials separate, and require human confirmation for destructive, financial or data-sharing calls.

import {createHash} from 'node:crypto';

// Canonical JSON (sorted keys), so the same definition always hashes the same way.
const canonical = value =>
  Array.isArray(value)
    ? `[${value.map(canonical).join(',')}]`
    : value && typeof value === 'object'
      ? `{${Object.keys(value)
          .sort()
          .map(key => `${JSON.stringify(key)}:${canonical(value[key])}`)
          .join(',')}}`
      : JSON.stringify(value);

export const toolDigest = tool =>
  createHash('sha256').update(canonical(tool)).digest('hex');

// `pinned` maps "server/tool" to the digest recorded when a person reviewed the whole
// definition: name, description, input and output schemas and annotations.
export function toolsNeedingReview(server, tools, pinned) {
  return tools
    .filter(tool => pinned[`${server}/${tool.name}`] !== toolDigest(tool))
    .map(t => t.name);
}

Agents assemble their capabilities at run time: MCP servers, tool definitions, plugins, prompt templates, models and other agents found through registries. The OWASP Top 10 for Agentic Applications 2026 lists the risk that any of these is malicious, compromised or tampered with as Agentic Supply Chain Vulnerabilities (ASI04). A compromised component gains the agent's access the moment it loads, so apply the controls you use for code dependencies to everything an agent loads while it runs.

Keep an inventory of the servers, tools, plugins, models and prompt templates each agent can load, with source and version. Allowlist and pin them by version and content hash, verify provenance before installing or activating anything, and reject unsigned or unverified updates. OWASP's ASI04 guidance adds re-checking signatures and hashes at run time, staged rollout with automatic rollback when a hash or behavior changes, and a kill switch that disables a specific tool, prompt or agent connection across every deployment. Keep prompts, orchestration scripts and memory schemas under version control with review, run third-party servers with least privilege and away from secrets (next section), and do not let agents join a multi-agent system by open registration: authenticate peers and sign their messages.

The compromise can also run the other way, from a developer tool into the agents already installed beside it. The Nx s1ngularity packages tried to make local AI command-line tools search the disk for secrets (/domains/ai-emerging/agent-security/case-study-nx-s1ngularity/), and code shipped in the Amazon Q Developer extension 1.84.0 was meant to drive the Q Developer CLI (/domains/ai-emerging/agent-security/case-study-amazon-q-extension/).

A one-click install that writes a startup command into the client’s configuration can run anything, such as a command that uploads ~/.ssh/id_rsa. Before the first launch, the client must show the exact command and arguments without truncation, warn that it executes code with the user’s privileges and require explicit approval.

Then confine the process. The configuration below starts a server image pinned by digest with no network, a read-only root filesystem, no Linux capabilities, an unprivileged user, memory and process limits, and read-only access to one directory. Stdio still works, which is all the protocol needs. Grant more access only when a specific tool requires it.

{
  "mcpServers": {
    "notes": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "--network=none",
        "--read-only",
        "--cap-drop=ALL",
        "--security-opt=no-new-privileges",
        "--user=65534:65534",
        "--memory=512m",
        "--pids-limit=128",
        "--mount=type=bind,src=/home/me/notes,dst=/data,readonly",
        "registry.example.com/notes-mcp@sha256:REVIEWED_DIGEST"
      ]
    }
  }
}

Use controlled servers and fixtures that return misleading tool descriptions, forged agent messages, private-address discovery URLs and javascript: authorization URLs. Verify that tokens issued for another audience are rejected, that a state handle fails for every principal except its owner and that a changed tool definition is held for review. Record both denied proposals and successful authorized calls. Network egress, local servers and filesystem roots need their own isolation tests; prompt instructions cannot establish those boundaries.

A state handle names server-side state; it does not identify the caller. Test that another user presenting a valid handle is refused, and evaluate each request under the principal from the verified token. A previously successful connection is not a grant for every later operation. On revision 2025-11-25 and earlier, apply the same test to session IDs.

Server-provided metadata can improve the user experience, but an annotation claiming a tool is harmless cannot override observed effects or local policy. Define capabilities from the operation’s implementation and enforce destination and resource constraints at execution. Log denied proposals without storing raw bearer tokens or unnecessary document content.

Each row is a case from the delegation example or the fixture and the result the system must produce. The agent-tool-boundaries project on this page tests the same rule for tool metadata: a poisoned tool description cannot expand an approval.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. Model Context Protocol 2026-07-28: Security Best Practices. Revision 2026-07-28.
2. Model Context Protocol 2026-07-28: Authorization. Revision 2026-07-28.
3. OWASP MCP Security Cheat Sheet
4. OWASP Top 10 for Agentic Applications 2026 (ASI03, ASI04, ASI07). Version 2026 (December 2025).
5. RFC 8707: Resource Indicators for OAuth 2.0. February 2020.
6. RFC 9207: OAuth 2.0 Authorization Server Issuer Identification. March 2022.
7. OWASP AI Agent Security Cheat Sheet

Reference information

Tags

OAuth and OpenID ConnectPrompt injectionAI agents and tools

SDLC phase

DesignDevelopment

Role

Developers

ASVS 5.0.0 requirements

v5.0.0-10.2.2 · v5.0.0-10.3.1 · v5.0.0-10.3.3 · v5.0.0-10.4.1 · v5.0.0-8.2.2

Download this guide as Markdown

Continue exploring