Should organisations use new AI-specific identity standards or existing ones?

Organisations should start with existing standards such as PKI, OAuth 2.1, and OpenID Connect, then extend them with federation and metadata governance where needed. New standards are not automatically better if the underlying trust problem is already covered by mature identity controls. The practical test is whether the standard improves attribution, scope, and revocation.

Why This Matters for Security Teams

The question is not whether AI should be treated as a special case, but whether its trust model changes enough to justify new standards. For many enterprise use cases, it does not. Existing identity controls already cover attribution, scope, consent, federation, and revocation. The real security gap is usually operational: secrets spread into code, CI/CD, and tickets faster than teams can govern them. NHI Mgmt Group notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, and that 79% have experienced secrets leaks. See the Ultimate Guide to NHIs and Top 10 NHI Issues for the underlying governance pattern.

Standards only matter when they improve a control outcome. If a new AI-specific identity standard cannot tighten assurance, shorten credential lifetime, or make revocation more reliable than established patterns such as PKI, OAuth 2.1, and OpenID Connect, it adds complexity without reducing risk. That is why NIST’s NIST Cybersecurity Framework 2.0 remains useful as a governance anchor: it frames identity as a risk and lifecycle problem, not a branding exercise. In practice, many security teams encounter identity failure only after an exposed token has already been reused by an attacker.

How It Works in Practice

A pragmatic model starts with existing identity primitives and extends them only where the workload demands it. Human operators and service accounts can continue to use mature federation, assertion, and token issuance patterns, while AI systems inherit tighter metadata governance around purpose, audience, expiry, and downstream tool access. For autonomous or agentic workloads, the strongest direction is not a brand-new identity stack but a shift toward workload identity, JIT credentials, and runtime policy. Current guidance suggests that the agent should prove what it is, what task it is executing, and what context justified access at that moment.

• Use Ultimate Guide to NHIs — Standards as the baseline for lifecycle, visibility, and revocation.
• Issue short-lived credentials per task rather than long-lived static secrets.
• Evaluate access at request time with policy as code, not only at enrolment time.
• Bind the agent to a cryptographic workload identity so the system can attribute tool use precisely.

This is where existing standards and emerging AI governance can coexist: OAuth 2.1 and OpenID Connect can handle delegated access, while additional metadata can express intent, scope, and expiry for the AI workflow. For the attacker perspective, the speed of misuse is the warning signal. Entro Security found exposed AWS credentials were often probed within minutes, which is why DeepSeek breach and similar incidents matter as evidence of how quickly secrets become operationally dangerous. These controls tend to break down in multi-agent pipelines with shared tool permissions because privilege propagation becomes hard to trace and revoke.

Common Variations and Edge Cases

Tighter identity controls often increase integration overhead, requiring organisations to balance stronger attribution against deployment friction. That tradeoff is especially visible when an AI system must work across multiple clouds, vendors, or data domains. In those environments, the best practice is evolving, and there is no universal standard for this yet. Some teams may prefer to extend existing identity frameworks with trust metadata, while others will pilot AI-specific governance overlays for policy enforcement and auditability.

The main exception is a highly autonomous agent that chains tools, writes code, and triggers actions across systems without human review. In that case, static RBAC is usually too coarse, because the access pattern changes with the task. JIT provisioning, ephemeral secrets, and intent-based authorisation become more important than naming a new identity standard. NIST AI governance guidance and agentic ai research both point in that direction; the operational question is whether the control is enforced at runtime, not whether the label is novel. See also the 52 NHI Breaches Analysis for the repeated pattern of overbroad access and slow revocation, and NIST’s NIST Cybersecurity Framework 2.0 for the governance lens. Organisations should use new standards only when they measurably improve revocation, federation, or context-aware authorisation.

Related resources from NHI Mgmt Group

• How should organisations use AI in access request approval without weakening control?
• Should security teams replace PAM with a new identity model?
• How should organisations handle privileged access when workloads and AI systems are part of the model?
• What is the Agentic AI identity governance framework organisations should adopt?