MCP app security needs to start on day one

At a glance

What this is: This is a practitioner analysis of MCP app security, with the central finding that OAuth is necessary but not sufficient for production-grade access control.

Why it matters: It matters because MCP servers are now reaching databases, files, APIs, and infrastructure, so IAM and PAM teams need application-layer governance for non-human and agentic access before deployment becomes irreversible.

By the numbers:

• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Pomerium's analysis of securing MCP apps on day one

Context

MCP apps are turning natural-language workflows into production access paths for data, tools, and infrastructure, which means the control plane is no longer just the model or client. The first problem is simple: many teams secure the token, but not the request context, the tool boundary, or the downstream action.

For IAM and NHI programmes, that creates a familiar but sharper failure mode. A valid credential can still carry excessive reach if the server trusts every authenticated request equally, especially when hosted clients, external APIs, and production systems are all in the path. Security has to be designed into the access layer before usage becomes routine.

The article frames the right response as zero trust at the application layer, with identity-aware proxying and per-tool policy enforcement. That is the right governance question for MCP: not whether authentication exists, but whether authorisation still holds when the caller is an app, the action is dynamic, and the target is real infrastructure.

Key questions

Q: How should security teams secure MCP apps in production?

A: Start by putting MCP servers behind an identity-aware proxy that validates tokens, checks context, and logs every request. Then enforce tool-level policy so authenticated access does not automatically grant every capability on the server. Production MCP security is an access-control problem first, and an application problem second.

Q: Why do OAuth scopes fall short for MCP governance?

A: OAuth scopes tell you what a token can do in theory, but they do not decide whether a request is safe right now. MCP environments need context-aware authorization because device trust, location, session age, and tool risk can all change the correct decision. Without that layer, valid access can still be excessive.

Q: What breaks when MCP tools are granted server-wide access?

A: Server-wide access collapses every tool into the same trust level, even when the risks are very different. A read-only function and a destructive function should not share the same authorisation boundary. When they do, the server becomes a broad privilege container instead of a controlled capability set.

Q: How do teams know if MCP access controls are actually working?

A: Look for evidence at the request level, not just at login. Effective controls produce centralized logs, denied unsafe requests, and clear separation between authentication and tool authorisation. If every authenticated session can reach every tool, the control is present in name only.

Technical breakdown

Why OAuth alone does not secure MCP server access

OAuth answers whether a bearer token is valid and what scopes it carries. It does not decide whether the request should succeed in the current context, and that gap matters when MCP servers expose sensitive tools, databases, and internal APIs. In practice, a token can be correct while the request remains unsafe because the client, device, location, session age, or usage pattern is out of policy. MCP security therefore depends on contextual authorization layered on top of standard token validation.

Practical implication: treat OAuth as the authentication layer, then add context-aware enforcement before any MCP tool call is allowed.

Tool-level authorisation in MCP apps

MCP servers often bundle many capabilities behind one authenticated endpoint, which means server access can become tool overreach. Tool-level authorization splits that surface so a user or agent can reach one function without inheriting every other action on the server. This is a control-plane issue, not just a UI issue, because the difference between read-only access and destructive actions must be enforced before execution, not documented after the fact.

Practical implication: classify MCP tools by risk and enforce per-tool policy instead of granting server-wide access by default.

Identity-aware proxying for production MCP

An identity-aware proxy sits in front of the MCP server and evaluates identity, context, and policy before traffic reaches the application. That architecture is important because hosted MCP clients cannot be trusted to sit inside a private network or VPN boundary, and the server must often be publicly reachable. The proxy becomes the enforcement point for authentication, token validation, and centralized logging, while the application focuses on business logic rather than building its own auth stack.

Practical implication: place production MCP servers behind an identity-aware proxy so access decisions are made before the service is exposed.

Threat narrative

Attacker objective: The attacker objective is to turn legitimate MCP authentication into broad, high-value operational access.

1. Entry begins when a developer exposes an MCP server to a hosted client with only basic OAuth protection and no contextual policy enforcement.
2. Credential access or abuse occurs when a valid token is accepted without checking whether the request comes from the right device, location, session state, or tool boundary.
3. Impact follows when the authenticated caller can reach sensitive tools, file systems, databases, or infrastructure with more authority than intended.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OAuth-only thinking is the wrong baseline for MCP governance. OAuth answers token validity, not whether a request belongs in the current operational context. In MCP, that distinction matters because the same authenticated caller may be safe for one tool and dangerous for another. The field should stop treating bearer-token acceptance as equivalent to authorization success, because the governance problem is now request context, not login state.

