The Model Context Protocol has been the most consequential standardization in the agent ecosystem over the past eighteen months. It replaced thousands of bespoke tool integrations with a common surface, which is mostly good for security because shared infrastructure means shared controls. The catch is that MCP itself is intentionally minimal on authorization, leaving the design choices to server implementers, and the resulting deployments range from rigorously controlled to alarmingly open. This post is about what the rigorous designs look like.
The audience here is teams building or operating MCP servers, either internal ones that expose company tools to agents or third-party ones consumed by agent platforms. The threat model assumes the agent making the call is at best partially trusted and at worst fully compromised, and the authorization layer is the primary defense against arbitrary capability invocation.
What authorization model does MCP actually expect?
MCP itself does not mandate an authorization model. The specification defines the transport, the message format, and the discovery flow, and leaves authentication and authorization to the implementation. The reference implementations from Anthropic and the broader community converged early on OAuth 2.1 with PKCE as the standard pattern for human-delegated access, and on signed service tokens for machine-to-machine access. In practice, MCP servers in 2026 expose one of three authorization surfaces: a static API key, an OAuth-issued bearer token tied to a specific user identity, or a workload identity from the calling agent's runtime. Each has different security properties, and the static API key pattern is the one we recommend retiring. It is the default in most quick-start guides because it is easy to configure, and it is the proximate cause of most of the credential leakage incidents we have seen in MCP deployments this year.
How should user delegation actually work?
User delegation is the heart of agent authorization, and the pattern that works is the same pattern that works for any delegated access: the agent acts as a confidential OAuth client, the user authenticates with the upstream identity provider, and the resulting access token is scoped to the specific permissions the user actually has. The MCP server receives the token, validates it against the upstream provider, and uses the user's identity, not the agent's identity, for authorization decisions. This sounds obvious, and yet a large number of production deployments do the opposite: the MCP server trusts the agent's identity and treats the agent as if it were the user, with whatever permissions the agent's service account holds. This collapses the security model and is the root cause of confused-deputy vulnerabilities that have shown up in several incident reports this year. The fix is straightforward but requires deliberate engineering: pass the user's identity through the entire call chain and authorize against it at the resource layer.
What does scope minimization look like in practice?
Scope minimization for MCP servers is about exposing the smallest set of capabilities that satisfies the use case. The temptation is to expose a few large generic tools, query the database, send an email, run a script, because they are flexible and reduce the number of tool definitions. The security cost is high. A generic database query tool with a SQL parameter is effectively a full read-write database connection delegated to the agent, with whatever filtering the model decides to apply. The minimized version is several narrow tools: lookup customer by ID, get order history for customer, search products by name. Each tool encodes its own access control logic and its own input validation. The development cost is real, but the resulting authorization model is auditable and the blast radius from any single compromised tool is bounded. The teams operating at scale, particularly the financial services adopters, have largely moved to this narrow-tool pattern over the past year.
How are audit trails and accountability handled?
Audit trails for MCP servers need to capture enough context to investigate an incident after the fact, and the bar is higher than most teams initially set. The minimum useful log entry contains the user identity that initiated the agent session, the model version that generated the tool call, the request ID linking the call to its upstream conversation, the tool name and full parameter set, the response or error, and a timestamp. Storage retention should match the regulatory requirements of the underlying data, which often means months or years rather than days. Several enterprise MCP server deployments are now feeding these logs into SIEM platforms with detection rules for unusual tool-call patterns, particularly batch enumeration that looks like data exfiltration. The detection content is still maturing, but the audit foundation is increasingly considered table stakes for any MCP server handling sensitive data.
What antipatterns produce the most incidents?
The recurring antipattern in 2026 is the trust-the-agent design, where MCP servers grant authorization based on the agent's identity rather than the user's, and the agent ends up acting as a confused deputy with permissions broader than any individual user should have. The second antipattern is parameter trust, where servers validate that tool parameters parse correctly but not that they are within the calling user's authorized scope. The third is over-broad credential storage, where MCP servers hold long-lived credentials for downstream APIs and use them indistinguishably across all callers; a compromise of the MCP server then compromises every downstream account. These three patterns together account for the bulk of the MCP-related incidents we have reviewed, and they share a common root: authorization decisions made at the wrong layer of the call stack. The fix in every case is to push identity and authorization decisions to the resource boundary and treat the MCP server as a relay rather than as a trust authority.
How Safeguard Helps
Safeguard maintains an inventory of every MCP server your agents call and runs continuous policy evaluation against your authorization design. Griffin AI maps each MCP server's exposed tool surface, identifies parameter validation gaps, and flags servers that rely on agent identity rather than delegated user identity. Policy gates block deployments that introduce new MCP servers without an authorization model review, and our TPRM scoring evaluates third-party MCP publishers on their auth design, audit logging, and breach response. Reachability analysis on MCP SDK CVEs surfaces issues that affect deployed call paths rather than dormant code, and the zero-day feed catches disclosed protocol vulnerabilities within hours, so your MCP estate stays continuously assessed rather than annually audited.