Notifications
Clear all
Topic starter
19/08/2026 4:08 pm
TL;DR: AI agent risk registers break when they are built around behaviour, because prompt changes, new MCP connections, and model upgrades make yesterday’s likelihood and impact ratings obsolete, according to ARMO. The durable unit is the agent surface, not the specific action, and runtime telemetry is now a prerequisite for usable governance.
NHIMG editorial — based on content published by ARMO: AI Agents in the Cloud: A Risk Management Framework for Security Leaders
By the numbers:
- 88% have already had confirmed or suspected incidents.
Questions worth separating out
Q: How should security teams build an AI agent risk register that survives changing behaviour?
A: Anchor the register to stable surfaces, not to the agent’s latest behaviour.
Q: Why do AI agents break traditional likelihood and impact scoring?
A: Because the underlying inputs are no longer stable enough for intuition-based scoring.
Q: How do you know if an AI agent risk register is actually working?
A: A working register stays current after model upgrades, new MCP connections, and prompt changes.
Practitioner guidance
- Map every AI agent to four stable surfaces Rebuild the register around Identity, Data, Tool, and Model for each production agent, and update only the affected cells when model or tool changes occur.
- Replace subjective scoring with observable inputs Score likelihood from exposure, autonomy, and instrumentation gap, then score impact from identity blast radius, data sensitivity, tool capability, and model reach.
- Add runtime-derived inventory to GRC workflows Feed runtime AI bill of materials data into the register so the platform team can show actual agent processes, model endpoints, and API use rather than declared intent.
What's in the full article
ARMO's full blog covers the operational detail this post intentionally leaves for the source:
- A complete scoring model for Exposure, Autonomy, and Instrumentation Gap across cloud-deployed agents.
- The full treatment of surface-by-surface treatments for Identity, Data, Tool, and Model controls.
- Monthly KRI examples for behavioural deviation, permission entropy, and cross-agent correlation.
- Deployment guidance for turning runtime telemetry into a maintained AI agent register.
👉 Read ARMO's framework for AI agent risk registers in the cloud →
AI agent risk registers: what security leaders should change now?
Explore further
19/08/2026 4:41 pm
Behaviour is the wrong governance unit for AI agent risk. Traditional registers assume that a risk row can be tied to a stable action, but AI agents change execution paths as prompts, tools, and models change. That makes the action itself non-durable as a governance object. The useful unit is the surface that carries the behaviour, which is why Identity, Data, Tool, and Model are the right abstraction for IAM and GRC teams. The implication is that risk governance for agents has to move from event logging to surface control.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, which shows how often governance failures start with identity lifecycle drift.
A question worth separating out:
Q: Who should own AI agent governance when identity and access are shared across teams?
A: AI agent governance should sit with identity, security, and platform owners together, because no single team sees the full risk surface. IAM owns the control model, security owns containment and monitoring, and platform teams own the runtime integration. Shared ownership matters because agent risk spans identity, policy, and downstream execution.
👉 Read our full editorial: AI agent risk registers need four stable surfaces, not behaviour rows
