Key takeaways

  • MCP is a protocol, not a security product. Authorization is optional in the specification. If a server you connect does not use it, anything the server can reach is only as protected as that server.
  • For HTTP-based servers the current revision (2026-07-28) builds on OAuth 2.1, protected resource metadata (RFC 9728), resource indicators (RFC 8707), PKCE and issuer checks (RFC 9207).
  • Two rules matter most in practice: a server must accept only tokens issued for it (audience validation), and it must never pass the token it received on to another service (no token passthrough).
  • Ask for minimal scopes first and add more only when needed. Wildcard and all-purpose scopes undo the point of the design.
  • The protocol secures the connection. It does not tell you who the agent is. Give every agent its own identity, a human sponsor and a way to be switched off.
  • NIST's NCCoE published a concept paper on agent identity and authorization in February 2026. No practice guide has been published yet.

What MCP is, in one paragraph

The Model Context Protocol, or MCP, is an open standard that lets an AI application talk to outside tools and data through a common interface. An MCP client (the AI application or agent) connects to an MCP server (a program that exposes tools such as "search tickets", "read this folder" or "run this query"). Instead of writing a custom integration for every pairing, developers write one server per system and any compatible agent can use it. That convenience is why MCP servers are spreading quickly, and why a security review of each one is worth the time.

An MCP server is, in effect, a new door into your systems that an AI model can open. Some servers run on the same laptop as the agent. Others run on the network and are reached over HTTP. The security questions are different for each, and this article focuses on the HTTP case, because that is where several people, several agents and real company data meet.

Authorization is optional, so ask whether it is on

The first thing to know about the MCP authorization specification is that it is optional. The current revision of the protocol is 2026-07-28. It says that when authorization is supported, implementations using an HTTP-based transport should conform to it, while implementations using the local STDIO transport should not and should instead retrieve credentials from the environment. In other words, a server that skips authorization is not breaking the standard. It is making a choice, and you need to know that choice was made.

For a local server this means the credentials come from the environment of the person running it, so the question becomes who installed it and what it can reach. The protocol's security guidance for local servers says that a one-click install must show the exact command to be run and require explicit approval, and that servers should be sandboxed. Treat a local MCP server as software that runs with the user's own rights, because it does.

The sign-in model: OAuth 2.1 and protected resource metadata

For remote servers, the specification says the authorization server must implement OAuth 2.1, the current consolidation of OAuth best practices. The MCP server plays the role of a resource server, accepting access tokens. The client plays the role of an OAuth client. The authorization server, which may be your identity provider, signs people in and issues the tokens.

The server must also publish OAuth 2.0 Protected Resource Metadata (RFC 9728), a standard document that tells a client where to sign in. When a client calls without a token, the server answers with HTTP 401 and a pointer to that metadata. The client follows it, finds the authorization server, and starts the flow. You should be able to see this document at the server's published address. If you cannot find one, the server is not following the specification.

Client registration has also changed. The 2026-07-28 revision says authorization servers and clients should support OAuth Client ID Metadata Documents, where the client uses an HTTPS address as its identifier and the authorization server fetches its details from there. Dynamic Client Registration is now described as deprecated and kept for backward compatibility. For a buyer, the point is simple: an identity provider that can recognize a client by a published, verifiable address is easier to govern than one that lets any client register itself.

Tokens must be made for the server that receives them

The most important idea in the specification is audience binding. The client must send the resource parameter from RFC 8707 in both the authorization request and the token request, naming the MCP server it plans to use by its canonical address. It must do this whether or not the authorization server supports the parameter. The resource indicator tells the authorization server which service the token is for.

On the other side, the specification says MCP servers must validate that access tokens were issued specifically for them as the intended audience. They must only accept tokens valid for their own resources, and they must not accept or transit any other tokens. Invalid or expired tokens must get an HTTP 401 response. A token that was issued for a different service, even one in your own company, must be refused.

Why this matters: without audience checks, a token stolen from one service can be replayed against another. With audience checks, a stolen token is useful only against the one service it was issued for. When you evaluate a server, ask the vendor or developer how it validates the audience claim, and look for the answer in the code or documentation, not only in a sales page.

Tokens must travel in the Authorization header on every request, and they must not appear in the URL query string, where they would end up in logs and browser history.

No token passthrough

Many MCP servers sit in front of another service. For example, a server for your document system may call a cloud storage API on the user's behalf. A tempting shortcut is to take the token the client sent and forward it to the downstream API. The MCP security guidance calls this explicitly forbidden, and the authorization text says the server must not pass through the token it received from the client. The server should obtain a separate token for the downstream call, issued to it for that purpose.

Passthrough breaks accountability and containment. The downstream service cannot tell the difference between a request that came through the server and one made directly with a stolen token, audit logs show the wrong party, and any control that depends on the audience stops working. When you review a server, ask what credential it uses for each system it calls and who issued it.

Confused deputy: proxies and consent

A confused deputy attack happens when a trusted intermediary is tricked into using its authority for someone else. The specification's best-practices guidance describes it for MCP proxy servers that use a static client ID with a third-party authorization server. If the proxy does not ask for user consent for each client that registers, an attacker can register their own client and use an existing consent cookie to obtain an authorization code that the proxy then hands to the attacker.

The guidance says proxies using static client IDs must obtain user consent for each dynamically registered client before forwarding to the third-party authorization server. The consent page must show the client name, the scopes and the redirect address, and it must be protected against cross-site request forgery and framing. Redirect addresses must be matched exactly, and the state value must be single-use. These are details a vendor can answer yes or no to. A server that has never heard of them is not ready.

PKCE and the issuer check

