NSA MCP Security Guidance: An Enterprise Implementation Checklist

In May 2026, the US National Security Agency's Artificial Intelligence Security Center released Model Context Protocol: Security Design Considerations for AI-Driven Automation. The publication matters because it treats MCP risk as a system-design problem rather than a collection of malicious prompts. It highlights dynamic tool invocation, implicit trust, context sharing, implementation gaps, and the way weaknesses can compound across an agentic environment.

This article translates that high-assurance perspective into an enterprise implementation and testing checklist. It is not an NSA endorsement of any product, and the guidance is not a certification standard. Organisations should combine it with the current MCP specification, secure software practices, identity controls, threat modelling, and evidence-driven testing appropriate to their own systems.

Treat MCP as an architecture, not a connector

MCP is often introduced as a convenient way to connect models with tools and data. That description is technically useful but security-incomplete. A production path can include the user interface, host application, model, MCP client, one or more servers, tool implementations, downstream APIs, identity providers, secrets, context stores, and external content. Trust does not transfer safely just because each hop uses a standard protocol.

Create an architecture diagram that separates data flow, control flow, and authority. Data may enter through a document and leave through an email tool. Control may move from a user request to model planning to a server call. Authority may be exercised through a service token broader than the user's access. Seeing these lines separately exposes confused-deputy and exfiltration paths.

Inventory every server, including local developer instances and vendor-managed endpoints. Record owner, source, version, transport, tools, resources, prompts, credentials, reachable data, network access, update mechanism, and retirement process. Keep the exact tool definitions observed in each assessment because descriptions and schemas can change behavior.

Define zones by trust and consequence. Separate development from production, public from sensitive data, low-impact retrieval from privileged action, and local processes from remote services. Do not connect every approved server to every agent. An allowlist should express which client may connect to which server for which purpose.

Model failure and change. What happens when a server disappears, returns malformed output, changes its tool list, or is compromised? Does the client fall back to a more powerful tool, retry an action, or preserve poisoned content in memory? Security review should cover lifecycle and degraded states, not only the successful demo.

The MCP server threat-model guide provides a detailed worksheet. The central lesson is simple: securing the endpoint while ignoring the model, client, context, and downstream authority leaves the most important attack paths unexamined.

Establish explicit trust, provenance, and change control

MCP metadata influences model decisions. Tool names, descriptions, parameter schemas, examples, annotations, prompts, resources, and results can all carry attacker-controlled content. Enterprises should not treat a server as trusted merely because it appears in a popular registry, comes from a known package ecosystem, or worked safely during initial review.

Verify source and publisher. Pin packages and images, review install commands, scan dependencies, validate signatures where available, and record the repository and release. For remote services, validate endpoint identity and understand who can alter server behavior outside your release process. A trusted company domain does not prove that every path and deployment is equally controlled.

Snapshot tool definitions and compare them over time. Alert on added tools, broadened parameters, changed descriptions, new outbound destinations, requested scopes, or modified annotations. Require reapproval for consequential changes. This helps detect rug pulls where an initially benign server later changes the instructions presented to the model.

Preserve provenance through the workflow. The agent should know whether content came from the user, a trusted policy, an internal record, a public webpage, or another MCP server. Summarisation must not erase that distinction. A low-trust tool result should not be rewritten as an authoritative instruction for a high-trust action.

Control extension and protocol versions. Reject unexpected capabilities or place them in a restricted compatibility mode. Test downgrade, partial implementation, and unknown metadata. The MCP specification migration guide explains how stateless requests, cache scope, Tasks, Apps, and authorization changes affect this lifecycle.

Finally, maintain a disablement path. Security teams should be able to remove a server, revoke credentials, invalidate cached definitions, stop active tasks, and identify affected users. Practice this before an incident. Trust that cannot be revoked is merely permanent exposure.

Enforce identity and authorization at every consequential hop

Authentication establishes which principal is present; authorization decides what it may do to a particular resource. MCP systems need both at the client-server boundary and again at downstream services. Encrypted transport alone does not prove appropriate authority.

Use distinct, short-lived workload credentials. Bind tokens to the intended audience, validate issuer, expiry, scope, and user context, and prohibit token passthrough. A server should not accept a token minted for another service or forward the user's broad token downstream. Store secrets outside model-visible context and isolate them by server and environment.

Preserve the initiating user's identity. If an agent acts for a user, downstream policy should not see only a platform-wide service account. Bind resource access to the user's tenant and entitlements or issue a narrow delegated grant. Test alternate object and tenant identifiers directly at the server. A model refusal is useful behavior but not proof of access control.

Minimise scopes and separate operations. Prefer purpose-built read, draft, and execute tools over broad manage or arbitrary command capabilities. Use server-side allowlists for resource types, fields, paths, recipients, destinations, and transaction limits. Restrict general URL fetching and filesystem access.

Require trusted, parameter-specific approval for high-impact actions. The interface should show actual target, amount, recipient, and side effect from controlled data. Approval should expire and be bound to one action. Test whether model or tool output can hide, alter, or bypass it.

Review capability composition. A read tool may be low risk alone but dangerous when combined with external send. A code-writing tool plus deployment authority can modify production. Apply policy to the reachable path and constrain which tools can influence one another.

For deeper implementation detail, see AI agent identity and authorization and excessive agency in AI systems.

Validate inputs, outputs, tools, and context

Structured JSON-RPC does not make a tool argument safe. Strings can reach shells, SQL, file paths, URLs, templates, search filters, or administrative APIs. Validate type, length, format, canonical form, and business rules. Use parameterised queries, safe APIs, filesystem sandboxing, egress controls, and resource limits.

