How do organisations decide whether an AI agent needs NHI controls, AI controls, or both?

Why This Matters for Security Teams

Organisations usually get this wrong by treating an AI agent as either “just another app” or “just another AI model.” In reality, the deciding factor is what the agent can do at runtime. If it holds secrets, calls APIs, or acts through delegated credentials, it has an NHI footprint. If it chooses tools, sequences actions, or changes behaviour without a person approving each step, it also creates an AI governance problem. That is why agent reviews need both identity and behaviour lenses, not a single control lens.

The risk is not theoretical. In SailPoint’s AI Agents: The New Attack Surface report, 80% of organisations said their AI agents had already acted beyond intended scope, including unauthorised system access and revealing credentials. That aligns with broader guidance in the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework, both of which emphasise runtime risk, oversight, and accountability rather than static trust assumptions.

For NHI practitioners, the key question is not whether an agent “has an account,” but whether that account can be safely bounded, rotated, and revoked. In practice, many security teams discover agent overreach only after sensitive data has already moved or a tool chain has already been abused, rather than through intentional design review.

How It Works in Practice

A practical decision tree starts with identity, then adds autonomy. If the workload needs credentials, tokens, certificates, or delegated access to reach data and tools, it should be treated as an NHI and governed with the same discipline as service accounts or API keys. That means inventory, ownership, scoped permissions, rotation, offboarding, and monitoring. NHIs are still a major weak point across enterprises, and NHI Mgmt Group notes that 97% carry excessive privileges in the Ultimate Guide to NHIs, which is a strong signal that AI agents inherit the same privilege problems if left unmanaged.

If the agent can decide which tool to invoke, what data to combine, or whether to continue a workflow, AI controls must be added on top. Current guidance suggests intent-based or context-aware authorisation: the system evaluates what the agent is trying to do at request time, not only what role it was assigned at deployment. That is the pattern reflected in the CSA MAESTRO agentic AI threat modeling framework and the NIST Cyber AI Profile (IR 8596).

• Use NHI controls for workload identity, secret custody, JIT credentialing, and revocation.
• Use AI controls for prompt injection resistance, tool-use limits, approval gates, logging, and policy enforcement.
• Use both when the agent is autonomous and can move from reasoning to execution without human review.

In implementation terms, that often means short-lived credentials issued per task, policy-as-code checks at runtime, and a clear boundary between “can authenticate” and “is allowed to act.” These controls tend to break down when multiple agents share the same long-lived token because attribution, revocation, and containment become ambiguous.

Common Variations and Edge Cases

Tighter control often increases operational overhead, so organisations have to balance safety against workflow friction. That tradeoff is most visible in high-frequency agents, where constant approval gates can stall work, but fully standing privileges create unacceptable blast radius. Best practice is evolving, not settled, for where to place that boundary.

One common edge case is a passive AI service that only classifies or summarises content. If it never calls tools and never holds secrets, AI governance may be lighter, while NHI controls may still be needed only around the hosting workload itself. Another is a “copilot” that starts read-only but later gains write access or delegated credentials. At that point, it crosses into both domains and should be re-assessed immediately. The same applies to multi-agent pipelines where one agent plans and another executes: the planner may need AI governance, but the executor often needs strict NHI scoping and JIT credentials, especially under OWASP NHI Top 10 guidance and the NIST AI Risk Management Framework.

The hardest cases are agents that chain tools across domains, because a harmless first action can become privilege escalation in the second or third step. For those, the safest answer is usually both: treat the identity as an NHI, treat the behaviour as an AI system, and require runtime policy checks before every sensitive action.

Related resources from NHI Mgmt Group

• How do organisations decide whether an AI workflow needs stricter controls?
• How do IAM teams decide whether an AI use case needs new controls or better NHI hygiene?
• How can organisations decide when an AI agent needs higher controls?
• When should organisations treat an AI agent as a privileged system?