Why do MCP servers need runtime governance as well as secret hygiene?

Why runtime governance is the missing half of MCP security

MCP servers sit at the point where an agent turns a capability into an action. Secret hygiene limits who can authenticate in the first place, but it does not decide whether the request itself is appropriate, within scope, or safe for the current context. runtime governance is the control layer that evaluates intent, tool use, and policy at the moment of execution.

That distinction matters because MCP workflows can still fail after a valid login. A credential may be well protected, rotated, and scoped, yet the server can still accept a request that is too broad, too destructive, or too loosely tied to the original user intent. The MCP authorization specification shows why the protocol needs explicit server-side authorization, not just transport or secret controls.

At a practical level, runtime governance covers decisions such as whether a tool call should be allowed for this tenant, this user, this agent, this data set, and this time window. That is a different problem from storing secrets safely. The first protects the boundary around the action, while the second protects the material used to enter that boundary.

What secret hygiene does, and what it cannot do

Secret hygiene reduces the chance that an MCP server or client leaks an API key, token, or other credential. Good hygiene includes short-lived credentials, rotation, vaulting, and limiting where secrets are stored or copied. It lowers the likelihood of theft and makes exposed material less useful over time.

However, even perfect secret handling does not stop abuse by a legitimate principal. If an agent already has valid access, it can still make unsafe calls, overreach into adjacent data, or chain a sequence of tool requests that exceeds the original purpose. That is why a secret-free or secret-minimised design is helpful but incomplete on its own, especially where the Secrets Management Guide emphasises rotation and secretless patterns rather than treating storage hygiene as the end state.

In MCP environments, the stronger pattern is to separate authentication from authorisation and then re-check the request at runtime. Secret hygiene reduces exposure before access is granted. Runtime governance reduces blast radius after access has already been granted.

How runtime governance constrains safe use after access is issued

Runtime governance is the policy enforcement layer for use, not just possession, of access. It can bound which tools are reachable, which resources are in scope, which prompts or arguments are acceptable, and which requests require escalation or human review. This is the control that helps prevent a valid session from becoming an unsafe session.

For MCP specifically, that often means inspecting the call path for confused-deputy conditions, token passthrough, overbroad tool permissions, and requests that cross environment or tenant boundaries. The MCP Security Guide is useful here because it ties authorisation design to real MCP failure modes such as tool poisoning and gateway enforcement. Runtime governance is where those failures are actually stopped.

It also matters when the agent is acting on behalf of a human. The original user may intend a narrow action, but the agent may have enough authority to do much more. In that case, governance must verify not only that the agent is authenticated, but that the action still fits the delegated scope and the current policy state. The OAuth 2.0 Protected Resource Metadata model is relevant because it supports explicit resource and authorisation discovery rather than blind trust in a token alone.

Risk and Threat Considerations

When MCP servers rely on secret hygiene alone, the remaining risk is authorised misuse rather than simple credential theft. That creates exposure to overprivileged tool calls, confused-deputy behaviour, accidental data disclosure, and chained actions that stay within authentication rules but violate policy.

Failure mechanism: A valid agent session can keep working after a secret has been protected or rotated, so the attacker or careless automation does not need to steal the credential if they can operate inside an already authenticated path.

Impact: The blast radius extends from stolen secrets to unsafe execution, which can mean unwanted data access, destructive actions, or cross-boundary operations that are harder to detect because they look authenticated.

Practitioner Guidance

What to prioritise: Treat MCP as an execution boundary, not a credential storage problem. If a server can perform side effects, the question is whether each request remains policy-compliant at the moment it is made.

What to verify: Check that the server enforces request-time authorisation on tools, scopes, tenants, and environments, and that a valid credential cannot automatically unlock every available operation.

Decision rule: If the control only reduces secret exposure but does not evaluate the action itself, it is hygiene, not runtime governance, and it should not be treated as sufficient.

Common mistake: Teams often stop at vaulting, rotation, and token scoping, then assume the protocol is safe. That leaves a legitimately authenticated agent free to make unsafe or unintended requests.

Practitioner takeaway: MCP security is strongest when issuance and use are governed separately, because the real failure is often not secret theft, but authorised execution beyond intent.

Practitioner Guidance

What to prioritise: Treat MCP as an execution boundary, not a credential storage problem. If a server can perform side effects, the question is whether each request remains policy-compliant at the moment it is made.

What to verify: Check that the server enforces request-time authorisation on tools, scopes, tenants, and environments, and that a valid credential cannot automatically unlock every available operation.

Decision rule: If the control only reduces secret exposure but does not evaluate the action itself, it is hygiene, not runtime governance, and it should not be treated as sufficient.

Common mistake: Teams often stop at vaulting, rotation, and token scoping, then assume the protocol is safe. That leaves a legitimately authenticated agent free to make unsafe or unintended requests.

Practitioner takeaway: MCP security is strongest when issuance and use are governed separately, because the real failure is often not secret theft, but authorised execution beyond intent.

Related resources from NHI Mgmt Group

• How does the consumer-secret-entitlement model help with governance at scale?
• How should security teams stop MCP servers from bypassing governance at runtime?
• What makes agentic AI an NHI governance issue?
• Why is proactive secret scanning important for NHI security?