Notifications
Clear all
Topic starter
07/06/2026 7:59 pm
TL;DR: Remote MCP servers are increasingly acting as the access layer for AI agent workflows, but unauthenticated deployments, hardcoded secrets, and static keys leave no identity boundary or audit trail, according to Clutch Security. OAuth 2.1 with DCR, PKCE, and short-lived scoped tokens shifts MCP from prototype convenience to production-grade identity control, but only if teams treat it as a governance baseline, not a finishing point.
NHIMG editorial — based on content published by Clutch Security: Industry Insights Part 1, Stop Shipping MCP Servers Naked, Why OAuth 2.1 Is Non-Negotiable
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 govern remote MCP servers that expose business tools?
A: Security teams should place remote MCP servers behind an external authorization server, then enforce short-lived tokens and explicit scopes at the protocol boundary.
Q: Why do static secrets create such a large risk in MCP deployments?
A: Static secrets create large risk because they turn every client into a persistent bearer of the same trust.
Q: How can organisations tell whether MCP access is actually being governed?
A: A governed MCP deployment can answer who requested access, what scope was granted, when the token expires, and which tool calls were made under that token.
Practitioner guidance
- Replace static MCP secrets with external token issuance Move remote MCP servers behind an authorization server that issues short-lived access tokens, then eliminate API keys from .env files, JSON configs, and command-line arguments.
- Enforce scope-based tool access at the MCP boundary Define explicit scopes for read, write, and elevated operations, then reject wildcard permissions such as full-access or admin-style tokens.
- Treat client registration as a governed lifecycle event Approve Dynamic Client Registration through the same ownership model used for other non-human identities, including named owners, expiry expectations, and revocation criteria.
What's in the full article
Clutch Security's full post covers the operational detail this analysis intentionally leaves for the source:
- A production-oriented breakdown of how OAuth 2.1 maps MCP servers to external resource-server patterns for remote access.
- Specific treatment of Dynamic Client Registration and why it removes manual client setup from the onboarding path.
- The PKCE requirement in context, including why code interception matters for diverse client runtimes.
- The article's own security posture guidance for moving from local STDIO usage to remote, authenticated MCP deployments.
👉 Read Clutch Security's analysis of OAuth 2.1 for remote MCP security →
Remote MCP servers and OAuth 2.1: are your controls ready?
Explore further
07/06/2026 9:44 pm
Hardcoded credentials in MCP configs are a protocol governance failure, not a setup mistake. MCP servers that ship with baked-in keys, .env secrets, or command-line credentials inherit all the weaknesses of static NHI design without any of the compensating controls. The problem is not just exposure, but permanence: once a key exists as a configuration artifact, it can be copied, reused, and forgotten across environments. Practitioners should read this as a signal that protocol design must assume secret compromise unless identity is externalised and ephemeral.
A few things that frame the scale:
- 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 MCP Server Security 2025.
- MCP deployments are still thin on access boundaries, with only 18% of servers implementing any form of tool-permission scoping, according to The State of MCP Server Security 2025.
A question worth separating out:
Q: Should teams use Dynamic Client Registration for AI agent workflows?
A: Teams should use Dynamic Client Registration when many tools need to onboard quickly, but only with ownership, expiry, and revocation rules attached. The registration process should be treated like any other non-human identity lifecycle event. Without that, onboarding convenience becomes another source of unmanaged access.
👉 Read our full editorial: OAuth 2.1 is becoming the minimum for remote MCP security
