Agent identity needs runtime authorization for MCP tool calls

At a glance

What this is: This is an analysis of why verifiable agent identity does not replace per-call authorization for MCP tool execution.

Why it matters: It matters because IAM, NHI, and emerging agentic AI programmes need a separate decision layer for delegation, intent, context, and tool risk, not just stronger credentials.

👉 Read PermitIO's analysis of agent identity and MCP runtime authorization

Context

Agent identity is the claim layer, but tool-call authorization is the decision layer. In practice, that means a signed agent can be real, governable, and lifecycle-managed without being safe to execute a specific MCP action against a production resource in that session.

The security gap appears when teams treat identity verification as permission. For NHI, agentic AI, and human-delegated workflows, the question is not just who the actor is, but whether the requested action fits the current intent, context, and risk boundary.

Key questions

Q: How should security teams authorise MCP tool calls for AI agents?

A: Security teams should authorise MCP tool calls at runtime, not only at agent onboarding. The decision should combine agent identity, delegator, intent, resource sensitivity, session context, and delegation chain. That lets the gateway permit low-risk actions, block high-risk ones, and enforce obligations such as masking or step-up confirmation when the request is only conditionally acceptable.

Q: Why do verified agent identities still need runtime policy checks?

A: Verified identity answers who the agent is, but not whether the requested action is safe in the current session. An agent can be authenticated, sponsored, and lifecycle-managed while still being over-scoped for a particular tool call. Runtime policy checks are what stop a legitimate principal from executing an inappropriate action in production.

Q: What breaks when agent identity is treated like machine identity?

A: What breaks is the assumption that one stable principal equals one stable task. Agents can shift goals, delegate to sub-agents, and change context mid-session, while machine identity models assume predefined, static execution. If teams treat them the same, they overgrant access and lose the ability to evaluate intent and delegation properly.

Q: Who should be accountable when an agent makes a risky tool call?

A: Accountability should follow the human delegator, the sponsoring team, and the policy owner, not just the agent credential. The useful audit question is which approved delegation path enabled the call and which runtime control allowed it. That structure makes agent behaviour governable instead of anonymous.

Technical breakdown

Agent identity vs machine identity in MCP ecosystems

Machine identity was built for software that performs predefined tasks, such as service accounts, API keys, and workload certificates. Agent identity needs more than authentication because an agent can reason over goals, shift tasks, and delegate work to sub-agents. That makes it a control-plane distinction, not a naming debate. A valid credential proves the principal exists. It does not prove the current action is appropriate for the delegator, the intent, or the session context.

Practical implication: separate principal verification from action authorisation in every agent workflow.

How SD-JWT selective disclosure changes agent discovery

SD-JWT lets a holder reveal only the claims needed for a specific interaction while preserving issuer integrity. In agent ecosystems, that reduces over-disclosure during discovery and supports proof-of-possession through key binding. The limit is clear: a verified Agent Card can establish credibility, but it cannot by itself answer whether a production tool call should proceed. Discovery evidence is not runtime permission.

Practical implication: treat cryptographic agent claims as input to policy, not as a substitute for policy.

Runtime authorization for MCP tool calls

MCP tool execution needs a per-invocation policy decision built from human delegator, agent identity, intent, trust level, tool, resource, context, policy version, and delegation chain. That tuple allows allow, deny, or allow with obligations, such as masking, row limits, or step-up confirmation. The architecture works because it evaluates live conditions at execution time rather than assuming the session remains safe after onboarding.

Practical implication: evaluate policy at each tool call and enforce obligations at the gateway or broker.

Threat narrative

Attacker objective: The objective is to turn a legitimate agent identity into unauthorized execution authority inside a production workflow.

1. Entry occurs when a signed agent credential or Agent Card is accepted as proof that the actor is legitimate and enterprise-governed.
2. Escalation occurs when that verified identity is allowed to reuse broad standing permissions for a tool call that was never evaluated against current intent or context.
3. Impact occurs when a safe-looking agent session executes an unsafe production action, such as exposing sensitive records, making destructive writes, or crossing delegation boundaries.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity verification and runtime authorisation are not the same security problem. Agent identity proves a principal exists and may be governed, but it does not decide whether a specific MCP tool call should be executed in this session. The field keeps collapsing these layers because directory-centric thinking assumes authentication and authorisation move together. They do not. Practitioners should treat verified identity as a prerequisite, not a permission decision.

