Notifications
Clear all
Topic starter
06/07/2026 9:37 am
TL;DR: Agentic AI is exposing a governance gap: traditional IGA and IAM controls were designed for stable human roles and cannot keep pace with machine-speed, ephemeral agent contexts, according to Reva.AI’s guide. Static access review models no longer align with runtime authorization, where policy must be enforced after authentication and during execution.
NHIMG editorial — based on content published by Reva.AI: Mapping reva.ai to MAESTRO and AI TRiSM
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should security teams govern AI agents that can act at runtime?
A: They should govern the action path, not just the identity record.
Q: Why do static IAM controls struggle with agentic AI?
A: Static IAM assumes stable roles and predictable behaviour, while agents can change tools, targets, and outputs during one session.
Q: What do security teams get wrong about AI agent governance?
A: They often treat agent governance as an entitlement problem when it is really an enforcement problem.
Practitioner guidance
- Define the runtime authorization boundary Identify which agent actions must be evaluated after authentication, then route those decisions through infrastructure policy instead of only relying on role assignment at provision time.
- Translate governance into policy-as-code Convert high-risk rules for data export, transaction limits, and tool use into executable policies so the control can deny specific actions inside the execution loop.
- Instrument agent sessions for continuous enforcement Add monitoring that can detect unsafe behaviour during task execution, including prompt injection drift, unauthorized tool calls, and context changes that invalidate the original approval.
What's in the full article
Reva.AI's full guide covers the operational detail this post intentionally leaves for the source:
- A practical mapping of runtime authorization controls to agent execution paths and policy enforcement points
- Examples of policy-as-code logic for tool calls, refund limits, and data export restrictions
- A framework comparison that translates AI TRiSM and MAESTRO into implementation choices for security teams
- The guide's own explanation of how Reva positions continuous monitoring and circuit breaker logic across agent workflows
👉 Read Reva.AI's guide on mapping agentic AI governance to runtime policy →
AI agent governance and static IAM limits: what changes now?
Explore further
06/07/2026 9:52 am
Static IAM is built on a governance assumption that no longer holds: access can be evaluated at provisioning time because intent is stable. That assumption fails when an agent changes tools, targets, and execution path inside the session. The implication is not that teams need more review checkpoints, but that the old notion of a fixed access decision no longer describes the behaviour they are trying to govern.
A few things that frame the scale:
- 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.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
A question worth separating out:
Q: Who is accountable when an AI agent makes an unauthorized decision?
A: Accountability should sit with the programme that authorized the agent, the control owner that defined its permissions, and the operator that failed to constrain its runtime behaviour. In practice, organisations need clear ownership for policy, logging, and exception handling before agents are allowed to touch sensitive workflows.
👉 Read our full editorial: AI agent governance exposes the limits of static IAM controls
