What breaks when AI systems are governed only through IGA?

IGA can prove who received access, but it cannot prove whether an AI agent used that access appropriately at runtime. That leaves behavioural drift, shadow AI, and policy violations outside the control model. The result is a governance gap where credentials look valid while actions are still unsafe.

How IGA Fails as the Only Control Plane for AI

IGA is good at governing access grants, approvals, and recertification, so it can answer a narrow question: who was allowed to connect an AI system to a resource. It cannot, by itself, answer the harder question of whether the system stayed within policy once runtime execution started. That gap matters because AI systems can behave differently from the approval record that authorised them.

The practical failure is that governance becomes point-in-time while the risk is continuous. If an AI agent can change prompts, call tools, or chain actions after approval, the control model needs visibility into behaviour, not just entitlements. That is why identity governance must be paired with runtime controls that observe what the AI is actually doing, not only what it was permitted to do.

When teams treat access certification as proof of safety, they confuse administrative validity with operational safety. IGA can confirm that a credential, role, or assignment exists; it cannot confirm intent, context, or whether a tool invocation was appropriate at that moment. For readers trying to understand the boundary, the difference between IAM and IGA Basics and runtime governance is the difference between authorising access and supervising use.

Where Behavioural Drift, Shadow AI, and Policy Violations Appear

Once an AI system has valid access, the main failure mode is behavioural drift. The model may start taking actions that are technically permitted by its access but no longer aligned with the original business intent, especially when tools, memory, or prompts change over time. Shadow AI is the parallel risk: systems, plugins, or delegated workflows appear outside the governance registry, so they never enter the review cycle in the first place.

Policy violations are especially easy to miss when they emerge through composition rather than a single forbidden action. A harmless-seeming sequence, such as reading data, transforming it, then sending it onward, may still violate segregation rules, data handling policy, or approval boundaries. This is why access review alone is too coarse for AI systems, and why the operational question becomes whether the action chain itself is controlled, not just whether the initial grant was approved.

That distinction is visible in lifecycle controls as well. A clean provisioning record does not prevent a later misuse pattern, and a valid offboarding workflow does not help if the system can continue to use cached permissions, tokens, or delegated access paths. For teams managing machine and agent populations, the useful anchor is Joiner-Mover-Leaver (JML) Guide, because lifecycle hygiene is necessary but still not sufficient for runtime trust.

What Governance Needs Beyond Access Certification

Good AI governance needs two layers: entitlement governance and action governance. Entitlement governance asks whether the AI should have access at all, while action governance asks whether each use of that access remains within approved purpose, scope, and boundaries. If those layers are collapsed into one IGA workflow, the organisation gets a clean audit trail and an incomplete control story.

The best practical pattern is to make IGA the source of truth for assignment, ownership, and periodic review, then pair it with runtime policy enforcement, logging, and exception handling for actual AI behaviour. If an AI agent can reach production systems, the control objective is not merely to confirm its role, but to bound what it can do with that role. That is why Access Reviews and Certification Guide matters as a governance control, while Segregation of Duties (SoD) Guide becomes the test for whether those grants can be used in harmful combinations.

Risk and Threat Considerations

When AI access is governed only through IGA, the organisation can end up with a false sense of control. The access record looks clean, but an AI system may still execute unsafe, unexpected, or policy-breaking actions after approval, especially where tools, memory, or delegated permissions broaden the blast radius.

Failure mechanism: Static entitlement review cannot see runtime behaviour, so drift, shadow workflows, and multi-step misuse remain invisible until the AI has already acted.

Impact: Valid-looking credentials can mask unsafe action paths, creating exposure to data misuse, process violations, and downstream compromise of systems the AI is allowed to reach.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and NIST AI RMF set the technical controls, and ISO/IEC 42001:2023 defines the regulatory obligations.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	AI runtime misuse of granted access is a core agentic identity-risk pattern.
	ASI02 — Tool Misuse	The gap is about tools being used outside intended policy after access approval.
	ASI08 — Cascading Failures	Unsafe AI actions can propagate through connected systems after a governance miss.
Recommendation — Constrain agent privileges and verify each tool/action against runtime policy. Gate tool use by context and block unauthorized action chaining. Contain blast radius with circuit breakers and scoped execution boundaries.
NIST SP 800-53 Rev 5	AU-12 — Audit Generation	Runtime AI governance depends on evidence of actual actions, not just access grants.
	AC-6 — Least Privilege	IGA-only governance fails when AI retains more access than its runtime task requires.
	IA-9 — Service Identification and Authentication	AI systems and agents need strong identity controls, but identity alone does not ensure safe use.
Recommendation — Generate logs for AI actions that matter to security and accountability. Restrict each AI to the minimum permissions needed for the task. Authenticate AI services and bind their identities to approved exchanges.
NIST AI RMF	GOVERN — Govern	AI governance must cover accountability, oversight, and control objectives beyond entitlement review.
	MAP — Map	Understanding AI use context is necessary to identify where static IGA misses runtime risk.
Recommendation — Assign accountability for AI runtime oversight and escalation. Map AI use cases, actors, and downstream impacts before approving access.
ISO/IEC 42001:2023	4.1 — Understanding the organization and its context	AI governance needs context around how systems behave after access is granted.
	8.1 — Operational planning and control	Operational controls must govern AI execution, not just provisioning records.
Recommendation — Define the operating context that makes runtime AI controls necessary. Implement operational controls that constrain AI behaviour during use.

Practitioner Guidance

What to verify: For every AI system in scope, verify both the approved access grant and the runtime conditions under which that access can be used. If you cannot point to a control that limits tool calls, data egress, or privileged action at execution time, the governance model is incomplete.

Decision rule: If the AI can take actions that affect production, customer data, or downstream automation, treat IGA as one control input, not the control boundary. Require runtime monitoring, scoped delegation, and an explicit exception path for any action that can materially change state.

Practitioner takeaway: IGA can tell you who was allowed to act, but AI governance only becomes defensible when you can also show what the system was permitted to do, in context, at the moment it acted.