Why do MCP runtime controls need both discovery and inspection?

Why discovery and inspection solve different MCP problems

MCP discovery answers a gateway question: should this server be trusted enough to install, register, expose, or allow into an environment? That is a supply and trust decision about the server itself. Inspection answers a runtime question: given a specific live request, is this call safe, scoped, and consistent with the policy you intended to enforce?

MCP Security Guide is useful here because MCP deployments usually mix server onboarding, token handling, and tool access decisions in the same operational path, even though those decisions belong to different control layers.

When teams collapse discovery and inspection into one check, they usually overfit to one failure mode. A server can look legitimate at install time and still issue dangerous tool calls later. Conversely, a server may deserve a limited exposure path but still need per-call inspection because the runtime context, parameters, or destination data make a particular action unsafe.

What discovery should establish before a server is exposed

Discovery is about trust placement and inventory hygiene. You want to know what the server is, who published it, what capabilities it advertises, what dependencies it brings, and whether it belongs in the approved surface area at all. That is where you catch shadow servers, unexpected capabilities, weak provenance, and servers that should never be reachable by production agents.

Top 10 NHI Issues helps frame the same problem as a visibility and ownership issue: if you cannot inventory the service or understand its authority, you cannot govern its access safely.

Discovery also has to be coarse enough to be operational. If you make it too strict, teams will bypass it to get work done. The practical goal is not perfect certainty, but enough confidence to decide whether the server should be admitted, quarantined, restricted, or rejected before any live interaction begins.

What inspection should decide at runtime

Inspection is the per-request control plane. It should answer whether this specific call is allowed now, for this user or agent, against this tool, with these arguments, in this context, and under this policy. That includes checking for dangerous parameter combinations, unexpected tool chaining, excessive scope, sensitive destinations, and any request that is technically valid but operationally unsafe.

MCP authorization specification is relevant because MCP treats servers as OAuth resource servers, which reinforces the need to validate the live authorization context rather than assume the initial install decision is enough.

Inspection matters most when the same server can be used safely in one context and unsafely in another. A call that is harmless for a read-only lookup may become risky when it can write, trigger actions, or retrieve data from a sensitive system. runtime inspection is the control that narrows that gap.

Why the two controls must stay separate in practice

Discovery and inspection fail differently, and the attack surface changes at different times. Discovery is about what enters your environment. Inspection is about what a trusted component is allowed to do after it is already inside. If you rely on discovery alone, you miss malicious or abusive behaviour that appears only after deployment. If you rely on inspection alone, you may expose an untrustworthy server and give it too much ambient authority.

Ultimate Guide to NHIs, Key Challenges and Risks is relevant because the same pattern appears anywhere visibility gaps and over-privilege combine: the organisation knows something exists, but not enough about what it can do or how far its actions can reach.

The strongest MCP control design treats discovery as admission control and inspection as execution control. That separation keeps the first decision focused on trust and the second on safe use, which is the only reliable way to reduce both installation risk and runtime abuse.

Risk and Threat Considerations

When discovery and inspection are merged, the environment becomes easier to over-trust. A server that passes onboarding may later be used to exfiltrate data, invoke unintended tools, or chain actions that were never part of the original approval. The failure mode is especially dangerous in agentic workflows because the caller may treat a trusted server as safe by default.

Failure mechanism: A single coarse control either blocks too much at install time or allows too much at runtime, so trust decisions and action decisions drift apart and attackers can exploit the gap.

Impact: You can end up admitting risky MCP servers, missing unsafe live calls, or both, which increases exposure to privilege abuse, data leakage, and unauthorized tool use.

Practitioner Guidance

What to prioritise: Keep discovery and inspection under separate policy outcomes. Discovery should answer whether the server may be present in the environment; inspection should answer whether the current call may execute.

What to verify: Make sure your runtime layer checks the exact tool, arguments, caller context, and destination data path, not just the server’s registration status or publisher reputation.

Common mistake: Treating a “trusted server” as equivalent to “safe request.” Trust in the component does not remove the need to evaluate the action.

Practitioner takeaway: The control objective is layered trust, not a single approval event: discovery bounds what you admit, and inspection bounds what you let it do.

Related resources from NHI Mgmt Group

• What is the difference between code scanning and runtime identity monitoring?
• How should organizations prioritize security in their MCP implementations?
• When does secrets discovery become insufficient on its own?
• What breaks when MCP server discovery is missing from security controls?