How should security teams evaluate agentic AI controls when applications can be manipulated into unsafe actions?

Why Unsafe Actions Need a Control Review, Not Just a Prompt Review

agentic ai creates a different security problem from a chat-only model because the system can do more than answer: it can call tools, move data, and chain steps toward a goal. That means security teams need to assess whether the application can be steered into actions the operator did not intend, not just whether it can be tricked into generating harmful text. OWASP’s OWASP Top 10 for Agentic Applications 2026 is a useful reference because it treats unsafe agent behaviour as a control problem, not only a content-safety problem.

The key question is whether the system’s permissions, tool routing, and execution gates are narrower than its language capability. If they are not, a model that is only mildly steerable can still become operationally dangerous once it has access to internal systems, customer records, or workflow automation. In practice, many security teams discover this mismatch only after tool use has already been normalised inside production workflows.

How Security Teams Should Test Agentic Boundaries

Evaluation should start with the actions, not the wording. Teams need to verify what the agent can actually do when it receives a persuasive or malformed instruction, because unsafe behaviour often appears as a sequence: retrieve context, select a tool, transform the request, and then execute a change that would not be acceptable under normal approval rules. The important test is whether the application can resist being redirected from helpful assistance into unauthorised side effects.

A strong assessment usually checks three layers. First, prompt and input controls should limit obvious injection, manipulation, and instruction hijacking. Second, tool and workflow controls should enforce least privilege, scoped credentials, and explicit approval before high-impact actions. Third, monitoring should flag unusual sequences such as repeated tool calls, unexpected data retrieval, or execution that departs from the user’s stated intent. NIST’s NIST AI Risk Management Framework is relevant here because it pushes teams to assess function, context, and downstream impact rather than treating the model in isolation.

• Test whether the agent can be induced to call tools outside its intended task.
• Check whether approval gates exist for irreversible or high-impact actions.
• Confirm that logs show the user request, the model decision, and the executed action.
• Validate that denied actions fail closed, rather than silently degrading into partial execution.

These controls matter because an agent that can be manipulated into unsafe action has crossed from content risk into execution risk. Where the application has broad integrations or autonomous retries, the guidance becomes less reliable because the failure mode is no longer a single bad answer but a compounding chain of bad decisions.

Where Agentic Control Evaluations Break Down

Tighter action control often increases friction, requiring organisations to balance automation speed against approval overhead and operational delay.

One common edge case is the difference between a harmless suggestion and a harmful execution path. A model may be allowed to draft a message, summarise a record, or propose a workflow step, yet still be unsafe if it can submit the step automatically or invoke a connected system with real authority. Another issue is that strong input filtering does not solve delegated access: if the agent already has broad permissions, a clever request can still reach sensitive state through normal APIs.

There is also a governance nuance. For low-impact tools, teams may accept some conversational flexibility and rely on post-action monitoring. For high-impact tools, that trade-off is usually weak unless the system enforces pre-execution checks. OWASP’s agentic guidance and MITRE’s MITRE ATLAS adversarial AI threat matrix are both useful when a team needs to compare prompt abuse with broader adversarial patterns, but they should not be treated as a substitute for access design.

In practice, the hardest failures appear when the agent is treated as an interface layer rather than an actor with operational consequences. That is where teams most often underestimate the difference between “can answer safely” and “can act safely.”

Risk and Threat Considerations

Agentic AI introduces execution risk because a manipulated request can be converted into a real action through tool calls, workflow triggers, or data movement. The material concern is not only unsafe content generation but unsafe side effects in systems that trust the agent’s output as if it were a user or operator decision.

Failure mechanism: An attacker or abusive user exploits prompt injection, instruction conflict, or tool-routing weakness to steer the agent into calling the wrong tool, disclosing sensitive context, or chaining multiple benign steps into an unauthorised outcome. The risk becomes worse when the agent has standing permissions, weak approval gates, or no policy check before execution.

Impact: Sensitive data can be exposed, unauthorised transactions can be initiated, business workflows can be altered, and trust in the application’s decisions can collapse. In environments with connected systems, the harm can extend beyond one prompt into broader compromise of process integrity.

Practitioner Guidance

What to verify: Security teams should verify that a blocked action remains blocked even when the model is given a plausible reason to proceed, because a control that only works for obvious abuse is not an agentic control.

Decision rule: If a tool can change state, move data, or trigger an external process, treat it as an execution control problem and require pre-action policy checks, not just better prompting or content moderation.

What practitioners underestimate: The most common gap is not a single dangerous tool, but the combination of ordinary tools that become unsafe when the agent can chain them. That means evaluation should include multi-step abuse paths, not only isolated requests.

Practitioner takeaway: The decisive question is whether the system can be made to do something it should not do, not whether it can be made to say something inappropriate.

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?