Tool-level policy is the named concept MCP governance needs. MCP servers are not single-purpose endpoints in practice; they are capability bundles with different risk profiles behind one front door. When access is granted at server scope, the programme inherits avoidable overreach. The implication is straightforward for IAM and NHI teams: authority must be expressed at the tool boundary, not assumed from server authentication alone.

Zero trust is the correct architectural lens for hosted MCP clients. Hosted clients cannot be treated as if they live inside a private perimeter, and VPN assumptions do not survive public client models. That means the control point moves to identity-aware enforcement at the edge, where every request is evaluated before the MCP service executes. Practitioners should view this as an access-design problem, not a deployment detail.

MCP security is exposing a familiar NHI failure mode in a new wrapper. Hard-coded secrets, broad scopes, and late security additions are the same structural mistakes seen in service-account sprawl and workload identity sprawl. MCP simply makes them easier to operationalize because the access path is now conversational and app-driven. The practitioner conclusion is that identity governance must cover protocol-aware non-human access before the tool estate expands.

Access review alone does not solve dynamic MCP risk. Review cadences are useful for standing entitlements, but they do not express whether a tool call is safe in the exact moment it is made. That makes context-aware policy, logging, and centralized enforcement the real governance primitives for production MCP. Teams should align MCP controls with the same rigor they apply to privileged service accounts and other high-reach NHIs.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• Also from our research: 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025.
• For a broader view of non-human identity exposure patterns, see the Ultimate Guide to NHIs for lifecycle and control guidance.

What this signals

Tool-level policy will become the baseline control for production MCP estates. Teams that only validate bearer tokens will discover that authentication is too coarse for mixed-risk tool bundles, especially when hosted clients and external APIs are involved. The next governance step is to align MCP access with the same control discipline used for privileged non-human identities, including request-level logging and explicit capability boundaries.

Identity-aware proxies are becoming the practical enforcement point for public MCP access. Hosted clients cannot live behind a conventional VPN assumption, so control has to move to the edge where identity and context can be evaluated in real time. That shift is likely to push IAM and security teams toward central policy enforcement rather than per-service auth code.

The growth curve for MCP is creating a familiar secret-sprawl problem in a new protocol layer. The governance task is no longer just securing the server, but preventing configuration shortcuts from becoming durable access paths. Pomerium's emphasis on day-one security is a useful signal, but the operational lesson is broader: protocols that move fast tend to outpace human review cycles unless controls are built in early.

For practitioners

• Put MCP servers behind an identity-aware proxy Enforce authentication, token validation, and request logging before traffic reaches the server. This gives you a control point for public clients and keeps policy outside application code.
• Scope access at the tool level Separate read, write, and destructive tools into distinct policy classes so server access does not automatically imply full capability. Map each tool to a risk tier before rollout.
• Treat OAuth as necessary but incomplete Use OAuth for token issuance, then add device trust, session context, and location checks for production access decisions. A valid token should not override an unsafe request context.
• Centralise logs for every MCP request Record who accessed which tool, from where, and under what policy outcome so IAM, security, and audit teams can trace non-human access end to end.
• Retrofit existing servers before scale-out If MCP is already live, place the proxy in front of current servers rather than rewriting application logic. That lets you add context-aware controls without waiting for a rebuild.

Key takeaways

• MCP security fails when teams confuse token validation with actual authorization.
• Hard-coded secrets and broad tool access show that the current MCP adoption curve is already outpacing basic governance.
• Production MCP requires identity-aware proxying, tool-level policy, and request logging before scale makes retrofits harder.

Key terms

• Model Context Protocol: A standard that lets AI apps and agents connect to tools, data sources, and services through a common interface. In practice, MCP creates a new access layer that must be governed like any other production identity path, because the protocol can expose sensitive capabilities if authorization is too coarse.
• Identity-aware proxy: An enforcement layer that sits in front of an application and makes access decisions based on identity, context, and policy before traffic reaches the service. For MCP, it is the practical control point for request validation, centralized logging, and tool access separation.
• Tool-level authorization: A policy model that grants access to specific functions rather than to an entire server or application. In MCP environments, it prevents one authenticated session from inheriting every capability, which is essential when read, write, and destructive operations coexist behind the same endpoint.
• Context-aware authorization: An access decision model that considers signals such as device trust, location, session state, and time before allowing a request. It matters for MCP because a valid token can still represent unsafe access if the surrounding context does not match policy.

Deepen your knowledge

MCP app security and identity-aware proxy design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are moving MCP servers from prototype to production, it is worth exploring.

This post draws on content published by Pomerium: MCP apps are here. Is yours secure on day one? Read the original.