Because model routing only changes which brain reasons over the task, while MCP access changes what the agent can actually do. Once an agent can search, publish, transcribe, or execute code, the governance problem becomes delegated action and credential scope. That is why tool access expands blast radius even when the model is unchanged.
Why This Matters for Security Teams
Model routing is a control-plane decision, but MCP access is an action-plane decision. That distinction matters because an AI agent with tool access can move from “answering” to “doing” without a human re-authentication step. Once the agent can invoke APIs, retrieve files, or execute code, the security problem shifts to delegated authority, credential scope, and auditability. Guidance from the OWASP Agentic AI Top 10 and NHIMG’s OWASP Agentic Applications Top 10 both point to the same issue: autonomous systems inherit risk from every tool they can reach, not just from the model they use.
This is why agentic AI governance cannot be reduced to “which LLM is connected.” It has to answer what the agent may do, under what context, and for how long. NIST’s NIST AI Risk Management Framework is useful here because it frames AI risk as an operational governance problem, not a model-selection problem. In practice, many security teams encounter abuse only after an agent has already chained tools, crossed a trust boundary, or acted on stale credentials rather than through intentional testing.
How It Works in Practice
With model routing alone, the system decides whether a prompt goes to Model A or Model B. With MCP access, the agent may be holding privileged sessions, API tokens, or service credentials that let it touch production systems. That makes the right question: what identity does the agent present, what tools are in scope, and what policy is evaluated at runtime? NHIMG’s research on the Analysis of Claude Code Security and the OWASP NHI Top 10 shows why tool-mediated execution requires stronger controls than prompt mediation.
In practical terms, stronger architectures use workload identity plus just-in-time credentials:
- Issue short-lived, task-bound credentials instead of static secrets.
- Bind access to the agent’s workload identity, not to a shared human account.
- Evaluate intent-based authorisation at request time, using policy-as-code and current context.
- Limit each tool to a narrow scope, with explicit approval for sensitive actions.
- Revoke credentials automatically when the task ends or when the agent deviates from intent.
That model is consistent with the CSA MAESTRO agentic AI threat modeling framework, which treats autonomous behaviour, tool chaining, and execution authority as first-class risks. It also aligns with the NIST Cybersecurity Framework 2.0 emphasis on governance, protection, and continuous monitoring. The point is not to trust the model less and the router more; it is to make every tool call prove identity, purpose, and scope. These controls tend to break down when a single agent is allowed to retain long-lived secrets across multiple tasks because the blast radius becomes cumulative.
Common Variations and Edge Cases
Tighter control often increases latency and operational overhead, so organisations have to balance safety against automation speed. That tradeoff becomes sharper in multi-agent workflows, where one agent may delegate to another and each hop can multiply the permission problem. There is no universal standard for this yet, but current guidance suggests treating high-risk tools as separate trust zones and requiring stronger approval for write, delete, publish, or code-execution actions.
One edge case is read-heavy agents, such as research or summarisation bots. Even there, “read-only” can still be dangerous if the agent can query sensitive systems or exfiltrate data through logs, outputs, or downstream connectors. Another edge case is developer tooling: a coding agent may appear safe because it only proposes changes, yet access to repositories, secrets stores, or CI runners can still create real-world impact. NHIMG’s Moltbook AI agent keys breach illustrates how quickly exposed agent keys become reusable attack material once tooling is over-scoped.
For environments that already use PAM and ZSP, the best practice is evolving toward JIT issuance, runtime policy checks, and explicit workload identity for each agent session. That is especially important where MCP servers expose credentials or tool permissions are not scoped cleanly. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks is a useful reference for understanding why static access models fail once autonomy enters the picture.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agent tool misuse and over-privilege are central to MCP access risk. |
| CSA MAESTRO | MAESTRO models autonomous behaviour, tool chaining, and runtime controls. | |
| NIST AI RMF | AI RMF governs accountability and oversight for autonomous agent behaviour. |
Threat-model each agent workflow for execution authority, lateral movement, and privilege escalation.
