AI agent guardrails: defining what your AI must never do

Friday, 4:40 p.m. A support lead at a mid-sized SaaS company opens the transcript log of an agent that has been running quietly for three weeks. An illustrative pattern: of nine conversations that started with a pricing question, the agent offered "we can arrange a discount for you" in six of them. Nobody gave the agent authority to discount anything. Nobody told it that it lacked that authority either. The prompt said "be helpful, don't lose the customer," and the agent followed that instruction to the letter.

This piece is about making that sentence impossible in the first place. We start with why writing prohibitions into a prompt does not hold, then separate guardrails from rules and workflows. From there we cover where the list of prohibitions actually comes from, which actions belong behind an approval gate versus a hard block, and why the data an agent can read is half the boundary. The last sections deal with what should happen the moment a limit is hit, how you prove a limit actually holds, which records confirm it, and who owns the list over time.

Why doesn't writing prohibitions into the prompt hold?

A prompt is a statement of intent, not a mechanism. When you write "never commit to a price," that sentence competes with hundreds of other instructions in the same pool. As the conversation grows, as the customer pushes back, as the context window fills, the weight of that sentence drops. What the model sees is not a prohibition but a preference — and when preferences conflict, the one stated most recently and most forcefully tends to win. The moment a buyer says "that's outside my budget," the most helpful available move is exactly the one you forbade.

The second problem is scope. An agent no longer produces just text; it creates records, updates fields, sends messages, changes ad budgets. In this way of working, where software decides and then acts, the cost of a mistake is not an awkward sentence but an irreversible transaction. You can correct wording. You cannot un-send a quote.

This is why guardrails live in a separate layer. In Rocketly, the Guardrails screen lets you declare what an agent must never do, and those limits are enforced at runtime rather than negotiated inside the model's reasoning. The distinction matters: a prompt tries to make the agent not want to cross a line; a guardrail makes it unable to.

What separates a guardrail from a rule or a workflow?

Three concepts get conflated constantly. A workflow says "when this happens, do that" — ordered, conditional, predictable. A rule engine reads a field value and fires an outcome. A guardrail fires nothing at all; it simply closes a door. A workflow describes the road, a guardrail puts a railing along the cliff. The railing earns its keep precisely in the situations you did not anticipate.

The practical test is one question: does this statement describe a path or a boundary? "When a new lead arrives, research it, summarise it, log a note" is a path — and Step-by-Step Playbook lets you define that action sequence instead of leaving the ordering to the model. "Never commit to a delivery date" is a boundary that holds regardless of which path was taken. Writing both in the same place weakens both.

Getting this distinction right is also a precondition for positioning the agent as a co-pilot working alongside the team. A co-pilot is defined as much by the controls it cannot touch as by the ones it can.

Where does the list of prohibitions actually come from?

Sitting down with a blank page and asking "what shouldn't the agent do" is the least productive method available; the same four or five items always come to mind. The list is built from four concrete sources.

• The permissions matrix. Whatever a human on the team cannot do without approval, the agent cannot do either. If a rep cannot authorise a discount alone, that line copies across verbatim.
• Past incidents. The list of wrong things that reached customers in the last six months is the most honest source of prohibitions you will find. Each one converts into a guardrail line.
• Contract language. Response times you committed to, work you excluded from scope, confidentiality clauses. These become binding the moment an agent repeats them.
• Regulatory and data limits. Constraints on personal data processing, marketing consent, and retention periods.

The most common drafting error is writing prohibitions in the abstract. "Do not give misleading information" is unmeasurable. "Do not state a figure that is not on the published price list" is measurable. The same discipline runs through how intelligent features are configured inside a CRM: however capable the model is, the more concrete the boundary, the more work it does.

Which actions belong behind a hard block, and which behind approval?

Not every limit needs the same severity. Two axes are enough: is the action reversible, and does the customer see it? Reversible, internal actions can run automatically. Irreversible, externally visible actions either wait for approval or never happen. Rocketly's Approval Control lets you decide per action type whether it runs automatically or waits for your sign-off; guardrails hold the lines where the approval gate should not even open.

Action	Reversible?	Customer-visible?	Suggested limit
Logging a note or summary	Yes	No	Automatic
Updating lead score and tags	Yes	No	Automatic
Increasing an ad budget	Partly	No	Manual approval
Sending a quote to a customer	No	Yes	Manual approval
Committing to a discount or date	No	Yes	Hard block
Deleting a record or conversation	No	No	Hard block

The last column is not filled in once and forgotten. The "manual approval" rows in particular drift in two directions over time: towards automation as trust builds, and towards a hard block after an incident. Where response-time promises are involved, the limit is set not by the agent's capability but by the service level you defined in the contract; the agent cannot promise past that threshold.

Why is the data an agent can read half the boundary?

Prohibition lists are usually built around actions, but what an agent can say is bounded by what it can read. An agent without access to the price list cannot quote a wrong price. An agent with access to the internal margin sheet will eventually leak a number from it, no matter how many rules you write. Access limits therefore come before behavioural limits.

