Because they turn a model from a text generator into a delegated actor that can reach real systems. Once the agent can send mail, query data, or execute commands, a broad token or static rule can expose far more access than the originating task requires.
Why This Matters for Security Teams
MCP-based agents change the access model because the request is no longer just a prompt, it is an instruction to a delegated actor with tool reach. That shifts risk from content safety to privilege exposure, secret handling, and runtime authorisation. Current guidance suggests IAM teams should treat these workloads as non-human identities with execution authority, not as another application integration. The issue is visible in both agent guidance and field research: the OWASP NHI Top 10 and the OWASP Top 10 for Agentic Applications 2026 both point to tool abuse and overbroad delegation as core risks.
NHIMG research also shows that access control maturity is lagging: in The 2024 Non-Human Identity Security Report, Aembit found that 88.5% of organisations say non-human IAM lags behind or merely matches human IAM. For MCP specifically, the problem intensifies because the protocol standardises how agents discover and invoke tools, so a single permissive token can touch mail, tickets, data stores, or infrastructure if controls are not narrowed per action. In practice, many security teams encounter overprivileged agent access only after a tool chain has already been used to reach systems far beyond the original task.
How It Works in Practice
The safer pattern is to stop thinking in terms of static roles and start thinking in terms of workload identity plus runtime policy. An MCP agent should present a cryptographic workload identity, such as an OIDC token or SPIFFE-derived identity, and then request narrowly scoped, short-lived credentials only for the task it is attempting. The decision point moves from pre-assigned entitlements to context-aware authorisation at request time. That is why the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework emphasise governance, traceability, and task-bound controls rather than permanent access.
Practitioners typically combine four controls:
- Per-task just-in-time credentials with short TTLs and automatic revocation on completion.
- Tool-level scoping so an agent can read a dataset without gaining write or export rights.
- Policy-as-code enforcement at runtime, using context such as task intent, data sensitivity, and environment.
- Separate approval paths for high-risk actions like sending email, issuing payments, or changing infrastructure.
That model aligns with the reality documented in NHIMG’s The State of MCP Server Security 2025, where only 18% of MCP server deployments implement any form of access scoping for tool permissions. The lesson is straightforward: if the agent can chain tools, then one broad token becomes a lateral-movement primitive, not a convenience. These controls tend to break down when MCP servers are deployed with shared service accounts and hard-coded secrets because the runtime has no reliable way to distinguish one task from the next.
Common Variations and Edge Cases
Tighter control often increases orchestration overhead, requiring organisations to balance developer speed against containment. That tradeoff is real, especially in environments where agents are expected to complete multi-step workflows without human intervention. Best practice is evolving, but there is no universal standard for how granular MCP authorisation should be across every tool and connector.
Some teams choose coarse scopes for low-risk read-only tasks and reserve granular JIT provisioning for actions with external effects. Others enforce a policy gate only at tool invocation, while some add step-up approval when the agent crosses a sensitivity threshold. The right answer depends on the environment, but the access model should never assume that an agent will behave like a predictable service account. The AI LLM hijack breach and Anthropic’s report on AI-orchestrated cyber operations show why runtime behaviour can diverge sharply from initial intent.
Edge cases are common in hybrid estates, shared tool registries, and multi-agent pipelines where one agent calls another. In those setups, access creep can appear through delegation chains rather than direct login abuse. The practical takeaway is to make each agent prove what it is, restrict what each tool can do, and re-evaluate policy every time the request changes scope.
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 | A1 | Agent tool abuse and overdelegation are the core MCP risk here. |
| CSA MAESTRO | T2 | MAESTRO covers agent threat modeling and control of autonomous tool use. |
| NIST AI RMF | AI RMF fits governance, accountability, and runtime risk management for agents. |
Apply AI RMF governance to define ownership, escalation paths, and continuous monitoring.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
