They break at the point where output becomes action. Ordinary LLM controls focus on unsafe text, but agentic systems can turn manipulated intent into tool use, delegated execution, and cross-agent spread. If governance stays at the prompt layer, the system can still execute the wrong objective under valid authority.
Where ordinary LLM controls stop short
agentic systems are not just text generators with better prompts. Once a model can call tools, hand work to sub-agents, or continue a task after the user leaves the page, the control problem shifts from output quality to delegated execution. The key break is that a manipulated instruction can still be “valid” enough to trigger real action.
That changes what must be governed. A safe-looking response can still launch a file write, an API call, a ticket update, a trade, or a workflow transition. Controls that only inspect the final text miss the more important question: what authority did the system already have, and what could that authority do if the objective was hijacked?
Agentic security therefore needs to treat autonomy as part of the attack surface, not as a presentation layer. That includes tool permissioning, action scoping, human approval boundaries, and containment for multi-step plans that can amplify a single bad instruction into downstream execution.
Why prompt-layer governance fails in practice
Prompt-only governance assumes the model is the boundary. In an agentic workflow, the boundary is the combination of prompt, state, tool access, and policy decisions. If those layers are separated, an attacker can steer the objective while still staying inside apparently legitimate execution paths.
This is why agentic failures often look less like “bad wording” and more like abuse of delegated authority. The system may accept a malicious goal, select the wrong tool, reuse context from a prior task, or propagate that objective across a chain of agents. The failure is structural: the wrong intent is executed under correct credentials.
Practitioners should think in terms of blast radius. The question is not only whether the model can be tricked, but whether the resulting action is reversible, attributable, and contained. If the answer is no, then ordinary LLM safety controls are too shallow for the system you actually built.
What has to change in the control model
Agentic systems need controls that sit at the decision point between reasoning and action. The most important shift is from “is this output allowed?” to “is this action allowed, by this actor, in this context, with this scope?” That usually means per-action authorization, task-scoped permissions, approval gates for sensitive steps, and explicit isolation between agents, memory, and tool credentials.
It also means treating orchestration as a governed function. If one agent can spawn another, inherit context, or pass tokens onward, the architecture must define where delegation starts and stops. Multi-agent designs need clear ownership of identities, tighter handoff rules, and logs that preserve attribution when one component causes another to act.
For a practical security baseline, the Agentic AI Security Guide is useful because it frames the problem across inputs, memory, tools, orchestration and identity rather than at the prompt alone. For execution control specifically, the AI Agent Authorisation Guide is the right pattern to follow when authority must be scoped per task or per action.
Risk and Threat Considerations
When agentic systems are treated like ordinary LLMs, the main risk is that manipulated intent is converted into real-world side effects before anyone notices. The danger grows sharply when the system can call tools, reuse credentials, or fan out work to other agents, because a single compromise can become execution, persistence, or cross-agent propagation.
Failure mechanism: The attacker does not need to produce obviously malicious text. They only need to steer the agent’s objective, exploit loose delegation, or trigger an unsafe tool path while staying inside permitted authority.
Impact: You get wrong actions under valid credentials, wider blast radius across workflows or agents, and a control gap where text moderation no longer protects the system from operational misuse.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agentic systems fail when prompts drive real actions under valid authority. |
| ASI02 — Tool Misuse | The question centers on unsafe tool execution, not unsafe text alone. | |
| ASI07 — Insecure Inter-Agent Communication | Cross-agent spread is a core failure mode when autonomy is chained. | |
| Recommendation — Enforce per-action authorization and least privilege for agent tool use. Restrict tool access and validate each tool invocation against policy. Authenticate and constrain inter-agent handoffs and message trust. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Agentic systems need action-scoped privilege, not broad runtime authority. |
| AU-2 — Event Logging | Action attribution and post-incident review depend on agent activity logs. | |
| IA-9 — Identification and Authentication (Non-Organizational Users) | Tool and service interactions in agentic systems need strong machine-to-machine trust. | |
| Recommendation — Minimise each agent's permissions to the smallest workable scope. Log agent decisions, tool calls, handoffs and approvals for traceability. Require strong authentication for agent, tool and service interactions. | ||
| NIST Zero Trust (SP 800-207) | 0 — Zero Trust Architecture | Agentic execution needs continuous verification of identity, context and access. |
| Recommendation — Verify every agent action and trust decision before allowing execution. | ||
| CIS Controls v8 | 6 — Access Control Management | Agent tool access and delegated authority are access-control problems at runtime. |
| Recommendation — Review and limit agent access paths, especially privileged ones. | ||
Practitioner Guidance
What to verify: Confirm that every meaningful tool call, state change, or external action is authorised at the action layer, not inferred from prompt content. If a model can complete a business workflow without a separate policy decision, the control boundary is too weak.
What to prioritise: Start with the actions that can move money, alter records, expose data, or trigger other agents. Those are the points where ordinary LLM safety controls stop being sufficient and where delegation must become explicit, bounded, and reviewable.
Common mistake: Teams often harden the prompt, add content filters, and assume they have agent security. In practice, the high-value control is usually least-privilege action design, plus observability for when the agent’s goal changes or expands mid-task.
Practitioner takeaway: If the system can act, govern the action path first; prompt safety is only a supporting control once authority, delegation, and containment are already correct.
Related resources from NHI Mgmt Group
- What breaks when private keys are treated like ordinary application data in infrastructure systems?
- What breaks when agentic identities are treated like ordinary automation?
- What breaks when AI gateway controls are treated like ordinary API security?
- What breaks when remote access into CPS is treated like ordinary IT access?