Guardrails for AI Agents: Input, Output and Action Controls

Guardrails for AI Agents: Input, Output and Action Controls

Guardrails for AI agents are controls placed outside the model that check what goes in, what comes out and what the agent is allowed to do. Input guardrails filter and bound the context, output guardrails validate the response before it reaches the customer or a system, and action guardrails limit tools, permissions and volume. The greater the possible damage, the more the control should be deterministic code rather than an instruction written in the prompt.

Key takeaways

• A guardrail is a mechanism that keeps working when the model makes a mistake. An instruction in the prompt is a request, not a control.
• There are three families: input (what the agent receives), output (what it answers or writes) and action (what it can execute).
• Action guardrails matter most, because they cap the damage even when the others fail.
• Each guardrail has a right place to live: channel, orchestration, tool layer, destination system or a person.
• Start with a few rules tied to real risks in the workflow, log everything and adjust based on the failures you observe.

Why is instructing the model in the prompt not enough?

A language model follows instructions probabilistically. Telling it in the prompt never to offer a discount lowers the chance that it happens, but does not remove it. If the agent has access to a tool that applies discounts, there is a technical path to the error, and it can be opened by a model mistake or by a malicious user message.

That is why the practical distinction is between guidance and control. Guidance is what you write in the prompt, and it helps average behavior. A control is a check in code, a denied permission or a human approval, and it holds in the worst case.

Anthropic, in its writing on building effective agents, highlights extensive testing in sandboxed environments and appropriate guardrails as part of the design. The OWASP Top 10 for LLM applications covers risks such as prompt injection and excessive agency, which are exactly the problems that input and action guardrails try to contain.

Input guardrails: what can the agent receive?

Input is everything that reaches the model, and that goes beyond the customer's message. It includes the text of an attached PDF, the result of a knowledge base search, the content of an email and the response from another tool. Any of these can carry instructions that the model treats as orders.

The most useful input controls in companies tend to be:

• Sender identification: knowing whether the WhatsApp number belongs to a registered customer before allowing any lookup of personal data.
• Limits on size, file type and message frequency, to prevent abuse and unexpected cost.
• Separation of instruction and data: external content enters marked as material to be analyzed, never as a command.
• Routing by intent: out-of-scope topics (legal, serious complaints, health) go straight to a person.
• Data minimization: whatever is not needed for the task stays out of the context, which also helps with LGPD compliance.

OWASP's guidance on preventing prompt injection relies on layered defense, precisely because no input filter is complete. Treating the filter as the first barrier, not the only one, is the right posture. If your workflow runs on WhatsApp, it is also worth reading LGPD Compliance for AI on WhatsApp: Legal Basis, Consent, Records, which covers what can enter the context and what should be recorded.

Output guardrails: how do you validate what the agent produces?

Output is anything the agent generates: the reply to a customer, a field filled in a system, a summary sent to the team. The design question is the same in every case: what must be true before this goes out?

Validation works best in layers, from the cheapest and most predictable to the most flexible:

• Format: the output follows the expected schema (required fields, types, allowed values). If it does not, it is rejected in code.
• Existence: the order number, product or time slot cited really exists in the system. This prevents answers that are plausible but invented.
• Policy: the reply does not promise a deadline, discount, diagnosis or condition that the company has not authorized. Term lists and simple rules cover a good part of this.
• Sensitive data: the reply does not repeat a document number, address or data belonging to another person.
• Second-model review: for what rules do not cover, such as tone and fit with the context. This reviewer also makes mistakes, so it should not be the only barrier for anything critical.

The most neglected point is what to do when validation fails. Reasonable options are to retry a limited number of times, respond with a standard message or hand off to a person. Retrying indefinitely consumes resources and can end up delivering a worse output.

Action guardrails: how do you limit what the agent executes?

When the agent stops merely talking and starts calling tools, the nature of the risk changes. A bad reply can be corrected, but an issued refund, a sent email or a deleted record may not be reversible. Action guardrails exist so that a model error has a ceiling on its impact.

The principles come from application security in general. OWASP's authorization cheat sheet advocates deny by default and granting the least privilege necessary. Applied to agents, this translates into concrete practices:

• Minimal tools: the agent only sees the tools the workflow requires, and each one does a single thing.
• Read before write: start with lookups and only then allow writes, with clear limits.
• Scoped credentials: the agent uses a restricted service account, never administrative access.
• Parameter validation in the tool: maximum value, allowed destination list, statuses that can be changed.
• Volume ceilings: number of actions per hour or per conversation, to contain loops and abuse.
• Idempotency: repeating the same call does not duplicate the effect, which protects against repeated attempts.
• Human approval for irreversible or high-value actions, as described in AI Agent Approval Policy: Practical Template.
• Kill switch: a simple way to turn off the agent or a specific tool without touching the rest.

In coding agents, part of these controls can be enforced by automatic rules before and after each action. The article on Claude Code Hooks Examples: Enforce Rules Before and After Actions shows this mechanism applied to development teams.