In Rocketly, Agent Knowledge Routing lets you pick, agent by agent, which knowledge sources are reachable — and you can switch knowledge base search off entirely. Inside one company the sales agent reads the price list while the support agent sees documentation only. That is the mirror image of connecting your own company data to an AI assistant: what you deliberately leave unconnected is as much a design decision as what you connect.

On the personal data side the boundary is sharper still. An agent being able to read a record does not mean it may summarise that record to a third party. When you are handling customer data with AI, deciding up front which fields the agent never sees costs far less than investigating a disclosure afterwards.

When a limit is hit, should the agent stop or hand over?

The moment a guardrail fires should never be a dead end for the person on the other side. A poorly designed limit says "I can't help with that" and ends the conversation; the customer asks the same question a third time and leaves. A well designed limit has three exits: the agent states what it cannot do, offers the nearest thing it can do, and hands the conversation to a person when needed.

Smart Human Handoff is exactly this mechanism — in complex or sensitive situations the conversation moves to the right rep with its full context intact. A handoff is not a failure; it is evidence the boundary worked. What you measure is not whether the handoff rate is zero, but whether handoffs happen for the right reasons.

The most dangerous form of violation is not the agent breaking a rule but the agent describing something it does not know as though it does. Recognising when a model is wrong is part of guardrail design: it is better for an agent never to make a claim it cannot source than to make one and retract it. The same logic applies across channels, and for an agent speaking on the phone the limits are drawn tighter still, because nothing said out loud can be edited afterwards.

How do you prove a limit actually holds?

Writing a guardrail is easy; demonstrating that it holds is not. Rule one of testing: probe the limit with the sentences designed to break it. Polite questions prove nothing. "Is there any flexibility on price, could you check with your manager, a competitor quoted us lower" — these are the pressure lines you will actually meet in production.

The Test and Preview panel lets you run the agent against real scenarios before it goes live, and it shows not only the replies but which actions the agent invoked. The way to confirm a limit is not to admire a polite sentence; it is to verify the forbidden action was never called at all. On the playbook side, side-effect-free dry-run mode does the same job at flow level: the steps execute, the results are visible, and no record changes.

The same discipline applies when you adjust routing. Multi-Agent Routing lets you measure a new rule in shadow mode first, and the explanation panel shows why a request landed with a given agent. When writing test cases, borrow from the practice of framing prompts precisely — a vague test sentence produces a vague result.

Which records confirm the boundaries are working?

A guardrail's value is invisible as long as nothing is violated, so measurement is indirect: you look at what the agent attempted, not only at what it completed. The Run Trail collects every agent run in a single stream, with each action's parameters, result, duration and approver on record. When a customer says "I was told X," you have a record rather than an argument.

Agent Insights aggregates the same logs into a picture: which actions run how often, where they stall, how much credit they burn. An action piling up permanently in the approval queue usually means the limit sits in the wrong place — either you blocked too broadly, or that job should not belong to an agent at all. On the AI Analytics side, the handoff breakdown and agent comparison let you pick the scenario to fix from data rather than intuition.

Cost is a boundary too. A per-agent credit cap sets a monthly ceiling for each agent, and a run that would exceed it is stopped before it starts. An agent stuck in a loop inflating the bill is a quieter fault than a wrong sentence, and usually a more expensive one.

Who owns this list, and how often is it revised?

An unowned guardrail list decays in one of two directions: nobody touches it and the agent becomes progressively useless, or everybody adds to it and it becomes unreadable. In a healthy setup one person owns the list — usually whoever owns the process the agent works in — and changes pass through them.

The review cadence can stay simple: read the handoff records and the approval queue monthly, then read the whole list line by line once a quarter. Each line gets one question: has this limit fired even once in the last three months? A limit that never fires is either unnecessary or badly written. A limit that fires constantly usually points at a content problem instead, which is the moment to revisit how the messages going out to customers are drafted.

Building an agent together with its boundaries is far easier than trying to brake one afterwards; if you want to draft your own prohibition list and watch it hold, you can open a free Rocketly account and try an agent in the test panel.

FAQ

Do guardrails make an agent less useful?

The opposite: narrow, explicit limits are what let you delegate more. Nobody puts an unbounded agent in front of real customers, whereas an agent whose boundaries are written down and observable can have its scope widened over time.

How is this different from writing the same rules into the prompt?

A sentence in a prompt is open to interpretation and loses weight as the conversation grows. A declared limit is enforced at runtime — even if the agent tries to invoke the action, the operation does not go through.

Does every prohibition need its own line?

No. Start at category level: commitments, personal data, irreversible operations, out-of-scope topics. Add granular lines only after a real incident; prohibitions invented without one tend never to fire.

How do I notice when an agent tries to cross a limit?

The run trail records every action's parameters, result and approver, and blocked attempts stay in that stream. Agent insights aggregate the same records to show which limits engage and how often.