Notifications
Clear all
Topic starter
26/08/2026 11:51 am
TL;DR: AI agents are already taking real actions inside CRM, ERP, and code environments, and Cakewalk’s session with Vanta argues that human IAM models fail because agents act faster, with broader privilege, and with less determinism than traditional users. The core issue is that access review and static RBAC assume stable, reviewable behaviour, which autonomous runtime action breaks.
NHIMG editorial — based on content published by Cakewalk: AI agent authorization and the AARM discussion with Vanta
Questions worth separating out
Q: What breaks when AI agents are governed with human IAM, IGA, and PAM models?
A: Human identity models assume a known person, a start date, a manager, and predictable access review cycles.
Q: Why do AI agents complicate least-privilege design?
A: AI agents complicate least-privilege design because their tool use can change dynamically while the underlying permissions remain persistent.
Q: How do security teams know if agent authorization is actually working?
A: Authorization is working only if the agent can complete the intended task without gaining unnecessary reach.
Practitioner guidance
- Inventory every agent credential and scope Build a live inventory of which agents exist, what credentials they use, and which tools, systems, and data paths those credentials can reach.
- Move runtime checks in front of tool execution Require policy evaluation before an agent can invoke a tool, write a record, or trigger payment.
- Capture session context for every meaningful action Persist the session context, request chain, and escalation reason so a future reviewer can reconstruct why a tool call was allowed or denied.
What's in the full article
Cakewalk's full article covers the operational detail this post intentionally leaves for the source:
- The 24-page AARM specification outline and how the runtime authorization model is structured.
- The discussion of intercept, accumulate context, evaluate, and log as the four building blocks for agent control.
- The practical examples of context referral and why selective escalation reduces approval fatigue.
- The market argument for a shared specification instead of fragmented point tools.
👉 Read Cakewalk's analysis of AI agent authorization and AARM →
AI agent authorization at runtime: what IAM teams need now?
Explore further
26/08/2026 11:51 am
Human IAM assumptions are collapsing at the point of runtime action. Traditional identity controls were built for accountable people with bounded intent and reviewable requests. Agents are different because they can execute tools, change system state, and move faster than any approval workflow can comfortably absorb. The implication is that identity governance now has to separate who initiated the session from what the session is allowed to do.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface.
- 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 AI Agents: The New Attack Surface report.
A question worth separating out:
Q: Who is accountable when an AI agent makes the wrong change?
A: Accountability sits with the governance chain that approved the access model, not with the agent alone. Teams need a trace from requester to policy decision to identity issuance to action results. If that chain is missing, incident review becomes guesswork and access governance cannot be defended to auditors.
👉 Read our full editorial: AI agent authorization is breaking human IAM assumptions
