Security teams should test both input filtering and action controls. If an AI system can be persuaded to reveal data, call tools it should not use, or chain requests into unsafe steps, access control alone is not enough. The stronger pattern is to constrain what the system can do, add policy checks before execution, and monitor for abnormal tool use.
Why This Matters for Security Teams
agentic ai changes the control problem because the risk is not only what the model can say, but what it can do once it is allowed to act. If an application can be manipulated into unsafe actions, prompt filtering alone is insufficient, since the real exposure sits in tool execution, data access, and chained actions. Current guidance from the OWASP Agentic AI Top 10 and NHI research such as OWASP NHI Top 10 both point to the same issue: autonomy expands the blast radius of a single manipulated request.
That is why security teams should judge controls by whether they stop unsafe actions at runtime, not whether they merely block suspicious text. The right question is whether the agent can be constrained before it reaches a database, a payment step, or a credentialed API call. In practice, many security teams encounter unsafe agent behaviour only after the system has already chained tools, moved laterally, or disclosed data rather than through intentional testing of action boundaries.
How It Works in Practice
Effective evaluation starts with the agent’s execution path. Teams should map each tool, connector, and downstream privilege, then test whether the system can be induced to exceed its intended scope. This includes direct prompt injection, indirect prompt injection through retrieved content, and multi-step abuse where one harmless action becomes a later unsafe action. The NIST AI Risk Management Framework is useful here because it pushes teams to evaluate governance, measurement, and operational controls together rather than as separate checkboxes.
Practitioners should validate three layers:
- Input controls that reduce malicious instructions, but do not assume they solve the problem alone.
- Action controls that enforce allowlists, scoped permissions, human approval for high-risk steps, and policy checks before execution.
- Runtime monitoring that logs tool calls, detects unusual sequences, and flags attempts to chain low-risk actions into high-risk outcomes.
For autonomous systems, the better pattern is often just-in-time privilege, short-lived secrets, and workload identity, because the agent should only hold authority for the exact task window. That aligns with the threat model described in the AI Agents: The New Attack Surface report, where agents were already observed acting beyond intended scope. Security teams should also compare this behaviour against implementation guidance in the CSA MAESTRO agentic AI threat modeling framework and test whether policy is evaluated at request time rather than assumed from static role assignment.
These controls tend to break down in highly connected environments where a single agent has broad tool access across multiple systems, because one compromised step can cascade into unauthorized execution across the workflow.
Common Variations and Edge Cases
Tighter action controls often increase workflow friction, requiring organisations to balance safety against speed, automation depth, and operator burden. There is no universal standard for this yet, so current guidance suggests tuning controls to the risk of the task rather than applying one model everywhere.
High-trust internal assistants may tolerate broader read access but still need strict write barriers. Customer-facing agents usually need stronger guardrails because untrusted input is part of the normal operating environment. Multi-agent setups add another wrinkle: one agent may pass unsafe instructions to another, so the evaluation must cover inter-agent communication, not just the primary prompt. That is why NHI-focused analysis such as LLMjacking: How Attackers Hijack AI Using Compromised NHIs remains relevant, especially where credentials or API keys can be abused once the agent crosses a boundary.
Teams should also treat static API keys and long-lived tokens as a weak fit for autonomous workloads. Short-lived credentials, policy-as-code, and per-action authorization are more resilient when behaviour is unpredictable. The NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both support this direction, but best practice is still evolving for chained, tool-rich environments.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 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 |
|---|---|---|
| OWASP Agentic AI Top 10 | Covers prompt injection and unsafe tool execution in agentic apps. | |
| CSA MAESTRO | Focuses on threat modeling for agent workflows, tools, and control points. | |
| NIST AI RMF | Supports governance and measurement for AI risk, including runtime controls. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Short-lived secrets and credential hygiene reduce abuse after manipulation. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access control limit damage from manipulated tool use. |
Replace long-lived agent secrets with JIT credentials and revoke them immediately after task completion.
Related resources from NHI Mgmt Group
- How should security teams implement agentic AI controls when autonomous systems can take actions across multiple business tools?
- How should security teams govern agentic AI in disconnected applications?
- How do security teams decide which controls to prioritise for AI applications?
- How should security teams evaluate identity controls against AI-driven attacks?