Test command and path injection with non-destructive fixtures. Include alternate encodings, traversal shapes, unexpected protocols, redirects, oversized values, and internal destinations. For fetch tools and authorization discovery, defend against SSRF across every redirect and DNS resolution. Prefer established network controls over handcrafted address parsing.

Treat tool output as untrusted input. A server response can contain instructions that attempt to change the agent's goal or invoke another capability. Preserve provenance, label data, minimise context, and prevent low-trust results from overriding policy. Use structured extraction where possible, but remember that structured fields can still contain malicious language.

Test tool poisoning. Place benign instruction canaries in descriptions, schemas, and results in a controlled environment. Observe whether they change selection, arguments, memory, disclosure, or later tool calls. Test several connected servers because one server may manipulate the use of another. The MCP tool-poisoning guide covers shadowing and rug-pull scenarios.

Apply conventional software security as well. Review server code, dependencies, deserialization, input validation, error handling, secret storage, container configuration, and update chain. Sandbox local servers with minimal filesystem and network access. A prompt-injection defence will not stop a vulnerable parser or malicious package.

Control resource consumption. Bound response size, tool calls, retries, concurrency, execution time, recursion, and model spend. Ensure destructive actions are idempotent or reconciled after timeouts. Test malformed streams, partial results, repeated notifications, and unavailable dependencies.

Protect data throughout the agentic workflow

MCP workflows can combine conversation history, system instructions, retrieved documents, user records, secrets, tool metadata, and outputs. The model and every connected server should receive only what the current task needs. Convenience-driven context sharing can silently defeat data minimisation.

Map each data category from source to processing, storage, logs, and deletion. Record region, retention, subprocessors, access roles, and whether data is used for model training. Do this for the actual deployment configuration rather than relying on generic vendor statements.

Redact secrets before content reaches the model or report. Use synthetic canaries to test leakage. Review errors and debug traces, which often reveal tokens and internal details. Protect evidence stores because security transcripts may contain the most sensitive view of an application.

Test tenant and session isolation. Attempt retrieval with alternate identifiers, new sessions, revoked users, and changed roles. Check memory, indexes, caches, task stores, and generated summaries. Deleting the source record may not remove derived context.

Restrict egress and destinations. A model should not be able to encode data into arbitrary URLs, email recipients, search queries, or tool parameters. Combine destination allowlists, data-loss controls where appropriate, user approval, and server authorization. Verify at the actual sink with controlled canaries.

Plan cleanup. Define how to remove poisoned documents, cached definitions, memory entries, active tasks, logs, and credentials. Preserve necessary incident evidence under appropriate access and retention. Then rerun the original test to prove the unsafe path no longer works.

Build monitoring and incident response around actions

A final chat response is not an audit trail. Logs should connect the initiating principal, agent and model version, prompt and tool-definition versions, selected tool, arguments after redaction, approval, authenticated server identity, downstream decision, result, and confirmed side effect. Use durable trace IDs across hosts, servers, queues, and APIs.

Distinguish planned, attempted, blocked, accepted, and impact-confirmed events. This helps analysts prioritise a model that repeatedly proposes unsafe calls even when the server blocks them, while avoiding exaggerated claims that a blocked request caused compromise.

Monitor definition changes, new servers, new tools, broader scopes, unusual call frequency, cross-tenant errors, new recipients, high-impact actions, task fan-out, and resource exhaustion. Baselines should account for workflow and identity rather than treating every tool call equally.

Protect monitoring from the system it observes. An agent or server should not be able to erase or rewrite security evidence. Apply role separation, tamper protection, controlled export, and retention. Redact sensitive values without destroying the ability to reconstruct identity and destination.

Prepare playbooks for a poisoned server, stolen token, malicious local package, cross-tenant finding, unsafe agent action, and runaway loop. Include disablement, credential revocation, task cancellation, evidence preservation, affected-resource identification, communication, remediation, and safe retesting.

Run exercises. Measure whether teams can identify which users and tools were affected, whether a changed definition propagated, and whether a downstream action occurred. Use the gaps to improve logging and ownership rather than assuming the platform dashboard will answer every question.

Convert the guidance into continuous security validation

Begin with inventory and architecture. Approve servers by owner, purpose, source, version, tools, data, identity, and consequence. Draw context, action, and authority paths. Remove or isolate unknown deployments.

Establish provenance and lifecycle controls. Pin trusted components, snapshot definitions, review changes, constrain protocol and extensions, and practise revocation. Treat tool metadata and results as untrusted content even when the server itself is approved.

Implement strong identity. Use audience-bound short-lived credentials, preserve the initiating user, block token passthrough, enforce resource access server-side, and use bounded step-up approval. Reduce broad tools and dangerous capability combinations.

Harden code and deployment. Validate inputs and outputs, sandbox local servers, constrain networks, scan dependencies, protect secrets, limit resources, and make side effects idempotent. Apply normal API and application security alongside AI-specific testing.

Test the connected behavior. Include alternate tenants, wrong audience, poisoned metadata, injected tool results, unauthorised destinations, changed definitions, replay, cancellation, and degraded services. Run multi-turn cases and preserve transcript plus backend proof. Label inferred paths honestly until replayed.

Retest after changes to models, prompts, tools, schemas, servers, identities, scopes, gateways, data, and extensions. A one-time review becomes stale quickly in an ecosystem where definitions and behavior can change independently.

The NSA guidance is valuable because it refuses to reduce MCP security to one control. Enterprises should do the same. The goal is a system where untrusted context can be processed without silently acquiring authority, and where failures produce evidence that engineers can reproduce and fix.

Oxyne supports security validation and deeper red teaming across exposed AI application, API, model-behavior, tool, MCP, and permission boundaries. Review the OWASP MCP testing checklist, learn how to evaluate MCP security vendors, or book a scoped demonstration.