Because the agent is choosing actions, chaining tools, and preserving context across steps. Ordinary API controls assume predictable request patterns, while MCP can turn one legitimate session into a route for data exposure or privilege escalation. The risk increases when identity, context, and tool access are not governed together.
Why This Matters for Security Teams
MCP-based agents are riskier than ordinary API integrations because the decision-maker is no longer a fixed application workflow. An agent can choose tools, branch into new tasks, and carry context forward across multiple calls, which means a single trusted session can become a chain of unintended actions. That shifts the problem from simple API authentication to runtime authorisation, context control, and secret handling.
Current guidance from the OWASP Agentic AI Top 10 and NIST’s NIST AI Risk Management Framework both point to the same operational reality: agent behaviour must be governed at the moment of action, not assumed safe because the integration itself is approved. NHIMG research has also shown how quickly agent risk becomes visible in production, with AI Agents: The New Attack Surface report noting that 80% of organisations say their AI agents have already performed actions beyond intended scope.
In practice, many security teams encounter excessive data access only after an agent has already chained tools and crossed a boundary that no static API review anticipated.
How It Works in Practice
Ordinary API integrations usually follow predictable paths: a service authenticates, calls a known endpoint, and returns a bounded result. MCP changes that pattern by allowing the agent to select from multiple tools and combine outputs across steps. The security question is therefore not just “who called the API?” but “what was the agent trying to do, what context did it retain, and what permissions existed at that exact moment?”
That is why static RBAC is often insufficient for agentic systems. A role can say an identity may use a tool, but it cannot express whether the tool should be used for this task, with this dataset, under this prompt, and in this risk state. Best practice is evolving toward intent-based or context-aware authorisation, paired with short-lived credentials that are issued just in time and revoked automatically when the task ends. Workload identity is the stronger primitive here: the system should prove what the agent is through cryptographic identity such as SPIFFE or OIDC, then apply policy-as-code at request time.
- Use ephemeral secrets instead of long-lived tokens whenever the agent can initiate follow-on actions.
- Bind tool access to task context, data sensitivity, and session duration.
- Evaluate policy at runtime with engines such as OPA or Cedar rather than relying only on pre-approved roles.
- Log tool selection, prompt context, and downstream actions so investigators can reconstruct the chain.
NHIMG’s The State of MCP Server Security 2025 underscores how often this breaks down in the wild, including hard-coded credentials and weak tool scoping, while the CSA MAESTRO agentic AI threat modeling framework and NIST guidance both support runtime controls over assumptions made at deployment time. These controls tend to break down when MCP servers are broadly exposed and the agent can pivot into multiple tools from a single authenticated session because scope is no longer enforced per action.
Common Variations and Edge Cases
Tighter agent controls often increase operational overhead, requiring organisations to balance safety against latency, developer friction, and observability cost. That tradeoff is real, especially when teams want agents to remain useful rather than over-restricted.
There is no universal standard for this yet. Some environments can tolerate per-task credential issuance and fine-grained policy checks, while others need a narrower initial rollout with guardrails around high-risk tools only. Sensitive environments such as code execution, ticketing systems, cloud consoles, and knowledge bases deserve stricter treatment because one agent action can cascade into lateral movement or data exposure. For implementation patterns, NHIMG’s OWASP NHI Top 10 and the companion Ultimate Guide to NHIs — Why NHI Security Matters Now both reinforce the same point: agent identities must be governed as dynamic workloads, not as static service accounts.
The hardest edge case is long-running agents with persistent memory or delegated tool chains. Current guidance suggests treating those sessions as higher risk because context can accumulate in ways that outlive the original approval. In those cases, short TTLs, step-up checks, and explicit re-authorisation between phases are more defensible than one-time approval at session start.
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 use and chained actions create the core risk described here. |
| CSA MAESTRO | T1 | MAESTRO addresses runtime governance for autonomous agent behaviour. |
| NIST AI RMF | GOVERN | AI RMF governance is needed for accountability over agent decisions and actions. |
Assign ownership, policy, and oversight for every agent capability and escalation path.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
