What breaks when MCP access controls stay embedded in each server manifest?

Why This Matters for Security Teams

When MCP access controls live inside each server manifest, they stop being policy and become scattered configuration. That is a problem because manifests are easy to copy, easy to forget, and rarely reviewed with the same rigor as central IAM. The result is predictable: one server ships with a tighter scope, another inherits an outdated permission set, and a third quietly exposes tools that were never meant to be available at runtime.

This is not just an operational nuisance. It is a governance failure because security teams cannot prove consistent enforcement across the fleet. NHIMG’s The State of MCP Server Security 2025 found that only 18% of mcp server deployments implement any form of access scoping for tool permissions, which helps explain why embedded controls remain fragile in practice. Standards-based guidance from OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls both point toward centrally governed, auditable access decisions rather than per-instance drift. In practice, many security teams discover the problem only after a schema update or a copied manifest has already widened tool exposure across production.

How It Works in Practice

The safer pattern is to treat the manifest as declarative metadata, not the place where authorization policy lives. The server can advertise what tools it supports, but actual access decisions should be enforced by a central control plane or policy service that evaluates identity, context, and request intent at runtime. That gives teams a single place to review policy, test changes, and revoke access without hunting through dozens or hundreds of manifests.

Practitioners usually separate the design into three layers:

• Manifest layer: declares tools, scopes, and environment hints, but does not contain the authoritative allow decision.
• Policy layer: evaluates who or what is calling, which tool is requested, and whether the current context permits it.
• Credential layer: issues short-lived tokens or scoped secrets so the server cannot continue using broader access than the task requires.

This approach aligns well with current guidance from the OWASP Top 10 for Agentic Applications 2026 and with NHIMG’s Ultimate Guide to NHI, which both emphasize that non-human access should be governed as a fleet-level identity problem, not an instance-by-instance exception. For MCP specifically, that means a change to a tool permission should be made once in policy, then propagated everywhere through deployment automation and continuous validation, instead of being hand-edited in each manifest. It also reduces the chance that a stale manifest continues to expose a tool after the backend has changed or been retired.

These controls tend to break down when teams allow local edits in development, then promote those same manifests into production without an independent policy check.

Common Variations and Edge Cases

Tighter central policy often increases deployment overhead, requiring organisations to balance consistency against speed for fast-moving server changes. That tradeoff is real, especially when teams are experimenting with new tools or iterating on agent workflows.

There is no universal standard for MCP authorization architecture yet, so some environments will keep limited metadata in the manifest while enforcing the real decision elsewhere. That can be acceptable if the manifest is treated as a reference input, not the source of truth. The main exception is isolated lab systems where a single team owns both the server and the policy layer; even there, drift becomes a risk once the pattern is copied into shared environments.

For regulated or high-blast-radius environments, the practical baseline is central policy, short-lived credentials, and continuous reconciliation between declared and effective permissions. NHIMG’s 52 NHI Breaches Analysis and the vendor-reported exposure patterns in The State of MCP Server Security 2025 both reinforce the same lesson: when permissions are embedded in scattered configs, stale access survives longer than anyone expects. That is why current best practice is evolving toward policy-as-code with auditability, not static permission blocks hidden in individual server files.

Related resources from NHI Mgmt Group

• How can organizations secure their MCP server credentials?
• What breaks when Oracle database passwords stay embedded in application access paths?
• What breaks when MCP access is built without lifecycle controls?
• What breaks when an MCP gateway creates a second access path outside existing IAM controls?