Why do AI systems make NHI risk harder to control?

Why This Matters for Security Teams

AI systems are harder to control because they do not stay inside fixed human-style job descriptions. A single agent can request tools, chain actions, invoke APIs, and change its own next step based on new context. That makes the identity question less about who is logged in and more about what the workload is authorised to do right now. Traditional RBAC and long-lived secrets were built for stable roles, not autonomous behaviour. Current guidance increasingly points toward Zero Trust thinking, where every action is rechecked at runtime, as reflected in NIST Cybersecurity Framework 2.0 and in NHI governance guidance from Ultimate Guide to NHIs. The problem intensifies when agents can reach production data, infrastructure, or downstream agents without a human pause point. That is why NHI risk becomes harder to control: the identity is still non-human, but the behaviour is now dynamic, delegated, and often goal-driven. In practice, many security teams encounter excessive privilege only after an agent has already used it to touch systems that were never intended to be in scope.

How It Works in Practice

The practical shift is from static permissioning to runtime validation. Instead of granting an agent a broad role for the life of a process, security teams are moving toward intent-based authorisation, where the decision depends on the action requested, the data involved, the system being touched, and the current risk context. That is especially important for agentic systems that can call tools unpredictably. NIST Cybersecurity Framework 2.0 supports this direction through access governance and continuous monitoring, while OWASP NHI Top 10 highlights the risks created when autonomous applications accumulate identity exposure. Common controls include:

• JIT credential provisioning so access is issued per task and expires automatically.
• Workload identity backed by cryptographic proof, so the system knows what the agent is before it receives any secret.
• Short-lived secrets and tokens, rather than static API keys that can be reused after a task ends.
• Policy evaluation at request time, ideally with policy-as-code, so the next action is checked against current context.
• Scoped tool access, so the agent can only call the minimum set of functions needed for the current objective.

NHIMG research shows why this matters operationally: the Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges and 96% of organisations store secrets outside secrets managers in vulnerable locations. Those conditions become more dangerous when an agent can decide its own next move. These controls tend to break down when agents are given broad API access across heterogeneous SaaS, cloud, and internal systems because policy coverage becomes inconsistent at the exact moment the workload starts chaining tools.

Common Variations and Edge Cases

Tighter control often increases operational overhead, requiring organisations to balance reduced blast radius against workflow latency and integration complexity. That tradeoff is real, especially in environments where agents must act quickly or across many systems. For that reason, best practice is evolving rather than settled in every detail, and there is no universal standard for how much autonomy should be paired with how much privilege. One common edge case is multi-agent orchestration: one agent may be trusted to plan, another to execute, and a third to validate, which complicates identity and accountability. Another is tool-rich development environments, where an AI agent can trigger code changes, CI/CD runs, and cloud actions in one chain. The Top 10 NHI Issues and 52 NHI Breaches Analysis both reinforce the same lesson: identity failures usually emerge where governance is fragmented across systems, not where one control is entirely missing. In agentic environments, the most reliable approach is to combine ZSP thinking, short TTLs, and continuous re-authorisation, while accepting that some high-risk actions may still require human approval until policy maturity catches up. This guidance becomes less effective when legacy systems cannot support per-request policy checks or when secrets must be shared across long-running jobs without a clean revocation point.

Related resources from NHI Mgmt Group

• Why do AI agents make non-human identity governance harder?
• How should security teams limit the risk from AI agents that have access to production systems?
• Why do AI agents create new risk in non-human identity management?
• Why do AI agents increase non-human identity risk in existing IAM programmes?