Should organisations delay AI agent production use until NHI controls improve?

Why This Matters for Security Teams

Delaying production use is less about “being anti-AI” and more about avoiding predictable failure when agents inherit weak identity hygiene. Autonomous agents do not behave like fixed service accounts: they chain tools, expand scope, and act faster than manual review can keep up. That means unresolved secrets sprawl, unclear entitlement ownership, and missing revocation paths become active risk multipliers, not just audit findings. The current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework is that agentic systems need stronger runtime controls than conventional applications, not just more policy documents.

NHIMG research reinforces that point: in The State of Secrets in AppSec, organisations reported an average of 6 distinct secrets manager instances, a pattern that fragments control and complicates revocation. In practice, many security teams encounter agent abuse only after an exposed secret or overbroad entitlement has already been exercised by an autonomous workflow.

How It Works in Practice

The production-readiness question should be treated as an identity and authorisation maturity check. If an organisation cannot tell which non-human identity owns a secret, who approves access, and how that access is revoked, then an AI agent will simply amplify the weak link. For agents, static RBAC alone is usually insufficient because access needs vary by task and by context. Best practice is evolving toward intent-based authorisation, where a decision is made at request time based on what the agent is trying to do, what data it needs, and whether the action matches current policy.

Operationally, that means pairing workload identity with just-in-time credentials. A secure pattern is to issue short-lived, task-scoped secrets or tokens, bind them to the agent’s workload identity, and revoke them automatically when the task completes. Standards such as SPIFFE/SPIRE and OIDC help prove what the agent is, while policy engines such as OPA or Cedar can evaluate whether the requested action should proceed right now. The AI Agents: The New Attack Surface report shows why this matters: 80% of organisations said their AI agents had already performed actions beyond intended scope, including revealing access credentials. That is not a theoretical concern, it is a deployment pattern.

• Use workload identity for every agent rather than shared human credentials.
• Issue credentials per task, not per environment, with short TTLs and automatic revocation.
• Map every agent to a business owner and a data owner before production access is granted.
• Evaluate permissions at runtime, not only during onboarding or quarterly review.

These controls tend to break down when agents are allowed to self-compose tools across loosely governed SaaS and internal APIs, because privilege chains become difficult to predict and revoke cleanly.

Common Variations and Edge Cases

Tighter production gating often increases delivery overhead, requiring organisations to balance speed against the cost of control design. That tradeoff is real, especially for low-risk copilots, internal automations, or read-only agents where the blast radius is limited. Current guidance suggests that not every agent needs the same control depth, but there is no universal standard for this yet. Risk-based segmentation is more practical than a blanket yes or no.

Edge cases matter. A customer support agent with access to ticket summaries is not the same as a code-action agent that can deploy to production, and a research agent with no write privileges is not the same as an autonomous workflow that can request new tokens. Where organisations usually go wrong is assuming that “internal” means “safe.” Internal agents can still exfiltrate sensitive data, chain permissive tools, or inherit overly broad service roles. NHIMG’s OWASP NHI Top 10 and the CSA MAESTRO agentic AI threat modeling framework both point to the same operational reality: identity, scope, and observability must be proven before scale, not after incident response.

The safest answer is conditional. Delay production for high-privilege, externally connected, or write-capable agents until revocation, ownership, and runtime policy evaluation are demonstrably working. For low-risk use cases, proceed only with hard task boundaries and limited data access.

Related resources from NHI Mgmt Group

• When should organisations use AI to help manage NHIs?
• When should organisations treat an AI agent as a privileged system?
• How can organisations govern AI agents that use service accounts and tokens?
• Should organisations delay production AI agents until identity governance is mature?