What is an input filter for an AI agent?

A check that runs before the model and tools process data — it rejects oversized payloads, flags prompt-injection attempts, and bounds what the agent may act on. It shrinks the attack surface before execution.

What does an output filter do?

It runs on the reply and tool results: redacts PII (emails, phone numbers, keys, customer IDs), caps payload size, and blocks outbound leaks. It reduces likelihood and blast radius but is not a cryptographic guarantee.

Allowlist or blocklist — which is better?

Allowlist (default-deny). Email only to approved domains, HTTP only to approved hosts, writes gated behind approval. A blocklist is weaker because an attacker uses a host you forgot to list.

Do filters guarantee no data leak?

No. Filters reduce the chance and size of a leak; a determined or obfuscated exfiltration can slip past a naive filter. They are one layer of defense-in-depth, paired with tool ratings and approval gates.

Why is logging part of filtering?

Because without a record of what was filtered and what was allowed, you cannot demonstrate oversight or traceability (EU AI Act Art. 12/14). Logs turn a filter from a silent control into evidence.

Input/output filter best practices for AI agents

Input filters

Input filters run before the model and the tools see the data. They:

Reject oversized payloads that blow up cost or context.
Flag suspected prompt-injection in tool results and user text ("ignore previous instructions…").
Normalize and bound what an agent may act on.

Input filtering is cheap insurance: it shrinks the attack surface before anything executes.

Output filters

Output filters run on the agent's final reply and on tool results returned to the user. The highest-value rule is PII redaction — strip emails, phone numbers, API keys, and customer identifiers before text leaves the boundary. A second rule is size capping so a single reply cannot dump an entire table.

Filters are not perfect. A determined leak can obfuscate data past a naive regex. Treat redaction as reducing likelihood and blast radius, not as a cryptographic guarantee.

Allowlist / blocklist

The most effective outbound control is an allowlist:

Email may only go to @yourco.com (or an approved list).
http_request may only hit pre-approved hosts.
delete / write tools are gated behind human approval, not the open internet.

A blocklist ("never call this host") is weaker — attackers just use a host you forgot. Default-deny with an allowlist is the safer posture for any agent that can move data.

Where teams trip up

Forgetting the tool path. Teams filter the chat reply but not the send_email tool argument — and the leak happens through the tool, not the window.
A weak allowlist. "Allowlist internal domains" that includes a wildcard is no allowlist at all.
No logging. If you cannot show what was filtered, you cannot prove oversight (EU AI Act Art. 12/14).

Filters are defense-in-depth. Pair them with tool-call ratings and approval gates so a single missed filter is not the whole story.

Authoritative references

EU AI Act, accuracy & robustness (Art. 15): https://eur-lex.europa.eu/eli/reg/2024/1689/oj
OWASP LLM Top 10 — excessive agency / data leakage: https://owasp.org/www-project-top-10-for-large-language-model-applications/
European Commission AI policy: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai