AI agents can choose actions dynamically, combine tools in unexpected ways, and respond to live content that may be malicious or misleading. Ordinary automation usually follows predetermined paths, but agentic systems need runtime policy checks because the risk appears when the action is executed, not when the code is written.
Why This Matters for Security Teams
Agentic systems change the control problem because the risky decision often happens at runtime, after the prompt, tool call, or retrieved content has already entered the execution path. That means a clean code review does not guarantee safe behaviour. Security teams need to think in terms of action authorisation, tool scoping, data provenance, and output validation rather than only software release governance. The NIST AI Risk Management Framework is useful here because it treats AI risk as an ongoing lifecycle concern, not a one-time build issue.
The practical difference is that ordinary automation usually executes a fixed workflow with stable inputs and predictable branching. An AI agent can inspect content, decide which tool to use, chain multiple calls, and adapt its next step based on what it learns. That expands the attack surface to include prompt injection, malicious retrieval content, tool abuse, and unsafe delegation. The control objective is not only to prevent failure, but to constrain what the system is allowed to do when it encounters ambiguous or adversarial inputs. In practice, many security teams encounter agent misuse only after a tool has already been invoked with the wrong context, rather than through intentional design of runtime guardrails.
How It Works in Practice
Effective control design for AI agents starts by separating model reasoning from action authority. The model may suggest a step, but a policy layer should decide whether that step is permitted, whether it needs human approval, and whether the target data or system is in scope. This is why frameworks such as the OWASP Agentic AI Top 10 and the CSA MAESTRO agentic AI threat modeling framework focus on agent-specific failures such as over-permissioned tools, untrusted instructions, and chained action abuse.
In operational terms, teams usually need four control layers:
- Input controls that filter prompts, retrieved documents, and external messages for malicious instructions or sensitive leakage.
- Action controls that enforce least privilege, step-up approval, and allowlists for tools, APIs, and destinations.
- Context controls that separate trusted system instructions from untrusted content and preserve provenance across retrieval and tool outputs.
- Output controls that validate what the agent is about to send, store, execute, or escalate.
Detection also matters. Adversarial behaviour is often better understood through threat patterns in the MITRE ATLAS adversarial AI threat matrix, especially where prompt injection or data poisoning leads to unsafe downstream actions. Security monitoring should therefore include agent traces, tool invocation logs, and exception paths, not only application logs. The strongest deployments pair policy enforcement with auditability, so that every high-risk action can be traced back to the prompt, retrieved evidence, and rule decision that allowed it. These controls tend to break down when agents are allowed direct access to production APIs without a mediation layer because the model can turn ambiguous instructions into irreversible actions.
Common Variations and Edge Cases
Tighter runtime controls often increase friction, so organisations have to balance automation speed against blast-radius reduction. That tradeoff is especially visible when teams want an agent to complete multi-step tasks autonomously but also require approval for every sensitive action. Best practice is evolving here, and there is no universal standard for the exact approval threshold yet.
Some environments need stronger controls than others. Customer-facing assistants, systems that handle regulated data, and agents that can send emails, change records, or trigger payments warrant stricter tool scoping than an internal drafting assistant. The security posture should also change when the agent can browse live content, because live retrieval creates a path for prompt injection through documents, webpages, tickets, and chat content. In those cases, the question is not whether the model is “smart enough,” but whether untrusted input can ever become authority.
For governance, the key distinction is that ordinary automation can often be certified by verifying code paths, while agentic systems require ongoing control over decision rights. Guidance from NIST AI Risk Management Framework and the Anthropic report on an AI-orchestrated cyber espionage campaign both point to the same practical lesson: visibility, containment, and revocation are more important than assumptions about model intent. The hardest cases are long-running agents with persistent memory, broad tool access, and weak human oversight because failures compound quietly until a high-trust action is taken.
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, MITRE ATLAS and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | GOVERN | Agent controls need governance, accountability, and lifecycle risk ownership. |
| OWASP Agentic AI Top 10 | A01 | Prompt injection and tool abuse are core agent-specific failure modes. |
| MITRE ATLAS | AML.TA0002 | Adversarial AI tactics help map how agents are manipulated at runtime. |
| CSA MAESTRO | MAESTRO addresses threat modeling for autonomous, tool-using AI systems. | |
| NIST CSF 2.0 | PR.AC-4 | Least privilege is essential when agents can invoke tools and access sensitive systems. |
Map agent abuse paths to ATLAS tactics and build detections for malicious inputs and downstream misuse.
Related resources from NHI Mgmt Group
- Why do autonomous AI agents create a different IAM problem from ordinary automation?
- Why do AI agents create more NHI risk than ordinary developer automation?
- Why do AI agents need separate governance from ordinary automation?
- Why do service accounts and AI agents need different controls from human users?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
