Define which systems the agent may touch, which tools it may call, what evidence will be logged, and where human approval is still required. If those boundaries are unclear, the agent can expand into actions the programme cannot meaningfully review. Governance must start before the first production workflow goes live.
Why This Matters for Security Teams
Allowing an AI agent to take production actions is not a normal application rollout. An agent can decide, chain tools, and vary its path at runtime, so IAM teams need to define the boundary before the first action is possible. Current guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both point to governance, accountability, and runtime control as prerequisites, not afterthoughts.
The practical risk is over-granting access because traditional role design assumes predictable human workflows. Agents do not work that way. They may call different tools, follow different branches, or escalate from one system to another based on context. That means the team must know which systems the agent may touch, which actions are reversible, what must be logged, and where a human must approve a step. NHIMG research on the OWASP NHI Top 10 and The State of Secrets in AppSec shows how fragmentation and weak secrets discipline quickly undermine control. In practice, many security teams encounter unsafe agent actions only after the agent has already moved beyond the intended workflow, rather than through intentional review.
How It Works in Practice
Before production enablement, IAM teams should treat the agent as a distinct workload identity, not as a user with a borrowed role. That means establishing a workload identity layer, then binding it to runtime policy that is evaluated at request time. For many teams, that includes short-lived credentials, scoped tool access, and explicit evidence capture for every privileged action. Where possible, the agent should receive just-in-time authorization for a single task rather than standing access that persists across sessions.
Operationally, this usually means four controls are defined up front:
- Allowed systems and data domains, with explicit deny rules for everything else.
- Permitted tools and actions, including write operations, deletions, and escalations.
- Logging and evidence requirements, such as prompts, tool calls, approvals, and output checks.
- Human approval points for high-impact steps, especially payment, access, deployment, or deletion actions.
The identity primitive should be the workload, not the model prompt. In practice, teams are moving toward cryptographic workload identity, such as SPIFFE-style identities or OIDC-based tokens, then layering policy-as-code through engines like OPA or Cedar. That approach fits the runtime nature of autonomous systems better than static RBAC alone, because the question is not only who the agent is, but what the agent is trying to do right now. NHIMG’s guidance in the OWASP Agentic Applications Top 10 and the threat patterns described in the AI LLM hijack breach illustrate why static permission sets are too brittle once tools can be chained dynamically. These controls tend to break down when agents are allowed to call loosely governed internal APIs because hidden privilege paths emerge faster than policy reviews can track them.
Common Variations and Edge Cases
Tighter control often increases operational overhead, requiring organisations to balance agent speed against review burden. That tradeoff is real, especially when production workflows are time-sensitive or when the agent supports many small tasks rather than one obvious high-risk action. Best practice is evolving, but current guidance suggests separating low-risk read-only actions from write-capable actions and requiring stronger approval for any path that changes state.
Edge cases usually appear in environments with shared service accounts, legacy applications, or broad platform-admin permissions. Those patterns make it difficult to prove what the agent actually touched and whether the access was proportionate to the task. The same issue appears when secrets are long-lived and reused across tools: the agent may not need human-like access, but it still inherits human-sized blast radius. NHIMG’s LLMjacking research and Moltbook AI agent keys breach case both reinforce that exposed or over-scoped keys can be abused rapidly once an agent is in production. The safe default is to narrow scope first, then expand only after the logging, approval, and revocation model has been tested in a non-production path.
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 | A1 | Agentic controls focus on limiting unsafe autonomous tool use and production actions. |
| CSA MAESTRO | MAESTRO addresses governance and threat modeling for agentic workflows and tool chains. | |
| NIST AI RMF | GOVERN | AI RMF GOVERN emphasizes accountability, oversight, and defined operating boundaries. |
Assign ownership, document boundaries, and require human oversight for high-impact agent actions.
Related resources from NHI Mgmt Group
- How should security teams limit the risk from AI agents that have access to production systems?
- How should security teams verify AI agents before allowing delegated actions?
- Why do AI agents increase non-human identity risk in existing IAM programmes?
- How should security teams manage permissions for AI agents?