Verified-agent, unverified-action is the right concept for this market shift. The article captures a control gap that will define agent governance for the next cycle: enterprises can increasingly attest to who the agent is, yet still cannot consistently decide what that agent may do right now. That is a runtime authorisation gap, not a credential gap. The practitioner conclusion is that policy evaluation must move to the point of execution.

Agentic identity = delegating human plus workflow context plus intent plus agent credential. That framing is more useful than relabelling service accounts as agents. If delegator, intent, and context are stripped away, the programme regresses to machine identity with a fancier label. The implication is that lifecycle and governance models must carry delegation semantics, not just principal registration.

Runtime policy must reason over delegation chains, not just the first caller. In agentic systems, sub-agent hops can widen authority without being visible in a simple authentication log. The control assumption that one authenticated principal equals one accountable actor breaks down. Practitioners need to re-think accountability as a chain of delegated decisions, not a single identity event.

Agent Cards are evidence, not execution rights. Selective disclosure and key binding improve interoperability, but they remain discovery and trust artefacts. The security mistake is to promote cryptographic identity proof into blanket tool access. The field should now separate identity artefacts from decision artefacts in every agent architecture.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to the same report.
• For a broader control lens, see OWASP Agentic Applications Top 10 for the runtime risks that identity proof alone does not remove.

What this signals

Verified identity will become table stakes, but runtime authorisation will become the differentiator. If your programme stops at agent onboarding, you will still be exposed to per-call abuse, context drift, and delegated overreach. The next control maturity step is to make policy decisions at the MCP gateway, not just inside identity systems.

The governance pattern here is broader than AI. Human delegation, NHI credentials, and agentic principals all need a clear separation between who is trusted and what is allowed. That is why runtime policy, delegation traceability, and audit replay will matter more than static role assignment in the next wave of identity programmes. Verified-agent, unverified-action is the right label for that shift.

With 52% of companies still unable to track and audit the data their AI agents access, the operational blind spot is already measurable, according to the New Attack Surface report. Teams should respond by treating tool-call decisions as auditable events, not invisible side effects of authentication. For the control model behind that shift, OWASP Top 10 for Agentic Applications 2026 is a useful external anchor.

For practitioners

• Separate identity proof from execution approval Route every MCP tool invocation through a policy decision point that evaluates intent, resource sensitivity, session context, and delegation chain before any action is executed.
• Normalize agent intents before policy evaluation Map free-text requests into a controlled intent vocabulary so that summaries, searches, exports, and writes are not treated as the same action category.
• Bind delegation to short-lived session context Require delegation tokens to expire with the session and propagate the delegator identity through every downstream agent and sub-agent hop.
• Use obligations for risky but necessary tool calls Allow masking, row limits, read-only mode, or step-up confirmation when policy permits an action only under constrained conditions.
• Log the full decision tuple for audit replay Capture human delegator, agent identity, intent, trust level, tool, resource, policy version, and delegation chain so authorisation decisions can be reviewed later.

Key takeaways

• Agent identity and runtime authorisation solve different problems, and confusing them creates a governance gap.
• The evidence shows agent scope drift is already happening at scale, so tool-call controls need to move to execution time.
• Practitioners should design for delegator, intent, context, and delegation-chain awareness before allowing production MCP actions.

Key terms

• Agent Identity: Agent identity is the set of claims used to recognise a software actor that can act on behalf of a human or workflow. Unlike a simple workload identifier, it must carry delegation, intent, and context so a policy engine can judge what the agent may do in a specific session.
• Runtime Authorization: Runtime authorization is the decision made at the moment a request is executed, using the current context rather than only the original login state. For agentic systems, it is the control that decides whether a tool call, data access, or write action is allowed right now.
• Delegation Chain: A delegation chain is the ordered path showing how authority moved from a human or parent principal to one or more agents and sub-agents. It matters because accountability, scope, and risk can change at each hop, especially when downstream actions are not visible to the original delegator.
• Key Binding: Key binding links a presented claim set to the cryptographic key held by the current presenter. In agent ecosystems, it helps stop replayed credentials from being reused by an impostor, but it does not replace policy decisions about whether the presenter should be allowed to act.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by PermitIO: Agent Identity Is Becoming a Protocol Layer, but Tool Calls Still Need Runtime Authorization. Read the original.