Notifications
Clear all
Topic starter
10/06/2026 12:52 am
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.
NHIMG editorial — based on content published by Pomerium: MCP apps are here. Is yours secure on day one?
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Put MCP servers behind an identity-aware proxy Enforce authentication, token validation, and request logging before traffic reaches the server.
- 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.
- Treat OAuth as necessary but incomplete Use OAuth for token issuance, then add device trust, session context, and location checks for production access decisions.
What's in the full article
Pomerium's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step setup for the `ssh -R 0 pom.run` tunnel and automatic OAuth bootstrap.
- Implementation detail for dynamic client registration, token exchange, and upstream OAuth handling.
- Configuration patterns for fine-grained per-tool authorization across read and write actions.
- Deployment guidance for moving from a prototype tunnel to self-hosted production infrastructure.
👉 Read Pomerium's analysis of securing MCP apps on day one →
MCP apps are here. Are your access controls ready?
Explore further
11/06/2026 2:27 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP app security needs to start on day one
12/06/2026 4:01 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP app security needs to start on day one
