How should organisations govern digital identity when AI is part of the service model?

Why This Matters for Security Teams

When AI is part of the service model, identity stops being a front-door control and becomes a governance chain. The organisation must prove who initiated the action, which service or agent executed it, what permissions were used, and which policy allowed it. That linkage is central to auditability, especially in regulated environments where an AI-assisted decision can be challenged long after the transaction completes. Guidance from NIST Cybersecurity Framework 2.0 reinforces that identity, access, and oversight are connected outcomes, not separate exercises.

The risk is not limited to bad model output. The larger problem is that AI systems often act through service accounts, API keys, or delegated tokens that outlive the task they were meant to support. NHIMG research shows how often these identities are exposed or over-privileged in practice, including the findings in the Ultimate Guide to NHIs. If the service model cannot show identity evidence at each step, investigations become guesswork instead of proof. In practice, many security teams discover this only after an AI-assisted workflow has already made an unauthorised or unreviewable decision.

How It Works in Practice

Effective governance starts by treating the initiating actor, the AI workload, and the downstream service as separate identity events. Human users still need authenticated attribution, but the AI layer also needs workload identity so the organisation can distinguish what the user asked for from what the agent actually executed. That is where intent-based authorisation, runtime policy evaluation, and short-lived credentials matter more than static role grants. A useful pattern is to issue access only for the current task, then revoke it automatically when the task completes.

For autonomous or semi-autonomous systems, best practice is evolving toward context-aware decisions at request time. Rather than giving an agent broad standing access, teams should evaluate each action against policy, data sensitivity, approval state, and business purpose. This aligns with the identity-first governance approach described in Lifecycle Processes for Managing NHIs and the broader control expectations in NIST Cybersecurity Framework 2.0. In practical terms, security teams should require:

• workload identity for the agent or service, not just a shared secret
• just-in-time issuance of credentials with short TTLs
• policy-as-code checks before sensitive actions are executed
• immutable logs that bind user intent, workload identity, and resulting access
• automatic revocation when the task, context, or trust signal changes

This model is especially important when AI touches payments, health, legal, customer support, or privileged internal workflows. The governance burden is not only to stop abuse, but to show that the AI decision was authorised, bounded, and attributable. These controls tend to break down when legacy applications only accept long-lived shared secrets because the service model cannot express task-scoped identity or runtime policy checks.

Common Variations and Edge Cases

Tighter identity governance often increases operational overhead, requiring organisations to balance auditability against system complexity and latency. That tradeoff is real, especially where AI services must respond in seconds or integrate with old platforms that were never designed for ephemeral access. Current guidance suggests that the answer is not to relax controls, but to right-size them for the risk and the workflow.

There is no universal standard for this yet, but several patterns are emerging. High-risk use cases may require explicit human approval before an AI agent can trigger privileged actions. Lower-risk workflows may allow automated execution, provided the evidence trail is complete. The strongest programs pair Regulatory and Audit Perspectives with external identity and risk guidance such as the NIST Cybersecurity Framework 2.0. The hard edge cases are shared agent pools, delegated access across vendors, and systems that blur the boundary between human instruction and machine execution. In those environments, the organisation should assume that if it cannot prove the identity chain, it cannot defend the decision.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• How should security teams govern Active Directory service accounts?
• How can organisations govern AI agents that use service accounts and tokens?
• How should organisations handle privileged access when workloads and AI systems are part of the model?