AI agents become NHI risk when they can act with delegated authority, such as calling APIs, querying data, or executing workflows. At that point, they need the same discipline used for service accounts and tokens: least privilege, audit logging, scoped permissions, and periodic review of what they can actually do.
Why This Matters for Security Teams
AI agents create NHI risk the moment they move from suggestion to execution. If an agent can call APIs, trigger workflows, read repositories, or open tickets on its own, it is no longer a passive model. It is an identity-bearing workload with delegated authority, and that authority needs the same controls applied to service accounts, secrets, and machine-to-machine access. The core risk is not the model output; it is what the agent can do with that output.
This is where conventional IAM assumptions break down. Static roles work best when behaviour is predictable, but agentic systems are goal-driven and can chain tools in ways humans did not pre-plan. Guidance from NIST AI Risk Management Framework and the OWASP Top 10 for Agentic Applications 2026 both point toward runtime governance, not just pre-launch approval. NHIMG research shows why the stakes are high: Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, which is exactly the condition that turns an agent into a blast-radius multiplier.
In practice, many security teams encounter agent risk only after an autonomous workflow has already touched production data or triggered an unauthorized action, rather than through intentional design review.
How It Works in Practice
Agentic risk should be treated as a question of delegated authority, not model intelligence. The practical control set starts with workload identity, then adds just-in-time credential issuance, intent-based authorisation, and continuous auditing. A mature pattern is to let the agent prove what it is, request what it intends to do, and receive short-lived access only for that specific task. That is very different from handing an agent a long-lived API key and hoping RBAC will contain the damage.
Current guidance suggests using cryptographic workload identity, such as SPIFFE or OIDC-based assertions, to bind the agent to a known runtime context. From there, policy decisions should be evaluated at request time, not baked into a static role table. Frameworks such as the CSA MAESTRO agentic AI threat modeling framework and MITRE ATLAS adversarial AI threat matrix reinforce the need to model tool chaining, lateral movement, and misuse of intermediate outputs.
- Issue ephemeral secrets per task, with automatic revocation when the action completes.
- Use policy-as-code for intent checks, so approval depends on context, destination, and data sensitivity.
- Separate model inference from execution privileges, so the agent cannot act just because it can reason.
- Log every tool call, token use, and privilege elevation for later review.
NHIMG analysis has repeatedly shown that credentials and keys become the real failure point, not the model itself, as seen in the Moltbook AI agent keys breach and the OWASP NHI Top 10. These controls tend to break down when agents are allowed to operate across loosely governed SaaS tools because each system makes its own authorisation decisions and the audit trail fragments.
Common Variations and Edge Cases
Tighter agent controls often increase operational overhead, requiring organisations to balance speed of execution against the cost of more frequent policy checks and credential churn. That tradeoff becomes especially visible in multi-agent systems, where one agent delegates to another or hands off partial state. Best practice is evolving here, and there is no universal standard for exactly how much autonomy a sub-agent should inherit.
One common edge case is a read-heavy agent that appears low risk but can still expose sensitive data through retrieval, summarisation, or downstream prompt injection. Another is a developer agent that only runs in CI/CD but still has enough scope to modify pipelines, publish packages, or rotate secrets. The right control is not simply “less privilege,” but “the minimum privilege for this intent, in this environment, for this time window.” The NIST Cybersecurity Framework 2.0 remains useful for mapping this into governance, while Analysis of Claude Code Security highlights how quickly coding agents can become privileged operators.
In environments with legacy IAM, shared service accounts, or broad CI/CD tokens, these controls often collapse because the agent cannot be isolated cleanly from the human or pipeline identity it inherited.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agentic tool use and delegation create the core risk here. |
| CSA MAESTRO | GOV-2 | MAESTRO covers governance for autonomous agent behaviour and escalation paths. |
| NIST AI RMF | AI RMF addresses governance and risk management for autonomous AI systems. |
Use AI RMF GOVERN and MAP functions to assign accountability and operational controls for agents.
