Notifications
Clear all
Topic starter
23/06/2026 7:29 pm
TL;DR: Agent identity can now be verified with cryptographic claims and lifecycle governance, but that still does not decide whether a specific MCP tool call should run in the current session, according to PermitIO. The real control boundary is runtime authorization, because identity proves who the agent is while policy must decide what it may do right now.
NHIMG editorial — based on content published by PermitIO: Agent Identity Is Becoming a Protocol Layer, but Tool Calls Still Need Runtime Authorization
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
PermitIO's full blog covers the operational detail this post intentionally leaves for the source:
- The decision model for mapping agent identity claims into live policy inputs at the MCP gateway.
- The implementation pattern for allow, deny, and allow with obligations outcomes in production workflows.
- The way Permit.io positions policy versioning, audit payloads, and enforcement boundaries for tool-call governance.
- The article's examples of how runtime authorization sits alongside, rather than inside, identity verification.
👉 Read PermitIO's analysis of agent identity and MCP runtime authorization →
MCP tool calls and agent identity: where does runtime auth start?
Explore further
25/06/2026 3:31 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Agent identity needs runtime authorization for MCP tool calls
