They need one governance model that ties people, service accounts, bots, and tokens to the OpenAI actions they can perform. Without that cross-identity view, reviews become fragmented and auditors cannot see who can do what across the full AI stack.
How IAM and IGA split the work in AI projects
In AI projects, IAM handles the mechanics of access, who authenticates, what credentials exist, and how a workload or user gets into a system. IGA handles the governance layer, including ownership, role design, entitlement review, segregation of duties, and evidence that the right identities still have the right access as the project changes.
The practical distinction matters because AI programmes often mix human users, service accounts, bots, automation, and short-lived tokens. If those are managed separately, the organisation loses the ability to answer a simple question consistently: which identity can invoke which AI action, in which environment, and under what approval or exception.
For teams building that model, the baseline usually starts with identity inventory and lifecycle discipline. NHIMG’s IAM and IGA Basics is useful because it ties authentication, authorization, access review, and governance of people and machines into one operating model rather than treating them as separate programmes.
How teams govern people, service accounts, bots, and tokens together
The cleanest approach is to treat every actor that can trigger an AI action as part of one governed access model, even if the technical controls differ. A human may request access through an access workflow, while a service account or bot may authenticate with certificates, keys, or federated tokens, but all of them should resolve to the same governance record: owner, purpose, scope, expiry, and allowed action set.
That record is what lets IGA teams review the full chain from identity to action. Without it, an access review might cover the developer’s account but miss the bot that calls the model, the integration account that pulls data, or the token used by an internal app to invoke the OpenAI API. NHIMG’s Access Reviews and Certification Guide speaks directly to that review problem, especially where reviewers need context rather than a raw entitlement list.
Lifecycle control is the other half of the equation. If a project ends, changes owners, or moves environments, the associated non-human access should not be left behind as static credentials or orphaned integrations. NHIMG’s Joiner-Mover-Leaver (JML) Guide is relevant because AI projects often fail at the leave and move stages, where old roles, stale tokens, and leftover automation keep working long after the original purpose has disappeared.
Identity governance also has to handle structure, not just inventory. When roles are too coarse, teams end up granting broad AI access to avoid blocking delivery; when roles are too fine, review volume becomes unmanageable. NHIMG’s Role Mining and Role Design Guide helps explain why AI projects need separate treatment for humans, applications, and automation rather than forcing all access into one generic role pattern.
What breaks when AI access is reviewed identity by identity instead of end to end
The main failure mode is fragmentation. Human access gets reviewed in one tool, machine credentials live in another, API tokens sit in a pipeline secret store, and the actual AI action is visible only inside the application. That gap makes it easy to miss excessive privilege, hidden shared accounts, and access that no one can tie back to a named owner.
A second failure is weak separation of duties. AI projects frequently combine development, data access, prompt management, model operations, and production support, so one identity can quietly accumulate enough reach to change inputs, outputs, or controls without meaningful oversight. NHIMG’s Segregation of Duties (SoD) Guide is a good fit here because SoD has to extend beyond humans when bots and service identities can create the same conflict patterns.
There is also a recurring access-governance problem around shared or reused identities. If multiple AI workflows reuse the same token, service principal, or bot account, reviewers can no longer tell which workflow actually used the privilege, and incident response becomes much harder. NHIMG’s Top 10 NHI Issues is a strong reference point for the kinds of lifecycle, visibility, and privilege problems that typically surface when AI projects scale faster than governance.
Risk and Threat Considerations
AI projects expand the attack surface when access is split across people, service accounts, bots, and tokens without a single governance view. The risk is not just over-permission, but also untraceable action, where a compromise or misuse path cannot be linked back to a responsible owner, a valid purpose, or a current approval.
Failure mechanism: Stale tokens, shared automation credentials, and loosely controlled bot accounts let an attacker or careless insider reuse legitimate access paths while bypassing the human review process.
Impact: The organisation can end up with unauthorized model calls, data exposure, manipulated outputs, or failed audits because it cannot prove who had access to which AI action at the time.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CSA Cloud Controls Matrix and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | AI projects depend on controlling human and machine credentials, tokens, and secret lifecycles. |
| IA-9 — Service Identification and Authentication | Covers service accounts, bots, and workload identities that authenticate to AI services. | |
| AC-2 — Account Management | AI access needs governed provisioning, review, and revocation across people and non-human accounts. | |
| Recommendation — Manage tokens, keys, and other authenticators so AI access can be rotated, revoked, and traced. Apply service authentication controls to every non-human identity that invokes AI actions. Inventory and govern all AI-related accounts through lifecycle provisioning and removal. | ||
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Cloud AI projects need unified identity governance across users, services, and machine access. |
| LOG — Logging and Monitoring | AI access governance depends on visibility into identity use across the stack. | |
| Recommendation — Use IAM controls to unify human and non-human access governance for AI workloads. Log identity use so AI action ownership and access anomalies remain reviewable. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | AI projects need policy-based access control across people and machine identities. |
| A.8.5 — Secure authentication | Machine and human access to AI systems depends on strong authentication methods and secret handling. | |
| Recommendation — Define and enforce access-control rules for all identities involved in AI. Require secure authentication for every identity that can invoke AI services. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account governance is central when AI projects use both human and non-human accounts. |
| Recommendation — Track, review, and remove AI accounts and credentials on a defined lifecycle. | ||
Practitioner Guidance
What to prioritise: Build one entitlement model that maps every AI-relevant action to both the human approver and the non-human actor that executes it. If you cannot name the owner, purpose, expiry, and scope for an identity, treat the access as unresolved rather than temporary.
What to verify: Confirm that access reviews include service accounts, bots, tokens, and any delegated or federated credentials used by the AI stack. The useful test is whether a reviewer can see the full chain from requester to runtime action without jumping between IAM, pipeline, and application records.
Common mistake: Treating AI governance as an application-only problem. In practice, the control failure often starts in identity lifecycle and review discipline, not in the model itself.
Practitioner takeaway: The governing question is not “who can log in?”, it is “which identity can cause which AI action, and can we prove why that access still exists?”