Generative AI creates IAM and IGA risk because it can change how decisions are made, who is considered accountable, and how quickly actions happen. If the organisation cannot show the identity behind the AI-enabled step, the audit trail becomes incomplete. That weakens certification, escalation, and incident review across human and machine workflows.
Why This Matters for Security Teams
Generative AI changes IAM and IGA because it introduces software that can make requests, chain tools, and act faster than human approval workflows were designed to handle. Traditional identity programs assume a person, a role, and a predictable access pattern. A genAI initiative can instead create transient, high-privilege access paths that are difficult to certify, recertify, or investigate after the fact.
That matters most when auditability is required. If a model, agent, or workflow can trigger actions but the identity behind each step is unclear, certification evidence becomes weak and incident review turns into guesswork. Current guidance in the NIST AI 600-1 Generative AI Profile and NHIMG research such as the OWASP NHI Top 10 both point to the same control gap: organisations often know where users are governed, but not where machine-issued authority begins and ends. In practice, many security teams encounter the identity problem only after an AI workflow has already accessed data, called a tool, or generated an approval trail that cannot be fully explained.
How It Works in Practice
GenAI initiatives create risk when they sit between users and enterprise systems but do not fit cleanly into existing identity models. A chatbot that drafts a request is one thing; an AI agent that authenticates, queries a CRM, updates a ticket, and invokes a downstream API is another. The latter needs workload identity, runtime authorisation, and a defensible chain of custody for every action.
Security teams usually need to separate three layers:
-
Human identity: who approved or prompted the action.
-
Workload identity: what the model, service, or agent is, using cryptographic proof such as OIDC or SPIFFE-based identities.
-
Delegated authority: what the AI is allowed to do right now, ideally with just-in-time access and short-lived secrets.
This is where static IAM and broad IGA entitlements fail. A role that is safe for a human analyst may be too permissive for an autonomous workflow that can chain prompts, tools, and API calls. Better practice is moving toward policy evaluation at request time, with context-aware rules that consider task, data sensitivity, and destination system. The NIST Cybersecurity Framework 2.0 supports the governance and control discipline, while NHIMG’s Top 10 NHI Issues highlights how weak lifecycle controls and poor secret handling show up in real environments.
For example, an AI assistant that can create support tickets should not automatically inherit the same access as the human who asked the question. It should receive time-bound credentials, scoped to one task, and those credentials should be revoked when the task ends. These controls tend to break down in legacy identity stacks that were never designed for ephemeral machine actors, especially when the same agent spans multiple clouds, business units, and API gateways.
Common Variations and Edge Cases
Tighter identity control often increases deployment friction, requiring organisations to balance faster AI delivery against stronger approval and review overhead.
Not every genAI use case has the same risk profile. A read-only internal summarisation assistant creates less IAM exposure than an agent that can modify records, send emails, or retrieve secrets from a vault. There is no universal standard for how much autonomy should map to which identity pattern yet, so current guidance suggests using a risk-tiered approach instead of a single enterprise-wide rule.
Edge cases appear when AI is embedded inside existing SaaS workflows, shadow IT tools, or low-code automation platforms. In those environments, entitlements may be hidden behind service accounts, shared tokens, or weakly governed connectors. The result is often a certification gap: access appears normal in the IAM console, but the actual machine-to-machine path is not visible to IGA reviewers. NHIMG’s research on the AI Agents: The New Attack Surface report shows why this matters operationally, with many organisations reporting limited visibility into what their AI agents can access and audit.
The practical takeaway is simple: if the AI can act, the organisation needs proof of what identity acted, what it was allowed to do, and how that authority was removed. Otherwise, certifications become checkbox exercises and incident response cannot reconstruct the full machine workflow.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | NHI-01 | GenAI agents create new identity and tool-use attack paths. |
| CSA MAESTRO | GOV-2 | Governance is needed for agent autonomy, delegation, and oversight. |
| NIST AI RMF | AI RMF addresses accountability, traceability, and risk management for genAI. |
Assign accountable owners and evidence requirements for AI-driven identity actions.