Where does each guardrail get implemented?

The most common confusion is thinking a guardrail is a single box placed around the model. In practice, each control lives in a different layer, and the choice of layer determines whether it can be bypassed. This guide helps you decide:

• Channel or gateway (WhatsApp webhook, inbound API): sender authentication, rate limiting, attachment size and type. If the control does not depend on interpreting text, put it here.
• Orchestration (the code that drives the agent): intent routing, output schema validation, maximum number of retries, per-conversation ceilings. This is home to most output guardrails.
• Prompt and context: delimiting external content, the agent's role and tone. Treat it as support, not as a security barrier.
• Tool layer (internal API, MCP server, functions): permissions, parameter validation, idempotency, allowed destination list. This is home to action guardrails.
• Destination system (ERP, CRM, database): the account the agent uses only has the permissions the workflow requires. If everything above fails, this is the last limit.
• People: approval of sensitive actions and handling of exceptions. The handoff flow should be defined, as in WhatsApp AI Agent Human Handoff: A Production Playbook.
• Observability: logging of inputs, decisions, tool calls and blocks, with alerts for unusual patterns. Without it, there is no way to know whether the guardrails work.

A rule of thumb: if the control must hold even when the model is fooled, it should sit in a layer the model cannot change.

Illustrative scenario: an orders and returns agent on WhatsApp

Imagine a store that uses a WhatsApp agent to look up orders and open return requests. This is an illustrative scenario, unrelated to any real case.

At input, the gateway only accepts messages from numbers that match a customer with an order and limits message frequency per conversation. Image attachments go through a type check, and the extracted text is treated as data, not as instruction. A message asking the agent to ignore the store's rules remains just a message, because the rules live in the code and the permissions.

At output, the reply must follow a schema that carries the number of the order being looked up. The code checks that this order belongs to that customer before sending. If the text mentions a refund, a delivery deadline outside the rules or an amount, the reply is blocked and the conversation goes to a human agent.

At action, the agent has one tool to look up an order and another to open a return request. There is no refund tool. Opening a return only accepts orders within the policy window, and repeating the call does not create a second request. Every call is logged with its source conversation.

The result is an agent that is useful for the common flow and, by construction, unable to do what the store has not authorized. For domain details, see the content on AI Customer Service for Ecommerce: Orders, Returns, Tracking, which covers the type of flow used in this example.

How to start: a step-by-step plan

A guardrail program does not need to start big. This sequence works for the first workflow:

• Step one: describe the current workflow and what the agent will do, including the data it touches and the actions it can execute.
• Step two: list the worst plausible outcome of each action (wrong amount, message to the wrong person, exposed data) and rank by severity.
• Step three: for each risk, choose the guardrail in the lowest possible layer, prioritizing action controls and validations in code.
• Step four: define what happens when a guardrail blocks: limited retry, standard message or handoff to a person.
• Step five: start with read-only access and drafts, and release writes gradually, with human approval on irreversible actions.
• Step six: log inputs, outputs, blocks and actions with a conversation identifier, and review blocks and near-misses on a fixed routine.
• Step seven: build a set of test cases with normal, ambiguous and hostile messages, and run it on every change to the prompt, model or tools.
• Step eight: before the pilot, define the success criterion and who decides whether to expand, adjust or stop.

The method used in consulting work follows the same logic: map the process and the starting point, limit data and actions, pilot one real workflow with logs and an agreed metric, then hand over the operation and decide whether to expand, adjust or close. Guardrails come in mainly at the limiting stage and are verified during the pilot, from the logs.

The NIST AI Risk Management Framework is a useful reference for organizing this risk management more broadly, if the company needs a shared vocabulary across departments.

Frequently asked questions

Do guardrails make the AI agent slower or less useful? Validations in code cost little time, and those involving a second model add some latency, which should be assessed in the workflow. The gain in usefulness usually comes from a well-defined scope, since an agent that knows when to hand off makes fewer mistakes and creates less rework. Too many blocks, on the other hand, frustrate the user, so it is worth reviewing wrongful blocks in the logs.

Do I need an off-the-shelf guardrails tool, or can I implement them myself? Many controls are ordinary code: schema validation, permissions, limits and logs. Libraries and moderation services can help at specific points, such as content detection, but they do not replace the design of permissions and approvals for your process. Evaluate any tool by what it actually prevents and what it records.

Do guardrails eliminate the risk of prompt injection? No. They reduce the chance that the attack works and, above all, limit what the attack can cause. That is why action guardrails, such as least privilege and human approval, are the most important part of the defense.

How do I know whether my guardrails are working? Through logs and tests. Track how many replies and actions were blocked, by which rule and whether the block was correct, and run hostile test cases on every change to the agent. If nothing is blocked during the pilot, be suspicious: either the workflow is very simple or the controls are not being exercised.

Sources

• OWASP: LLM Prompt Injection Prevention Cheat Sheet
• OWASP Top 10 for LLM Applications
• OWASP: Authorization Cheat Sheet
• Anthropic: Building effective agents