An agent can call a production tool without that action appearing in the identity, endpoint, or conversation logs a security team already monitors. MCP security provides the solution with runtime controls that decide which agents may connect to Model Context Protocol (MCP) servers, which tools they may invoke, and how every call is attributed and logged.
The protocol does not enforce all of those decisions. Authorization is optional in the current specification (2026-07-28). Standard input/output (STDIO) servers retrieve credentials from the environment, while HTTP servers that use authorization still leave policy and audit decisions to the operator.
The difference is whether an agent reaches production directly or through a governed enforcement point.
What MCP security changes
This page gives security teams a production checklist of six controls. Companion pages cover MCP gateway architecture, tool poisoning, prompt injection, and the NSA MCP security baseline.
Why Does the Protocol Leave Enforcement to the Operator?
MCP standardizes tool communication, but organizations still own the security decisions around that communication.
Authorization Is Optional
MCP defines how an agent discovers tools, calls them, and reads the result. Its authorization specification does not require every implementation to authorize those calls.
HTTP implementations that support authorization should follow OAuth 2.1, RFC 9728 Protected Resource Metadata, and RFC 8707 resource indicators. STDIO implementations should not use that flow. They retrieve credentials from the environment.
TLS and SSO Do Not Authorize Tool Calls
A security team may already require single sign-on (SSO) and transport layer security (TLS) at the client. TLS encrypts the channel, but it does not bind a token to a named MCP server or record which tool ran. The specification also forbids token passthrough: An MCP server must not accept a token issued for another audience and forward it downstream.
SSO at session start is also insufficient when the session carries a broad credential into every tool call. That ambient authority creates the failures described by OWASP MCP02 (privilege escalation via scope creep) and MCP07 (insufficient authentication and authorization).
NSA Guidance Extends Traditional Controls
The National Security Agency’s 17-page May 2026 Cybersecurity Information Sheet, Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation, is advisory. It says authentication, authorization, and input validation remain necessary, but agentic MCP introduces risks those controls do not address on their own.
Our operational interpretation of the NSA guidance groups its recommendations into message integrity, per-call scope, verifiable audit records, and explicit trust boundaries.
What Does Production MCP Require?
A security team that will sign off on MCP in production is asking for six countable controls. They map onto the OWASP MCP Top 10 (v0.1, in beta) and onto the NSA baseline.
These are six security controls, not six MCP tools. They operate at two stages: Governance determines which servers may connect, while runtime enforcement checks every tool call.
Six controls across MCP access
- Authentication bound to enterprise identity: Use short-lived tokens issued for a specific MCP server (the RFC 8707
resource) and Proof Key for Code Exchange (PKCE) on the authorization code flow. Do not store long-lived personal API keys inmcp.json. This control addresses MCP01 and MCP07. - An inventory of every MCP server an agent can reach: Include registered servers and those that live only in a laptop dotfile. This control covers the discovery half of MCP09.
- Tool allowlists: Name each approved server, tool, and role. Deny calls that are not on the list. This control addresses MCP02.
- An audit log of every invocation: Record the actor, tool, arguments, result, policy decision, and timestamp. Export these events to the security information and event management (SIEM) system the organization already runs. This control addresses MCP08. The NSA guidance also recommends recording identities, parameters, and cryptographic hashes of results where feasible.
- A kill path for shadow MCP: Find and disconnect unapproved servers, then keep them off the next laptop image. This control addresses MCP09. The broader category is shadow AI.
- Inspection at the tool boundary: Treat tool descriptions, schemas, and results as untrusted input. This boundary is where tool poisoning (MCP03) and prompt injection (MCP06, LLM01:2026) enter the system.
A policy wiki that names these six and a runtime that does not enforce them is the same gap the NSA CSI flags: established cyber defense that does not see dynamic tool invocation.
How Should MCP Authentication Work?
Start with the protocol flow, then bind it to enterprise identity and restrict the resulting credentials.
Follow the HTTP Authorization Flow
For HTTP MCP, the server is an OAuth 2.1 resource server and the client is an OAuth 2.1 client. After a 401 response, the client reads Protected Resource Metadata, discovers the authorization server through RFC 8414 or OpenID Connect Discovery, and runs the authorization code flow with PKCE. Every subsequent HTTP request carries Authorization: Bearer <access-token>, and the token’s audience is the MCP server.
The security best practices document also flags confused-deputy risk when a proxy uses one static client ID for a third-party API and skips per-client consent.
Bind Access to a Person and a Purpose
That is the protocol floor. Production adds three things the spec leaves to the operator:
- A named human. Map the agent session to the employee in Okta, Microsoft Entra ID, or Google Workspace. A service account shared across a team is MCP01 waiting to be copied out of a config file.
- Per-call scope. The NSA least-privilege requirement is that a read of one table does not authorize a write to another. OWASP MCP02 is the same idea from the other direction: temporary permissions that expand.
- No passthrough. If the MCP server calls an upstream API, it uses a token issued for that API. It does not forward the client’s token.
Treat STDIO Credentials as Identity Grants
STDIO servers never enter this flow. They inherit whatever is in the process environment. A coding agent with a production GITHUB_TOKEN in the shell is carrying an identity grant. Those servers belong on the allowlist with a scoped, rotatable secret, or they do not belong on the laptop.
How Do You Inventory Servers, Allowlist Tools, and Log Every Call?
These controls answer three different questions: What is connected, what may run, and what happened?
Inventory Every MCP Server
MCP configurations live in user-space files. They do not install an application, they do not open a well-known port, and they do not appear in a configuration management database (CMDB) the way a sanctioned SaaS app does. Inventory that waits for a software record will report zero servers while fifty engineers have GitHub, Postgres, and a Discord-linked MCP in ~/.cursor and ~/.claude.
Inventory is a client-side problem first. Agent hooks on Claude Code and Cursor see the server name, tool, and arguments at PreToolUse. Mobile device management (MDM) tools such as Jamf, Intune, Kandji, Fleet, and JumpCloud can install that hook configuration and a reviewed server list when a laptop is enrolled. The shadow AI page describes the detection architecture. You cannot allowlist a server you have not named.
Allowlist Servers, Tools, and Roles
Represent the allowlist with three columns:
| Column | What it names | What a miss looks like |
|---|---|---|
| Server | Hostname or package identity, pinned by hash | A rug pull on a server that passed review last quarter (MCP03) |
| Tool | get_customer is allowed; delete_customer is not | Ambient access to every function the server exported |
| Role | Which identity provider (IdP) group may call that tool | An intern’s coding agent with the same GitHub scopes as platform engineering |
A config-file allowlist that a developer can edit is an honor system. Enforce the deny on the path the tool call takes.
Log Every Tool Call
The log is the evidence the security operations center (SOC) and the auditor will actually use. MCP08 asks for tool invocations, context changes, and user-agent interactions, with an immutable trail. A production record, per call, is:
- enterprise identity (user, group, agent client)
- MCP server and tool name
- arguments and result status (redact secrets; do not drop the fact of the call)
- policy decision (allow, deny, step-up)
- timestamp and correlation ID that ties the tool call back to the prompt
Conversation logs from the model vendor cover the chat. They may omit a delete_repository call at 14:03 UTC against the organization’s GitHub organization. The NSA guidance recommends logging tool and model invocations with exact parameters, identities, and cryptographic hashes of results where feasible.
How Do You Close Shadow MCP?
OWASP MCP09 names shadow MCP servers: unapproved instances spun up with default credentials, permissive configuration, or unsecured APIs. They are the MCP-shaped slice of shadow AI. Closing them is three operations, in order:
- See them. Hooks plus an MCP registry of what was provisioned. The difference between those two lists is the shadow set, described in shadow MCP.
- Stop them. Disconnect the server, revoke the secret, and refuse the next connection from that client.
- Keep them off the next image. MDM-provisioned agent config with a reviewed catalog. A laptop that ships with the approved GitHub server, and a policy path that ignores an extra URL in
mcp.json, is the durable fix.
A quarterly audit is not a control. The install takes thirty seconds.
When a server may be useful but has not been reviewed, an MCP approval workflow gives the blocked user a path forward and records the evidence, audience, and rationale behind the decision.
How Do You Inspect the Tool Boundary?
Tool descriptions and results originate outside the employee’s prompt, so they need a separate inspection point.
Inspect Metadata Before the Model Reads It
LLM01:2026 Prompt Injection, published August 4, 2026, in the OWASP GenAI LLM Top 10, identifies tool output as an injection channel. MCP06 covers prompt injection through contextual payloads. MCP03 covers instructions hidden in a tool description, schema, or later update. Model-layer classifiers that watch only the user prompt never see tools/list.
Treat tool metadata and tool results as untrusted input. Inspect descriptions and schemas before the model reads them. Pin versions by hash so a mutated description is a different object. Scope the call so a successful injection inherits a narrow grant. Worked examples live on the tool poisoning and prompt injection pages. The requirement here is that those inspections run on the same path as the allowlist and the log.
Test Each Tool for the Lethal Trifecta
Simon Willison’s lethal trifecta is the containment test: private data, untrusted content, and an outbound channel. An MCP tool that can read a customer table and POST to an external URL has all three. An allowlisted tool that holds all three is an exception that should be named and recorded.
Where Are These Controls Enforced?
Governance controls determine which servers may connect. Runtime controls need an enforcement point on every request path.
Put an MCP Gateway on the HTTP Path
When an agent calls a remote tool, the gateway checks identity, evaluates the allowlist, inspects the payload, and logs the decision.
That proxy is an MCP gateway. Architecture, the large language model (LLM) gateway distinction, and vendor comparison live on that page, once the six controls have owners.
The Speakeasy AI Control Plane runs these controls in one place. Agents connect to Speakeasy-hosted MCP endpoints rather than directly to each upstream server. Authentication flows through the identity provider the organization already runs, and policy is evaluated on every call.
Cover Local Tools with Agent Hooks
Agent hooks cover coding-agent clients where STDIO and local tools never reach the HTTP gateway. Every invocation writes a structured event. Comparing unregistered servers with governed ones produces the shadow MCP list.
Keep Existing Systems of Record
Acceptable-use policy stays in governance, risk, and compliance (GRC). Okta stays the IdP. The platform is where the six controls run, which is the gap the NSA guidance and the OWASP MCP Top 10 leave to the operator.
If the current state is fifty mcp.json files and a wiki page titled “AI acceptable use,” the next step is to name the six owners and put an enforcement point on the tool-call path.