They often separate AI governance from identity governance, even though AI systems can shape access, code, and security decisions. That split leaves approval paths, accountability, and secret handling under-specified. A workable programme treats AI participation as part of the identity control problem.
Why This Matters for Security Teams
Organisations usually miss the real risk by treating AI governance as a policy exercise and identity controls as a separate technical track. Once an AI system can propose changes, trigger workflows, or act through tools, it becomes part of the access plane. That means approval paths, ownership, and secret handling are no longer peripheral concerns; they are the control surface. The NIST AI Risk Management Framework is useful here because it frames AI as a governed system, not just a model.
The common failure is assuming human-style controls will fit machine-speed decisions. In practice, organisations still grant AI systems broad entitlements, then try to compensate with review meetings after the fact. That is too late for systems that can chain tools, copy secrets, and move faster than a manual approval queue. NHIMG research shows this gap plainly: the Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, while the 2026 Infrastructure Identity Survey found only 44% of organisations have policies to manage AI agents. In practice, many security teams encounter over-privileged AI only after it has already touched production systems or exposed secrets.
How It Works in Practice
A workable programme starts by treating the AI system itself as an identity-bearing workload, not just a user interface. That means assigning a workload identity, binding it to a known runtime, and issuing credentials only for the specific task at hand. Standards such as SPIFFE and policy engines such as OPA are commonly used to support this model, while NIST guidance and the NHIMG lifecycle guidance for NHIs stress that identity lifecycle, rotation, and revocation must be explicit.
- Use short-lived, task-scoped credentials instead of persistent API keys or shared service accounts.
- Evaluate authorisation at request time based on context, intent, environment, and risk, not just preassigned roles.
- Separate model access from tool access so the model cannot infer broader privilege from one successful action.
- Log every action with the agent identity, the task context, and the policy decision that allowed it.
- Revoke access automatically when the task completes or the confidence threshold changes.
This is where identity governance and AI governance converge. If an agent can write code, call cloud APIs, or create downstream tasks, then the control question is not only “is the model approved?” but also “what can this workload do right now, under what context, and for how long?” The NIST Cybersecurity Framework 2.0 helps anchor that thinking in governance, risk, and control operations, while NHIMG’s Top 10 NHI Issues reinforces that secret sprawl and excessive privilege remain the practical weak points. These controls tend to break down in fast-moving CI/CD and multi-agent environments because access is often inherited, reused, or delegated faster than policy can be reviewed.
Common Variations and Edge Cases
Tighter AI identity control often increases operational overhead, requiring organisations to balance faster automation against stronger approval discipline. That tradeoff is real, especially where teams want autonomous systems to keep operating during incident response, code deployment, or customer support. Best practice is evolving, and there is no universal standard for how much autonomy to grant by default.
One edge case is delegated automation, where an AI agent acts on behalf of a human but should not inherit the human’s full entitlements. Another is multi-agent orchestration, where a planning agent may have different rights from an execution agent. In both cases, role-based access control alone is too blunt; context-aware or intent-based authorisation is better aligned, but the operational pattern is still maturing. The NIST AI Risk Management Framework and the NIST AI 600-1 Generative AI Profile both support more disciplined governance, but they do not remove the need for environment-specific policy design. For incident-driven programmes, NHIMG’s 52 NHI Breaches Analysis is a reminder that identity failures are usually about lifecycle gaps, not a single missing control.
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 | AGENT-03 | AI agents need runtime authZ and short-lived access. |
| CSA MAESTRO | M1 | Covers governance for autonomous agents and their tool use. |
| NIST AI RMF | GOVERN | AI governance must cover accountability and access decisions. |
Assign accountable owners and define AI risk controls as part of identity governance.
