Notifications
Clear all
Topic starter
23/06/2026 6:58 pm
TL;DR: Enterprise teams are now managing autonomous software actors that interpret goals, choose tools, and execute multi-step workflows, making identity a runtime authorization problem rather than a login problem, according to PermitIO. Static service-account models are no longer enough when agents can branch, drift, and trigger sensitive actions mid-session.
NHIMG editorial — based on content published by PermitIO: Agent Identity Is Not Enough: From DIDs and AI Control Towers to Runtime Permissions
Questions worth separating out
Q: How should security teams govern AI agents that can choose tools at runtime?
A: Security teams should govern agentic systems with per-action authorization, not just with identity issuance.
Q: Why do agent identities complicate zero standing privilege programmes?
A: Agent identities complicate zero standing privilege because their access needs can change during a single workflow.
Q: What breaks when runtime authorization is missing for AI agents?
A: What breaks is the separation between identity proof and permission to act.
Practitioner guidance
- Map every agentic workflow to a runtime decision point Identify where the agent can choose tools, retry actions, or branch into new tasks, then insert a policy check before each sensitive step.
- Separate discovery from enforcement Keep AI asset inventory, ownership, and lifecycle records, but do not confuse them with execution control.
- Bind delegated access to human intent and trust tier Record the human principal, agent principal, declared intent, approved resource, and trust classification in one machine-verifiable envelope.
What's in the full article
PermitIO's full blog post covers the operational detail this analysis intentionally leaves for the source:
- The policy envelope fields needed to bind a human delegator, an agent principal, declared intent, and a trust tier.
- The gateway pattern for intercepting MCP tool calls before execution and sending them to a policy decision point.
- The operational meaning of zero standing permissions for agents, including how temporary grants should expire or contract.
- The specific failure scenarios the article uses to explain runtime revocation, including wrong-tool selection and cross-tenant access.
👉 Read PermitIO's analysis of agent identity and runtime permissions →
Agent identity governance: are your runtime controls keeping up?
Explore further
25/06/2026 2:44 am
Agent identity has moved the control point from authentication to execution governance. The decisive question is no longer whether the agent can be trusted to log in, but whether each action should be allowed at the moment it is attempted. That shift collapses the value of identity-only thinking and elevates runtime authorization as the primary control for agentic systems. Practitioners should treat every tool call as a policy decision, not an inherited entitlement.
A few things that frame the scale:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, 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 AI Agents: The New Attack Surface report.
A question worth separating out:
Q: Who should be accountable when an agent makes a high-risk decision?
A: Accountability should sit with the governance chain that approved the agent, the intent, and the scope, not with the agent alone. High-risk actions need a traceable delegation record that links the human approver, the allowed action, and the policy version in force when the step was taken.
👉 Read our full editorial: Agent identity needs runtime permissions, not just authentication
