Security teams should govern MCP access as delegated identity, not simple application connectivity. That means binding consent to the client, validating the token audience, refusing passthrough, and constraining each tool call to the narrowest possible scope. If those controls are not enforced per request, an authorised login can become an unauthorised action path.
Why This Matters for Security Teams
MCP changes the control problem from “who can connect” to “what can this delegated identity do right now.” In agentic workflows, the client is often an autonomous software entity with goal-driven behaviour, so a valid login does not equal safe intent. Security teams need to govern the identity, the token audience, the tool surface, and the per-request context together. That is why current guidance from OWASP Top 10 for Agentic Applications 2026 and CSA MAESTRO agentic AI threat modeling framework both push toward runtime policy and narrow delegation rather than static trust.
The risk is not theoretical. SailPoint’s AI Agents: The New Attack Surface report found that 80% of organisations say their AI agents have already performed actions beyond intended scope, including unauthorised system access and credential exposure. That aligns with NHI failures more than conventional app-to-app integration failures, because the agent may chain tools, retry tasks, or amplify a small permission gap into a broad action path. In practice, many security teams encounter MCP abuse only after a tool call has already crossed an intended boundary, rather than through intentional design.
How It Works in Practice
Governance starts by treating MCP access as a workload identity problem. The agent should present a cryptographic identity that is bound to the client and the task, then receive a short-lived token that is scoped to a specific audience and purpose. That is the operational shape of zero standing privilege, and it fits the broader direction in the NIST AI Risk Management Framework and OWASP Non-Human Identity Top 10.
Security teams should enforce the following controls at request time:
- Bind consent to the specific agent client, not just the user session.
- Validate token audience and issuer on every tool call.
- Refuse passthrough of human credentials or long-lived service secrets.
- Issue JIT credentials with explicit TTL and automatic revocation after task completion.
- Authorise the exact tool, resource, and action, not the whole MCP server.
- Log each call with task context so audit trails show intent, not only authentication.
This is where intent-based authorisation matters. Static RBAC works poorly when the agent’s workflow is dynamic, because the next action may not be predictable at design time. Policy-as-code engines can evaluate whether the requested tool call matches the declared objective, the data classification, and the active risk posture. NHI governance guidance in Ultimate Guide to NHIs and the agentic risk framing in OWASP Agentic Applications Top 10 both support this move from standing access to per-request control. These controls tend to break down when MCP servers are shared across many agents because shared infrastructure makes audience binding, attribution, and least privilege much harder to preserve.
Common Variations and Edge Cases
Tighter delegation often increases operational overhead, requiring organisations to balance stronger containment against developer friction and latency. That tradeoff is especially visible in multi-agent pipelines, where one agent may call another, then call MCP tools on its behalf. There is no universal standard for agent-to-agent delegation yet, so current guidance suggests starting with explicit trust boundaries, minimal tool sets, and very short TTLs rather than broad cross-agent credentials.
Edge cases usually appear in environments with legacy MCP gateways, shared service accounts, or workflow orchestrators that expect static secrets. In those setups, teams should use ephemeral secrets as the default and reserve longer-lived credentials only for tightly controlled break-glass scenarios. The risk is compounded when teams ignore workload identity and rely on network location alone. For implementation detail on identity and attack-path hardening, see Analysis of Claude Code Security and the broader NHI lifecycle view in Ultimate Guide to NHIs. Where agents are allowed to discover tools dynamically, security teams should assume intent can change mid-session and re-evaluate policy on every call. That matters most in environments where one compromised tool can reach secrets, customer data, or infrastructure APIs.
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 | Covers agent misuse and overreach through unsafe tool access. |
| CSA MAESTRO | Defines threat modeling for autonomous agent workflows and delegation. | |
| NIST AI RMF | GOVERN | Addresses accountability and oversight for autonomous AI behaviour. |
Model agent-to-tool trust boundaries, then enforce short-lived, scoped delegation for each workflow step.
Related resources from NHI Mgmt Group
- How should security teams govern access when LLMs use MCP servers?
- How should security teams govern machine identity credentials in agentic AI environments?
- How should security teams govern AI agents that use OAuth access?
- How should security teams govern AI agents that can access enterprise systems?
