TL;DR: MCP apps are moving into production faster than the surrounding security model, and developers are still defaulting to OAuth alone, according to Pomerium. That leaves context-aware authorization, tool scoping, and request-by-request enforcement as the real gap, not token issuance.
At a glance
What this is: Pomerium’s analysis says MCP app adoption is outrunning security, with OAuth solving authentication but not context-aware authorization or tool-level control.
Why it matters: IAM and security teams need to treat MCP servers like production access surfaces from day one, because token validity alone does not protect tools, data, or infrastructure.
Context
MCP apps are becoming production infrastructure faster than most teams can mature their access controls. The security problem is not whether a user or agent can obtain a token, but whether a request should be allowed at the point of execution when identity, context, and tool scope all matter.
For identity programmes, that shifts MCP from a developer convenience to a governed access surface. Authentication, authorization, auditability, and least privilege now have to apply to non-human identities and agent-driven workflows before the first server is exposed publicly.
Key questions
Q: How should teams secure MCP apps when OAuth is already in place?
A: Teams should treat OAuth as the start of the control model, not the end. A valid token proves identity and scope, but it does not prove that a request is safe in the current context. The practical next step is request-by-request authorization with tool-level policy, logging, and contextual checks before the MCP server executes anything.
Q: Why do MCP servers need context-aware authorization instead of token validation alone?
A: Because token validation only answers whether a credential is acceptable, not whether the request belongs in this session. MCP servers often expose tools that can reach production data or infrastructure, so the decision has to consider device trust, location, time, and session state. Without that context, valid access can still be unsafe.
Q: What breaks when FastMCP exposes every tool to every connected user?
A: Least-privilege design breaks first. If tool listing and tool execution are not separately authorised, any connected client can discover and potentially invoke capabilities that should be restricted by role, context, or resource sensitivity. In practice, that turns an MCP server into a broad permission surface and makes sensitive actions available far beyond their intended audience.
Q: What should security teams do when MCP apps move from prototype to production?
A: They should assume the access model will outgrow the initial prototype quickly and design for logs, role separation, and policy enforcement from the beginning. The right question is not whether the app works, but whether the same control model will still hold when multiple users, tools, and environments are involved.
Technical breakdown
Why OAuth alone is not enough for MCP servers
OAuth answers whether a token is valid and what scopes it carries. It does not evaluate whether a request is safe in the current context, which is the gap Pomerium highlights for MCP deployments. An MCP server can expose databases, file systems, and third-party APIs, so a valid bearer token is only the starting point. The security decision still needs device posture, session state, time, location, and tool-level policy. Without those checks, authentication becomes a yes-no gate that is too coarse for production access.
Practical implication: treat OAuth as identity proof, then add authorization controls that inspect request context before the tool call executes.
Why MCP needs request-by-request authorization
MCP is not just another API surface. It is a tool-execution plane where an agent or client can take action on systems that matter, often outside a VPN and often from hosted environments that cannot join a private network. That means the control point has to sit in front of the server and evaluate each request independently. Identity-aware proxies are a fit here because they can enforce policy before access is granted, rather than assuming a one-time login remains valid for the full session. Tool scoping becomes essential when one authenticated user should not automatically reach every exposed action.
Practical implication: place MCP servers behind a proxy that can enforce per-request policy and per-tool restrictions.
How tool-level policy changes the attack surface
Tool-level authorization narrows what a valid session can do after authentication succeeds. Instead of giving a client or agent blanket access to every tool on an MCP server, policy can limit access to specific functions such as read-only operations while blocking write or delete actions. This matters because the blast radius of an MCP deployment is often defined by the most powerful tool exposed, not by the token itself. Fine-grained authorization is therefore a governance control, not a developer convenience, because it turns a single server into a set of separately governed actions.
Practical implication: classify MCP tools by privilege level and require separate authorization decisions for high-impact actions.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
OAuth is necessary but structurally incomplete for MCP governance. The article shows that token issuance does not answer the harder question of whether an MCP request belongs in the current context. That is an access governance problem, not just an authentication problem, because production MCP servers can touch databases, file systems, and third-party services. Practitioners should stop treating login success as equivalent to safe execution.
MCP turns non-human identity into an application-layer control issue. Once agents and clients can invoke tools directly, the server becomes the policy boundary, not the network perimeter. That means access reviews, audit trails, and least privilege must be enforced at the tool level, where the action actually occurs. Teams that only validate bearer tokens are governing identity too early and too coarsely.
Context-aware authorization is the decisive control plane for agent-driven access. The article’s central lesson is that MCP app security starts with the assumption that any valid token may still be the wrong request. Device trust, location, time, and session state are the variables that make production access safe or unsafe. Security teams should treat MCP as a request-time authorization problem first and a transport problem second.
Identity-aware proxies now function as the governance layer for MCP infrastructure. Pomerium’s framing makes clear that the proxy is not just a convenience for developers who do not want to write auth code. It is the place where authentication, policy, logging, and tool scoping can be enforced consistently across teams and deployments. The practitioner takeaway is to standardize the control point, not the individual app implementation.
MCP app security is collapsing the gap between developer tooling and enterprise access governance. What starts as a personal or team utility quickly becomes shared infrastructure with different roles, logs, and permission boundaries. That is why the secure-by-default model matters: once MCP is in production, governance expectations change faster than code can be refactored. Teams should design for that transition before the first public URL goes live.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
Context-aware authorization is becoming the baseline control for MCP deployments. MCP servers can expose high-impact tools to agents and clients that live outside a private network, so the control point must move to request time rather than login time. Teams that still rely on OAuth scopes alone are governing identity too early and too coarsely for production use.
MCP security is creating a new governance pattern for non-human identity. The practical model is not “authenticate once, then trust the session.” It is continuous evaluation of identity, context, and tool privilege every time an action is requested, which aligns access governance with how agent-driven systems actually behave.
24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption. That figure shows why day-one security matters: insecure defaults in emerging MCP estates can turn into credential exposure before teams have defined lifecycle governance or review processes.
For practitioners
- Implement request-by-request authorization Move MCP access decisions out of the application code path and into a control point that evaluates each request against context, identity, and tool scope before execution.
- Enforce tool-level privilege boundaries Separate read, write, and destructive MCP tools into different authorization tiers so one authenticated session cannot automatically reach every exposed action.
- Add context checks to token validation Use device trust, session duration, location, and time-of-day signals to deny requests that are formally authenticated but unsafe in the current context.
- Place MCP servers behind a policy enforcement layer Front public MCP endpoints with an identity-aware proxy that can authenticate users, validate tokens, log access, and prevent token passthrough.
- Treat prototype servers as future production dependencies Assume that a personal or internal MCP server may become shared infrastructure, then design access controls and logging accordingly from the start.
Key takeaways
- MCP app adoption is moving faster than the security model around it, which makes day-one governance a requirement rather than a later hardening task.
- OAuth helps prove who or what is connecting, but it does not decide whether a request should be allowed in the current context or at the current privilege level.
- The most effective control pattern is request-time authorization with tool-level scope, contextual checks, and an enforcement layer in front of the server.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on why token validity alone is insufficient for MCP access decisions. |
| NHI-05 — Overprivileged NHI | The article warns that authenticated MCP sessions can reach too many tools without fine-grained limits. | |
| NHI-10 — Human Use of NHI | MCP apps let humans and agents invoke non-human access paths that need explicit governance. | |
| Recommendation — Pair authentication with context-aware authorization so MCP requests are not approved on identity alone. Reduce tool blast radius by separating read, write, and destructive MCP privileges. Govern operator and agent access to MCP tools as non-human identity usage, not general user access. | ||
| NIST Zero Trust (SP 800-207) | No implicit trust — No implicit trust | The article argues for continuous verification before each MCP request is executed. |
| Recommendation — Enforce continuous verification at the MCP enforcement point instead of trusting a prior login. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on controlling entitlements at the point of MCP tool execution. |
| Recommendation — Review MCP entitlements at request time and constrain access to only the tool actions needed. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Exposed or overbroad MCP access can be abused to move from a valid token to broader system reach. |
| Recommendation — Map MCP abuse paths to credential access and lateral movement to prioritise enforcement controls. | ||
Key terms
- MCP App: An MCP App is an application that connects to tools, data, or services through the Model Context Protocol. It lets an AI agent request actions or information in a structured way, while the app controls what is exposed, how requests are authorized, and how responses are returned.
- Context-Aware Authorization: Context-aware authorization evaluates signals such as device posture, time, resource sensitivity, and request type before allowing access. It moves IAM away from static permission checks and toward decisions that reflect current risk, which is essential in cloud-native environments with frequent identity changes.
- Identity-aware Proxy: An identity-aware proxy combines routing with authentication and authorization logic. It checks tokens or certificates, applies policy at the edge, and forwards verified identity context to the backend so applications do not have to re-implement security decisions inconsistently.
- Tool-level Authorization: Tool-level authorization is the practice of checking permissions on each discrete action a client asks an MCP server to perform. It matters because LLMs can generate dynamic requests, so access control must be enforced where the action is executed, not only where the request is formed.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org