Clients must implement PKCE (Proof Key for Code Exchange) and use the S256 code challenge method when technically capable. They must refuse to proceed if the authorization server's metadata does not advertise PKCE support. PKCE ensures that an authorization code intercepted in transit cannot be redeemed by anyone who does not hold the original secret.

The 2026-07-28 revision adds a firm rule on the authorization response. Before redirecting the user, the client must record the expected issuer from the authorization server's validated metadata. When the response comes back, the client must check the issuer value (the iss parameter, defined in RFC 9207) before sending the authorization code to any token endpoint. If the server advertises that it includes the parameter and it is missing, the client must reject the response. The purpose is to defeat mix-up attacks, where a malicious authorization server tricks a client into sending a code to the wrong place. The specification also says a future revision is expected to make inclusion of the parameter mandatory for servers.

Minimal scopes, with step-up when needed

A scope is a named permission, such as read access to files. The specification tells servers to say in the WWW-Authenticate header which scopes the current request needs, and tells clients to request only what is necessary. When a client later needs more, the server answers with HTTP 403, an insufficient_scope error and the scopes required. The client then asks the user for the extra permission, a pattern known as step-up authorization. Clients must limit retries so a failing request does not loop.

The security best practices list common mistakes: wildcard or all-purpose scopes, and publishing every possible scope in the supported-scopes list. Both lead to tokens that can do far more than the task needs. A server that asks for a single "full access" scope for every user and every tool defeats the purpose of OAuth. For an agent that can be manipulated, small scopes are your last line of defense.

Sessions and requests that go sideways

Two more points from the security guidance are worth checking. Servers must not use sessions for authentication, and session identifiers must be secure, non-deterministic and bound to the user. Clients that fetch OAuth metadata from addresses they did not choose can be tricked into reaching internal systems, so they should require HTTPS and block private and link-local ranges. This guidance is from the 2025-11-25 revision; we did not verify every line in the moved 2026-07-28 version, so check the current page in your own review.

A checklist to use before you approve a server

  • Who publishes it, and can you identify them? Is the source code available for review?
  • Local or remote? A local server runs with the user's rights, so check what the install command does and sandbox it.
  • Does it implement OAuth 2.1 sign-in and publish protected resource metadata?
  • Does it validate that each token was issued for it (audience), and refuse all others with a 401?
  • Does it ever forward the client's token to another service? It should not. Ask what credential it uses downstream.
  • Does the client send the resource parameter and use PKCE with S256, and does it check the issuer on the response?
  • Are scopes small, named by task, and increased only by step-up? Are tokens short-lived and refresh tokens protected?
  • If it proxies a third-party sign-in, does it ask for consent for each client and match redirect addresses exactly?
  • Are requests logged with the agent's identity, the user's identity and the tool called, in a place the agent cannot change?
  • Who owns this connection at your company, and how is it turned off?

The other half: who is the agent?

MCP authorization answers the question "may this client call this server?" It does not answer "which agent is this, and who is responsible for it?" If every agent in your company signs in as the same service account, or worse as the developer who built it, your logs cannot separate a person from a program, and revoking one agent means breaking all of them.

Identity vendors are building for this. Microsoft describes Entra Agent ID as an identity and security framework that extends Microsoft Entra capabilities to AI agents. Agent identities are special identity constructs in Entra ID, and agent identity blueprints act as templates for creating them with consistent policy. The platform supports OAuth 2.0, MCP and agent-to-agent protocols, and Microsoft says it can also be used for agents built on other platforms. Conditional Access, risk detection, governance and audit logging extend to agents. Microsoft's documentation also records a sponsor, for example the user who created an agent in Copilot Studio. Microsoft states that extending Entra security features to agents requires Microsoft Agent 365, so check what your Microsoft 365 plan includes before you design around it.

You do not have to use one vendor to adopt the habit. Whatever your platform, each agent should have a unique identity, a named human sponsor who is accountable for it, an expiry or periodic review date, the least access that works, and a documented way to disable it. When the sponsor leaves the company or changes role, the agent is reassigned or retired.

The large clouds now sell agent platforms, and they are worth knowing when you decide where an agent runs. Amazon Bedrock includes Amazon Bedrock AgentCore for building and connecting agents and Bedrock Guardrails. Google Cloud's unified platform is now documented as the Gemini Enterprise Agent Platform. Microsoft Foundry, formerly Azure AI Foundry, includes Foundry Agent Service, with Microsoft Entra identity, role-based access control and network isolation. Oracle Cloud Infrastructure (OCI) offers OCI Generative AI. A platform can host an agent, but it does not replace the checklist above: you still decide which MCP servers the agent may reach, with which scopes.

Standards work is under way. NIST's National Cybersecurity Center of Excellence published a concept paper, Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization, on February 5, 2026. The public comment period closed on April 2, 2026. It describes a potential project to apply identity standards and best practices to software agents. It is a concept paper, not a practice guide, and we have not found a published guide yet. For now it is a useful statement of the problem, not a set of requirements.

Where to start

Make a list of every MCP server and connector in use or requested, with its owner. Put the checklist above in front of the ones that reach sensitive data first. Move agents off personal and shared credentials onto identities of their own. Then pilot with low-risk tools, as the joint government guidance on agentic AI recommends, before widening access. Our team designs and reviews these connections for clients as part of its cybersecurity work, and the free security assessment is a way to find out how many of these doors you already have open.

Sources

This article is general technical information, not legal or security advice. It summarizes the MCP specification as published at the time of review; specifications change, so check the current revision. Product names are trademarks of their owners and are mentioned as examples, not as endorsements or partnerships. Last reviewed .

Keep reading

Need help with this?

We find out whether everything you run is safe from attackers, then we fix it.

Cybersecurity