# Which guardrails does an AI agent need before it goes to production? > A checklist of input, tool, output and operations guardrails to clear before real customers talk to your agent, with a pointer to the deeper guide for each - Author: Ash Gaikwad (https://ashgaikwad.com) - Published: 2025-06-29 - Topics: ai agent, guardrails, checklist, production - Canonical: https://ashgaikwad.com/blogs/ai-agent-guardrails-checklist Before an AI agent goes to production it needs four groups of guardrails and a tested way to stop it. Input guardrails check what goes into the model. Tool guardrails limit what the agent can do. Output guardrails check what comes out. Operations guardrails (logs, spending caps, a kill switch) keep the whole thing visible and stoppable. A line in the system prompt is not on this list, because a prompt is a request and a guardrail is code that the model cannot talk its way past. I am Ash, and I have spent a decade shipping software, lately helping teams put AI agents in front of real users. This checklist is for the person who has an agent working in a demo and wants to know what to clear before customers use it. Each section ends with a link to a deeper guide, so you can read the short version now and the code later. ![Four groups of guardrails sit side by side. Input guards treat content as data, hide personal data, limit size and rate and keep the agent in scope. Tool guards give least privilege, check every argument, sandbox the network and ask a human for risky actions. Output guards fix the format, ground claims and stop leaks. Operations add logs, caps, a kill switch and an owner. All four lead to one launch gate.](/images/blogs/ai-agent-launch-checklist.svg) ## What counts as a guardrail A guardrail is a check that runs at runtime, inside one request, and can pass, change or block what the agent does. It is different from an evaluation, which looks at many conversations after the fact. You need both, and the evaluation is how you prove the guardrails work (more on that in the launch plan below). The [OWASP Top 10 for LLM applications](https://genai.owasp.org/llm-top-10/) is a good map of what can go wrong. Prompt injection, sensitive information disclosure, improper output handling, excessive agency and unbounded consumption are all on it, and every item in this checklist answers one of them. The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) adds the people side. It asks you to govern, map, measure and manage risk, and it has a [generative AI profile](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence) (NIST AI 600-1) for exactly this kind of system. ## Input guardrails Input guardrails run before the model sees anything. The goal is to stop bad or useless input early, because it is cheaper and safer than fixing the damage later. - Treat every webpage, email, document and tool result as untrusted data, and never let it change the agent's permissions or approve an action. - Remove or mask personal data and secrets before they reach the model, the logs or any long-term memory. - Set limits on message length and on how often one user can call the agent. - Check that the request is something this agent is meant to do, and send everything else to a polite refusal. The first item is the one people miss. A customer message is not the only input. If your agent reads a support ticket, a web page or a PDF, an attacker can hide instructions in it. OWASP calls this [prompt injection](https://genai.owasp.org/llm-top-10/), and it is the top risk on their list. A classifier can help, but the stronger fix is structural. Content the agent reads should never carry the power to authorise anything. ## Tool guardrails Tools are where an agent stops being a chatbot and starts changing things, so this is the section where I would spend the most time. A model can say anything it wants. It can only do what your tools allow. - Give the agent its own identity with narrow, short-lived credentials, and only the tools the task needs. - Check the user and tenant permission on every call, not once at the start of the conversation. - Validate each argument against a schema and your business rules before the tool runs, and reject calls that fail. - Require human approval for payments, deletions, deployments and anything sent outside your company, and show the person the exact action that is about to happen. - Run code in a sandbox with limited file access, and allow outbound network calls only to destinations you list. - Keep secrets out of anything the model can read. Not every tool needs the same control, so sort them by what a mistake costs. A tool that only reads can run after the permission and argument checks. A write you can undo can run too, if it keeps a backup and an audit line. Anything that sends something outside, spends money or changes access needs a person to approve it first. Anything that deletes data needs a person and a recovery plan. The model can propose an action at any of these levels, but a separate piece of code decides whether it runs, which is what the [OWASP cheat sheet on AI agent security](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html) recommends. Check that the guardrail covers every path. The [OpenAI Agents SDK documentation](https://openai.github.io/openai-agents-python/guardrails/) notes that input guardrails run only for the first agent in a chain and output guardrails only for the last one, while tool guardrails run on each guarded tool call. In a setup with several agents, the checks on your tools are the ones that run on every call, as long as every tool that matters has one. The Claude Platform guide to [securing a deployment](https://platform.claude.com/docs/en/managed-agents/secure-deployment) lists the settings that limit what an agent can reach and do, most important first, and it is a useful second opinion even if you do not use that platform. For the full pattern, read [How do I give an AI agent tools it can call safely?](/blogs/how-to-give-ai-agents-tools-safely) and [What does a custom guardrail for an AI agent look like in code?](/blogs/how-to-write-custom-guardrails-for-ai-agents-with-code). If your agent writes code, [How to set up guardrails for AI coding agents](/blogs/how-to-set-up-guardrails-for-ai-coding-agents) adds protected branches, reviewed pull requests and release credentials that the agent cannot touch. ## Output guardrails Output guardrails run after the model answers and before the customer or the next system sees it. They matter because a wrong answer in a friendly voice still reaches a real person. - Check the format. If another system reads the answer, validate it against a schema and never pass raw model text into a database query, a shell or a web page. - Check claims and numbers against the sources the agent used, and fall back to a person where an error would cost money or trust. - Scan for leaked data such as other customers' details, internal error messages, connection strings and your system prompt. - Check the tone and the promises. An agent should not offer discounts, legal advice or refunds that your policy does not allow. I like to keep these checks as plain code where I can, such as a schema check or a pattern match, and use a second model only for judgement calls like tone. Code checks are free, fast and predictable. A model checking a model adds cost and a new way to be wrong. ## Operations guardrails Operations guardrails are what let you sleep. Everything above can pass your tests and the agent can still loop, overspend or misbehave on a Friday night, so you need to see it and stop it. - Log every tool call, approval, outcome and blocked action, with sensitive data masked, so you can replay what happened. - Cap spend, run time, tool calls, retries and hand-offs for one task, and add timeouts so a loop ends by itself. - Fail closed. If a permission check or a guardrail is down, the agent should stop and hand over to a person, not carry on. - Make write actions safe to repeat, so a retry or a duplicate request cannot charge a customer twice, and keep a way to undo the change where you can. - After a write, check what happened before the agent says it worked, and handle a timeout as "unknown" until you have looked, so one slow call does not become a duplicate. - Version the prompt, the model, the tools and the permissions together, so you know which combination produced a bad answer and can roll back to the last good one. - Add a kill switch that someone on the team can use without a new deployment to turn off one tool or the whole agent. - Name one owner who gets the alerts and decides what the agent may do next. The caps are also where the economics live. Every extra tool call and retry is paid model time, so a limit protects your margin as well as your users. OWASP lists this risk as [unbounded consumption](https://genai.owasp.org/llm-top-10/). ## Do smaller or cheaper models need the same guardrails? Yes, and in my experience a smaller model needs the checks more often, not less. A smaller model tends to miss instructions and invent arguments more often, so more of its mistakes reach your guardrails. But a larger model does not remove the need. The guardrails protect against failure of the whole system (a poisoned web page, a bug in a tool, a confused user), and a stronger model fixes only one of those. Pick the model for quality and cost, then build the same guardrails around it either way. ## A one-week launch plan You do not need a quarter for this. A small team can reach a reasonable first launch in a week, and you can add depth after real traffic shows what matters. 1. On day one, write down what the agent may do, what it must never do and when it hands over to a person. Name the owner. 2. On day two, list every tool, remove the ones the task does not need and give the rest narrow credentials. 3. On day three, add argument checks and human approval to every tool that changes something. 4. On day four, add the input and output checks, starting with personal data, leaked secrets and the response format. 5. On day five, add logs, spending and step caps, the kill switch and the fail-closed behaviour. 6. On day six, test it. Use realistic tasks, prompt injection attempts, a request for another customer's data, a failing tool and a duplicate request. Our guide on [how to test that guardrails work](/blogs/how-to-test-guardrails-for-ai-agents) shows how to keep this as a small set you can rerun. 7. On day seven, launch to a small group, or run the agent in shadow mode first (it drafts actions that a person carries out, so you can compare). Watch the logs, keep a tested way to roll back and widen access only when the numbers look good. Keep score with a few plain numbers. How often the task is completed, how often a person had to step in, what a finished task costs and how many actions ran that should not have. The last one should be zero, and a test suite that finds none is a good sign, not proof. A single serious security failure is reason enough to hold the launch, even when everything else passes. Rerun the day-six tests whenever the model, the prompt, the tools or the permissions change. A guardrail that passed last month says little about this month's agent. For a full worked example in Rails, [How to build guardrails for AI Agents](/blogs/how-to-build-guardrails-for-ai-agents) builds all three layers around a support agent. ## Frequently asked questions ### What is the minimum set of guardrails for an AI agent? The minimum is least-privilege tools, argument checks before every tool call, human approval for risky actions, spending and step caps, logging and a kill switch. Input and output checks come right after, and they matter more as the agent talks to more people. ### Is a system prompt enough as a guardrail? No. A system prompt is an instruction the model usually follows, and a clever message or an unlucky response can break it. Put the rule in code that runs on every request, and keep the prompt as a helpful hint. ### Which guardrail should I build first? Start with the tools. Limit what the agent can do and require approval for anything hard to undo, because that caps the worst thing that can happen. After that, add logging so you can see what the agent does. ### How do I know my guardrails work? Try to break them. Run a fixed set of attack prompts, bad tool results and duplicate requests before launch and after every change, and watch real traffic through your logs once you are live. ### Which actions should need human approval? Sort actions by what a mistake costs. Reading and reversible changes can run on their own with checks and a log. Sending something outside the company, spending money, changing access and deleting data should wait for a person who can see the exact action. If you are unsure about a tool, start with approval and relax it once the logs show it behaves. ### Do I need guardrails for an internal agent? Yes, though you can set the limits differently. Internal agents still read untrusted content, hold real credentials and can delete real data, and staff are often the ones who find the mistakes in production. Pick one item from the checklist and finish it today. Your future self (the one holding the pager) will thank you.