Input filtering tries to stop bad text from entering the model, while runtime containment limits what the agent can do after text has already been accepted. In practice, containment is stronger because it addresses the privileged action itself, which is where indirect prompt injection causes damage.
Why Input Filtering and Runtime Containment Solve Different Agent Problems
Input filtering is a gate on what the model is allowed to ingest, so it is aimed at hostile or malformed instructions before they influence the agent’s reasoning. Runtime containment is a gate on what the agent is allowed to do after it has already accepted input, so it limits tool use, data reach, and side effects even when the prompt layer fails. For AI agents, that difference matters because the dangerous event is usually not the text itself, but the privileged action the text can trigger.
That is why teams treating prompt screening as a complete defence often miss the real blast radius. A filtered prompt can still be followed by a harmful action if the agent has broad tool access, weak approval thresholds, or no separation between reading instructions and executing them. The OWASP Agentic Applications Top 10 frames this as an agent control problem, not just a text-safety problem. In practice, many security teams discover the gap only after an agent has already acted on a trusted instruction path rather than during prompt review.
How It Works in Practice
Input filtering and runtime containment should be designed as layered controls, but they answer different questions. Input filtering asks whether the content entering the agent is likely to be malicious, off-policy, or structurally unsafe. It can inspect user prompts, retrieved documents, tool outputs, and embedded instructions, then block or rewrite suspicious content before the model processes it. That helps reduce obvious injection attempts, but it cannot guarantee safety because benign-looking text can still carry hidden intent, and some harmful requests only become dangerous once combined with agent capability.
Runtime containment assumes the model may still accept bad instruction. It constrains what the agent can do with that instruction by limiting tool scope, credential reach, network access, data visibility, and irreversible actions. In an agentic system, containment is usually implemented through short-lived credentials, narrow workload identity, scoped tool permissions, policy checks at execution time, and explicit approval for high-impact actions. The practical objective is to keep the agent useful while preventing a single prompt from becoming a broad operational event.
- Filter input to reduce obvious injection, prompt smuggling, and untrusted retrieved text.
- Contain runtime actions so the agent cannot exceed its task, data scope, or approval boundary.
- Separate read access from write access so an agent that can observe data cannot automatically change it.
- Make policy decisions at execution time when context, destination, and side effect are known.
The strongest pattern is to treat filtering as an early warning layer and containment as the safety boundary. The OWASP NHI Top 10 is useful here because agent containment depends on the same identity and privilege discipline used for non-human access. These controls tend to break down when the agent is allowed long-lived tokens, broad default permissions, or direct write access to production systems because then a single accepted instruction can still become an uncontrolled action.
Common Variations and Edge Cases
Tighter runtime containment often increases operational friction, so organisations must balance safety against automation speed and user experience. That tradeoff becomes most visible in agents that need to act across multiple systems, handle exceptions, or complete tasks without human pause.
Best practice is evolving for edge cases such as retrieval-augmented agents, multi-agent pipelines, and systems that mix advisory and execution roles. Input filtering is still valuable for untrusted documents and external web content, but it is weaker when the injected instruction is subtle, distributed across multiple sources, or only harmful after a later tool call. Runtime containment is stronger in those cases, but it can be overly restrictive if policy is too coarse or if the agent needs temporary elevation for legitimate work. The practical question is not whether one control is better in the abstract, but whether the agent can still be bounded when the input layer fails.
Where current guidance is clearest, filtering should be used to reduce exposure and containment should be used to cap damage. AI Agents: The New Attack Surface report is a relevant reality check because it shows that agent misuse is already occurring in live deployments, which means design assumptions should be tested against behaviour, not intent alone. This model breaks down when organisations expect prompt hygiene to substitute for execution controls, especially in agents that can read sensitive data and trigger irreversible actions in the same session.
Risk and Threat Considerations
The main risk is confusing input safety with action safety. Prompt filtering can reduce noisy injection attempts, but it does not stop a successfully influenced agent from over-collecting data, calling the wrong tool, or executing a destructive action with legitimate credentials. Indirect prompt injection is especially dangerous because the attacker does not need to win the model’s “trust” in a human sense; it only needs to shape the agent’s next permitted move.
Failure mechanism: A malicious instruction enters through chat, retrieval, file content, or another trusted channel, then the agent uses its existing permissions to access data or perform a side effect that the prompt layer alone cannot prevent. If runtime policy is missing or too broad, the model’s accepted text becomes an execution path rather than a screened message.
Impact: Sensitive data exposure, unauthorised tool actions, corrupted records, credential misuse, and loss of auditability can follow even when the original prompt was partially filtered. In multi-step agents, the damage can also cascade because one unsafe action becomes the context for the next one.
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 CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 — Prompt Injection | Directly addresses hostile input that can influence agent behaviour and tool use. |
| Recommendation — Harden against prompt injection and validate untrusted inputs before they reach agent logic. | ||
| CSA MAESTRO | A1 — Agent Identity and Access Control | Agent containment depends on bounded identity, privilege, and execution authority. |
| Recommendation — Scope agent permissions tightly and restrict execution rights to the minimum task context. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Containment often relies on short-lived credentials and limited secret exposure for agents. |
| Recommendation — Use ephemeral credentials and rotate or revoke tokens that exceed the agent’s task window. | ||
| NIST AI RMF | GOVERN — Govern | This distinction is an AI governance decision about acceptable risk and oversight. |
| Recommendation — Define policy for agent actions, approvals, and escalation before deploying autonomous workflows. | ||
| CIS Controls v8 | 6 — Access Control Management | Runtime containment depends on limiting who and what can access sensitive systems. |
| Recommendation — Restrict agent access paths and remove permissions that are not required for the task. | ||
Practitioner Guidance
What to prioritise: Treat runtime containment as the primary control for agent safety and use input filtering as a supporting layer. If an agent can make a consequential change, the approval boundary should sit on the action, not only on the text.
What to verify: Confirm that every privileged tool call is evaluated against live policy, current context, and least-privilege scope. If the agent can still write, delete, transfer, or disclose data after a filtered prompt, the containment boundary is too weak.
Decision rule: If the failure mode would be harmful even when the input is “clean” but the task context is manipulated, prioritise containment first. If the main issue is obviously malicious content that should never be processed, keep filtering, but do not assume it will prevent downstream abuse.
Practitioner takeaway: The most useful mental model is that input filtering reduces exposure while runtime containment limits blast radius; mature agent security needs both, but only containment stops an accepted prompt from becoming an unsafe act.
Related resources from NHI Mgmt Group
- What is the difference between prompt filtering and identity governance for AI agents?
- What is the difference between least privilege and session containment for AI agents?
- What is the difference between least privilege and runtime governance for AI agents?
- What is the difference between content filtering and intent security for AI agents?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
