What is the difference between input guardrails and output guardrails?

Input guardrails inspect what enters the model: jailbreak attempts, injected instructions, prohibited topics, and sensitive data being submitted. Output guardrails inspect what leaves it: leaked system prompts, personal data, ungrounded claims, unsafe content, and secrets. The distinction that matters operationally is that input guardrails protect the model, while output guardrails protect everything downstream of it, including the browser rendering the response.

Input controls typically include jailbreak and injection classifiers, topic denial, and redaction of personal data before it reaches the provider. They fail against attacks that arrive indirectly, through a retrieved document or a tool result, because that content enters the context without passing the input boundary.

Output controls typically include grounding or hallucination checks, personal data detection, toxicity filtering, and secret scanning. The one most often missing is output handling: treating model output as untrusted before it is rendered, executed, or passed to another system. OWASP tracks this as LLM05, Improper Output Handling, and it is how model output becomes cross-site scripting or command injection.

For agentic systems, there is a third category most stacks lack entirely: tool-call guardrails. Between the model deciding to act and the action executing, a policy check should evaluate whether this agent, in this session, may call this tool with these arguments. Input and output filtering do nothing here, because a malicious action can be requested in benign language and produce a benign response.

Akto Argus enforces at all three points, including the tool-call boundary, which is where autonomy converts a content risk into an action risk.

Filter both directions. Then authorize the action, because that is where agents actually cause damage.