How do organisations govern tool calls in MCP-enabled agent systems?

Why This Matters for Security Teams

MCP changes the control point for agent governance: a tool call is no longer a simple application request, but a machine-initiated action with real-world side effects. That makes every dispatch decision a security decision. If organisations rely on static allowlists or coarse role mapping, they miss the key question: should this specific actor, in this specific context, be allowed to invoke this specific tool with these arguments right now?

The risk is visible in current research. NHIMG notes that only 18% of MCP server deployments implement any form of access scoping for tool permissions in The State of MCP Server Security 2025. That gap matters because MCP tool calls can chain across systems, move data, and trigger state changes faster than human operators can intervene. Guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward runtime governance, not trust-by-default.

In practice, many security teams encounter tool abuse only after an agent has already retrieved secrets, touched sensitive data, or called a privileged action that no one expected it to reach.

How It Works in Practice

Governing MCP tool calls well means placing a policy layer in front of dispatch and treating the call as an authorization event, not a code path. The policy engine should evaluate the actor identity, the delegating system or user, the specific tool name, argument shape and safety, risk signals, and the trust level of the target server before the request is executed. That is consistent with emerging agentic guidance from CSA MAESTRO agentic AI threat modeling framework and with the runtime decision model described in OWASP NHI Top 10.

A practical control stack usually includes:

• Workload identity for the agent and the MCP server, so the runtime knows what is calling what.
• Per-tool policy, ideally policy-as-code, evaluated at request time rather than encoded in a static role.
• Argument inspection to block unsafe parameters, privilege escalation patterns, or prompt-injected tool misuse.
• Just-in-time credentials with short TTLs, so a granted capability expires after the task completes.
• Step-up approval or downgrade logic for high-impact actions such as data export, secret retrieval, or admin operations.

This is where MCP governance connects to broader NHI lifecycle discipline. NHIMG research on Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the NIST Cybersecurity Framework 2.0 both reinforce that permissions, secrets, and auditability must be continuously managed, not assumed once at onboarding. These controls tend to break down when tool output can trigger new tool calls across loosely governed services because the trust boundary becomes recursive.

Common Variations and Edge Cases

Tighter tool governance often increases latency and operational overhead, requiring organisations to balance safety against developer friction and agent throughput. That tradeoff is real, especially in fast-moving multi-agent systems where a deny decision can interrupt an otherwise valid workflow. Current guidance suggests starting with high-risk tools, then expanding policy coverage as confidence improves rather than attempting full parity on day one.

There is no universal standard for MCP trust scoring yet, so teams often combine coarse server reputation with fine-grained request context. That is also where implementation details matter: a tool may be safe in one workflow and unsafe in another if the same parameters are used for a different delegator, dataset, or environment. For this reason, organisations should not treat “tool allowed” as a permanent property. They should re-evaluate each call in context and log the decision path for audit and incident response.

NHIMG’s AI LLM hijack breach coverage shows how quickly an apparently contained model workflow can become an access-control problem once the model is induced to follow a malicious chain of action. The emerging lesson is simple: MCP governance must be dynamic enough to handle benign automation, but strict enough to stop tool chaining, privilege creep, and prompt-driven misuse before they become operational incidents.

Related resources from NHI Mgmt Group

• How should teams govern AI agents that use MCP?
• Why is identity such a critical factor in securing AI agent systems?
• When is it appropriate to implement MCP in the context of AI systems?
• How should security teams govern AI agents that can access enterprise systems?