They should place controls at each boundary where the agent can access models, tools, data, or enterprise systems. The objective is to make authorisation follow behaviour, not just account provisioning. That creates a practical governance layer for agent identity across the systems the agent can actually affect.
Why This Matters for Security Teams
For AI agents, the control point is not the login event. It is each moment the agent can invoke a model, call a tool, read data, or trigger an enterprise action. That is why static RBAC alone is usually too blunt for agentic workloads. Guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework points toward runtime governance, not one-time provisioning. NHI teams should therefore place controls where the agent can cause impact, while IAM defines who owns the identity and which baseline entitlements exist.
That distinction matters because autonomous behaviour changes the risk profile. An agent can chain tools, expand scope, or pursue a goal in ways a human session rarely does. NHIMG research shows that 88.5% of organisations say their non-human IAM practices lag human IAM, which helps explain why many agent deployments start with broad access and only later discover overreach through incident response rather than design. The practical takeaway is simple: if the agent can reach it, a control boundary should exist there, even if the identity was provisioned elsewhere. In practice, many security teams encounter excessive reach only after an agent has already touched a sensitive system, rather than through intentional architecture.
How It Works in Practice
The most reliable pattern is layered control. IAM establishes the agent identity, workload identity, and ownership. NHI governance then places policy enforcement at each boundary: model gateway, tool broker, data store, API, queue, and admin action. This is closer to Zero Trust than classic account administration, because every request is evaluated in context. The CSA MAESTRO agentic AI threat modeling framework and NIST AI Risk Management Framework both support this shift from static trust to continuous assessment.
In practice, teams should combine these controls:
- Issue JIT credentials for a task, then revoke them on completion or timeout.
- Use short-lived workload identity, such as OIDC or SPIFFE-based proof, so the system knows what the agent is and which workload owns it.
- Apply intent-based authorisation at request time, so the policy engine can decide whether the agent’s current goal matches the action.
- Separate model access from data access and from tool execution, so compromise in one boundary does not grant the others.
- Log every decision point to show why the agent was allowed, denied, or constrained.
NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is exactly why agent controls need to live at the edges of actual behaviour rather than in a generic account catalogue. For agentic systems, the control should follow the action path, not just the credential. These controls tend to break down when a single shared service account fronts multiple agents, because the workload identity and the business intent become impossible to separate.
Common Variations and Edge Cases
Tighter control placement often increases latency, integration effort, and policy maintenance, so organisations must balance safety against operational friction. That tradeoff is real, especially in environments where agents sit inside CI/CD pipelines, customer support tooling, or data enrichment flows that already depend on many APIs. Best practice is evolving, but there is no universal standard for this yet.
One common edge case is a multi-agent workflow where one orchestrator delegates to several specialist agents. In that model, control boundaries should exist between the orchestrator and each downstream agent, not only at the final business system. Another is a read-heavy analytical agent. It may need broad data discovery but very narrow write privileges, so the policy should be asymmetric rather than uniformly restrictive. NHIMG’s OWASP NHI Top 10 and Top 10 NHI Issues are useful here because they highlight how over-privilege, secret sprawl, and weak lifecycle control compound each other.
The clearest rule is this: place controls wherever the agent can change state, expose secrets, or cross trust boundaries. Where systems cannot support runtime policy, use compensating controls such as token scoping, network segmentation, and approval gates until the architecture catches up.
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 | Agent authentication and authorization controls | Agentic systems need runtime checks at each tool and data boundary. |
| CSA MAESTRO | Policy enforcement across agent workflows | MAESTRO maps control points across orchestrator, tools, and data paths. |
| NIST AI RMF | AI RMF governs contextual risk decisions for autonomous agent behaviour. |
Enforce per-action policy decisions for agents, not just one-time account provisioning.
Related resources from NHI Mgmt Group
- How do IAM teams decide whether an AI use case needs new controls or better NHI hygiene?
- Why do AI agents change the way IAM and governance teams think about access?
- How do organisations decide whether an AI agent needs NHI controls, AI controls, or both?
- Why do AI agents increase browser security risk for IAM teams?
