What should organisations do when AI adoption outpaces governance?

Why This Matters for Security Teams

When AI adoption outpaces governance, the main risk is not simply “too much AI”; it is uncontrolled identity sprawl. Autonomous systems and AI agents can request tools, chain actions, and reach across environments faster than static approval workflows can respond. That makes traditional RBAC snapshots and long-lived secrets a poor fit. Current guidance suggests treating AI rollout as an identity and access problem first, then a feature delivery problem second. The least-privilege principle in NIST Cybersecurity Framework 2.0 remains the anchor, but it must be applied to workload identity, JIT credentials, and runtime policy rather than human-centric roles.

NHIMG research shows why hesitation is rational: in The 2026 Infrastructure Identity Survey, organisations that described themselves as confident in AI deployment actually reported a 72% security incident rate, compared with 33% for those that stayed cautious. That gap is a warning that speed without guardrails increases exposure. In practice, many security teams encounter their first serious AI identity failure only after an over-privileged system has already made a risky change or exposed a secret, rather than through intentional testing.

How It Works in Practice

The practical response is to slow the rollout until the identity model is explicit. That means defining what the AI system is, what it may do, and what it may never do before the next use case goes live. For autonomous workloads, best practice is evolving toward intent-based authorisation: the decision is made at request time based on the task, context, and risk, not just on a pre-assigned role. Where possible, issue JIT credentials that expire when the task completes, and prefer dynamic secrets over static credentials so the agent cannot accumulate standing privilege.

Operationally, that usually requires four controls working together:

• Workload identity as the primary identity primitive, often backed by cryptographic proof of execution rather than a shared account.
• Policy-as-code for runtime decisions, so access can be evaluated against context instead of fixed group membership.
• Short TTL secrets with automatic revocation, especially for tool access and infrastructure changes.
• Lifecycle controls for creation, review, rotation, and removal, as outlined in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.

This is also where the Top 10 NHI Issues become practical: secrets sprawl, missing ownership, and weak rotation are not abstract hygiene issues when an agent can act continuously. The same risk pattern appears in the DeepSeek breach, where exposed data and embedded secrets showed how quickly AI-related assets can become an incident surface. These controls tend to break down when AI is allowed to make infrastructure changes autonomously across many services because the blast radius grows faster than manual review can keep up.

Common Variations and Edge Cases

Tighter governance often slows delivery and can frustrate product teams, so organisations have to balance safety against release velocity. That tradeoff is real, but current practice is clear that unrestricted access is not a safe default. For high-trust environments, some teams start with read-only access and narrow tool scopes before expanding to write actions; others use human-in-the-loop approval for high-risk steps until telemetry proves the agent is stable. There is no universal standard for this yet, especially for multi-agent pipelines and hybrid human-agent workflows.

One common edge case is the “confidently wrong” agent: it may act with high certainty while being operationally mistaken. In those cases, static RBAC fails because the access problem is not who the agent is, but what the agent is trying to do right now. Another edge case is mixed estates where human admins, scripts, and agents share the same credentials. That pattern should be avoided because it destroys traceability and makes revocation unreliable. The better path is to separate human access from workload identity and use NIST Cybersecurity Framework 2.0 alongside the Ultimate Guide to NHIs — Regulatory and Audit Perspectives to keep audit evidence tied to the actual identity and action path, not a shared account. Best practice is evolving, but the practical rule is simple: if the AI cannot be bounded, monitored, and revoked cleanly, it is not ready for broader production use.

Related resources from NHI Mgmt Group

• What makes agentic AI an NHI governance issue?
• Why is NHI governance critical in the age of AI attacks?
• Why is single-provider AI agent governance not enough for enterprise security?
• Why is visibility important in AI governance?