What breaks is accountability, not just visibility. Usage governance can tell you what was typed into a model, but it cannot show which agent identity acted, which permissions it held, or whether those permissions were ever removed. That leaves a gap in access review, ownership, and regulatory evidence that security teams will eventually have to close.
Why This Matters for Security Teams
AI usage governance answers a narrow question: what did the user or prompt do inside the model experience. It does not answer the security questions that matter when an autonomous workload can call tools, fetch secrets, trigger workflows, or impersonate a service. That is why AI identity becomes the control plane, not a side topic. NIST’s Cybersecurity Framework 2.0 and the NIST Cyber AI Profile (IR 8596) both push organisations toward governed outcomes, but they do not remove the need to know which identity executed the action.
The failure mode is familiar in NHI incidents. Security teams often have logs of model prompts, chat history, or policy acknowledgements, yet still cannot determine which agent held standing access, whether a token was shared across workflows, or who approved revocation. NHIMG’s research on the State of Secrets in AppSec shows how confidence and control often diverge in practice, especially when secrets are distributed across teams and systems. In practice, many security teams encounter the access problem only after an agent has already used a permission they never meant to grant.
How It Works in Practice
Identity governance for AI has to follow the workload, not just the interface. A human can be governed through login history and application usage. An agent, by contrast, may authenticate once, chain multiple tools, and operate for hours with changing intent. That is why current guidance increasingly points toward workload identity, runtime authorisation, and short-lived credentials rather than static entitlements. The operational goal is to prove what the agent is, what it is allowed to do right now, and when that permission expires.
Practically, teams should separate three layers:
- Identity: a cryptographic workload identity such as SPIFFE or an OIDC-based service identity that proves the agent instance.
- Authorisation: policy-as-code evaluated at request time, not only at onboarding, so decisions reflect the current task and context.
- Credential lifecycle: JIT issuance of short-lived secrets or tokens that are revoked automatically when the task completes.
This is where AI usage-only controls fail. They can show a prompt, but not whether the agent pulled from a vault, queried production data, or escalated through another service. NHIMG’s Lifecycle Processes for Managing NHIs and the 52 NHI Breaches Analysis both reinforce the same operational lesson: identity lifecycle, rotation, and revocation are decisive when a machine acts autonomously. For implementation detail, the SPIFFE model is useful because it ties permissions to workload identity rather than human session state, while NIST AI guidance helps frame governance around measurable risk and traceability.
These controls tend to break down when agents are allowed to reuse long-lived service accounts across multiple environments because the identity stops representing a single purpose and becomes impossible to audit cleanly.
Common Variations and Edge Cases
Tighter identity controls often increase integration overhead, requiring organisations to balance stronger traceability against delivery speed and platform complexity. That tradeoff is real, especially in early agent pilots where teams want quick experimentation before platform standards are mature.
There is no universal standard for this yet, but current guidance suggests the same pattern across most environments: use different identities for different agent functions, keep permissions narrowly scoped, and make revocation automatic. Shared identities are the fastest way to lose attribution. Long-lived credentials are the fastest way to lose containment. In multi-agent systems, the problem gets harder because one agent may call another, making the original request chain look clean while the effective privilege path expands underneath it.
Edge cases also matter. Batch agents may need broader temporary access than interactive copilots. Regulated workflows may require stronger evidence retention than general productivity use. Air-gapped or legacy environments may not support modern workload identity cleanly, so teams may need compensating controls such as vault-mediated secrets, stricter change windows, and explicit approval records. NHIMG’s Regulatory and Audit Perspectives and the Top 10 NHI Issues are useful references when shaping those exceptions. The core point remains unchanged: if the organisation cannot answer which AI identity acted, usage governance alone will not survive an audit or an incident review.
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 | Agentic systems need runtime identity, tool, and permission controls. | |
| CSA MAESTRO | MAESTRO addresses agent trust, orchestration, and autonomous workload governance. | |
| NIST AI RMF | AI RMF governance requires traceability and accountability for autonomous AI actions. |
Map agent lifecycle, trust boundaries, and task permissions before deployment.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 5, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
