Should organisations use prompt filtering or action-boundary controls for agent security?

Why prompt filtering and action boundaries solve different agent risks

Prompt filtering is best understood as an input hygiene control. It can remove obvious injection attempts, reduce noise, and block low-effort coercion before the model spends time on them. But once an agent has permission to act, the more important question is not what it read, it is what it is allowed to do after reading it. That is where action boundaries earn their keep.

For an agentic system, the security decision is shaped by both the content it sees and the authority it can exercise. A filtered prompt can still produce a harmful plan if the agent can write data, send messages, invoke tools, or trigger workflows. The boundary around those actions determines whether a bad instruction becomes a business event.

This is why the answer is not either-or. Prompt filtering helps at the perimeter of interpretation, while action-boundary controls govern execution. When those controls are layered, the system becomes more resilient to both opportunistic attacks and successful prompt-level coercion.

Where action-boundary controls matter more than input filtering

Action boundaries become the primary control whenever the system can cross a trust boundary: issuing API calls, changing records, sending payments, modifying code, or reaching sensitive systems. In those cases, even a well-filtered prompt can still steer the agent toward an unsafe outcome if the runtime lacks hard limits on tools, scopes, approvals, or destination systems.

The practical test is simple. If an untrusted input can influence an action with external effect, the control must sit at the action layer, not only at the prompt layer. That means explicit authorization for each sensitive step, narrow task scope, and a clear distinction between read-only reasoning and write-capable execution.

Prompt filtering still has value here, but mainly as a first-pass friction reducer. It can shrink the volume of bad requests and reduce accidental exposure, yet it cannot substitute for per-action policy enforcement. Organisations that rely on filtering alone usually discover that the agent was not “bypassed”, it was simply permitted to do too much.

How practitioners should choose the control stack

Use prompt filtering for low-cost reduction of obvious abuse, then design the action boundary as if the prompt will eventually fail. That means treating tool invocation, data writes, privileged queries, and side effects as separately governed events. The stronger the downstream action, the stronger the boundary needs to be.

For agent security, the most useful design pattern is to make sensitive actions explicit, reviewable, and narrowly scoped. A good boundary can require approval for high-impact actions, force task-scoped credentials, and prevent the agent from freely chaining from discovery to execution. The goal is not to ban autonomy, but to keep autonomy bounded by policy.

Teams that are building the control set should also align it with identity and privilege. If the agent has standing access, action boundaries become harder to enforce because the system already assumes trust. If access is time-bound, task-bound, and revocable, the boundary can actually stop coercion instead of merely observing it.

Risk and Threat Considerations

Prompt filtering fails when the attacker’s real objective is to influence an authorised workflow rather than to inject a visibly malicious string. The risk is highest where the agent can reach sensitive tools or systems, because the boundary between “understanding” and “doing” becomes the real attack surface.

Failure mechanism: The attacker coaxes the agent into taking an approved but unsafe path, such as over-broad retrieval, unintended data disclosure, or a privileged tool call that was not intended for the current task.

Impact: The result can be unauthorised action, data exposure, workflow manipulation, or a broader compromise if the agent’s execution authority extends into high-value systems.

Practitioner Guidance

What to prioritise: Put the strictest controls around any action that can write, send, delete, spend, or change system state. Those are the steps where prompt filtering is weakest and where boundary failures become operational incidents.

What to verify: Confirm that sensitive actions are gated by policy at execution time, not just screened at input time. If the agent can reach production systems, verify that scopes, approvals, and revocation are actually enforced when the action is attempted.

Common mistake: Treating prompt filtering as the main defence because it is easier to deploy. That approach can reduce noise, but it does not reliably stop an agent from carrying out a harmful instruction once the instruction has been accepted.

Practitioner takeaway: Filter prompts to reduce attack volume, but secure the action boundary to control damage. In agent systems, execution authority is the control that determines whether a bad instruction becomes a real incident.

Related resources from NHI Mgmt Group

• Why do AI agent security risks require immediate attention?
• How should security teams govern AI agents that use OAuth access?
• How should security teams use AI in secret scanning without creating new blind spots?
• When should organisations use AI to help manage NHIs?