Because they were designed to classify and review models, not the runtime actions that happen after a model discovers a tool. The control failure is at the boundary where a valid model decision becomes an unaudited external action, which is why tool governance has to be explicit.
Why This Matters for Security Teams
Model governance frameworks are built to evaluate the model as a system artifact: training data, output quality, bias, and safety. MCP risk sits one layer deeper, where an apparently valid model decision triggers tool use, data access, or external side effects. That boundary matters because the real exposure is not the prompt alone but the runtime authority granted to the agent after the prompt is accepted.
For security teams, this creates a governance gap between model review and execution control. A model can pass policy checks and still call a tool that reaches production data, secrets, or internal workflows. This is why NHI governance has to connect identity, secret handling, and action-level authorization, not just model approval. Current guidance also points toward agent-specific control sets such as OWASP Agentic AI Top 10 and the NHIMG analysis in OWASP NHI Top 10, both of which emphasize tool abuse and runtime trust boundaries. In practice, many security teams encounter MCP exposure only after an agent has already used a legitimate tool path to do something unintended, rather than through intentional design review.
How It Works in Practice
MCP risk appears when the model, the orchestrator, and the tool layer are treated as one control domain. A model governance workflow may validate the LLM, but MCP governs the interface that exposes tools, schemas, and callable actions. That means the security question is not just “Is the model approved?” but “What can this agent do right now, with this context, through this tool?”
Practically, teams should separate three layers:
- Model approval, which covers the model source, intended use, and output risk.
- Tool authorization, which defines which MCP tools are callable, by whom, and under what context.
- Runtime enforcement, which evaluates each request against policy, session state, and environment conditions.
This is where a broader NHI program helps. The Top 10 NHI Issues and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs both reinforce that identity lifecycle, credential scope, and revocation must be explicit for machine actors. For MCP, that often translates to short-lived credentials, per-tool scopes, logging of every tool invocation, and policy-as-code checks before the call is executed. Standards-based teams usually map this to NIST Cybersecurity Framework 2.0 outcomes for governance, access control, and monitoring.
The key implementation point is that the tool layer must not inherit trust from the model layer. An approved model may still need to be blocked from reading files, querying production APIs, or chaining tools unless the runtime context explicitly allows it. These controls tend to break down in loosely governed agent pipelines where tools are auto-discovered and secrets are shared through configuration rather than issued per task.
Common Variations and Edge Cases
Tighter MCP control often increases operational overhead, requiring organisations to balance fast agent development against stronger runtime inspection and access review. That tradeoff becomes most visible in engineering environments that value rapid tool onboarding, where each new MCP server can expand the agent’s practical authority faster than governance can review it.
There is no universal standard for this yet, so best practice is evolving. Some teams focus on blocking high-risk tools by default, while others allow broader tool access but require real-time policy evaluation and full audit trails. The latter approach aligns better with agentic systems, but it depends on reliable telemetry and policy engines that can interpret context at request time. The emerging direction in OWASP Agentic AI Top 10 and NHIMG’s Ultimate Guide to NHIs — Standards is to treat tool access as an explicit control plane, not an incidental model feature.
Edge cases also include local MCP servers, hidden tool connectors inside IDEs, and workflows where the agent can escalate by combining benign tools. Those environments are difficult because tool boundaries are often distributed, and model governance teams may not own the systems where the actual action occurs.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Covers tool abuse and runtime agent risks that model governance misses. |
| CSA MAESTRO | G4 | Addresses agent supervision and policy enforcement across orchestration layers. |
| NIST AI RMF | GOVERN | Explains why governance must extend beyond model evaluation into operational controls. |
| OWASP Non-Human Identity Top 10 | NHI-04 | Relevant because MCP tool access depends on non-human identity scope and secret handling. |
| NIST CSF 2.0 | PR.AC-4 | Access control must apply to tool execution, not just model approval. |
Treat each tool call as a governed action and block unsafe agent capabilities at runtime.
Related resources from NHI Mgmt Group
- How can organizations manage the risk of credential leaks in MCP frameworks?
- How does the consumer-secret-entitlement model help with governance at scale?
- Why do AI agents need identity and access governance if the model is already strong?
- Why do non-human identities create more audit risk than human accounts?
