What are runtime guardrails for an AI agent?

What are the four runtime guardrail stages?

The stage determines what a rule can inspect and therefore what it can enforce. A policy cannot evaluate information that is not available at its position in the agent process. A control placed before tool execution can prevent a call based on its name or arguments, but it cannot evaluate the content of a result that has not yet been returned.

pre_input: inspect the arriving message

The pre_input stage runs when a message arrives. It can inspect the message itself and its length. This makes it the appropriate location for rules concerned with an oversized or scored message.

A rule at this stage can warn about a message or block it before the rest of the agent process handles it. It cannot determine what a later tool will return, because no tool result is available at this point. It also cannot substitute for a control that checks the arguments of a tool call.

This stage is also where a prompt-injection classifier sits when it scores the message before the model reads it. The classifier can annotate the message or stop the turn from reaching any tool.

pre_tool: enforce conditions before execution

The pre_tool stage sees the tool being called and every argument. It is the point at which a policy can stop a call before it happens, or hold it for a person.

This distinction matters when the risk is contained in the requested operation or in one of its arguments. For example, a rule can deny a call when an argument does not meet an enforceable condition. The agent is told about the verdict and continues without the denied call.

A pre-tool gate cannot inspect what the tool would have returned. That information only exists after execution. Rules concerned with the size of returned data therefore belong at post_tool, not pre_tool.

post_tool: inspect the returned result

The post_tool stage sees the tool name and the size of what came back. It can warn when a result is far larger than expected.

This stage is useful for identifying an unexpected response size after a tool has executed. It does not provide the same control as a pre-tool denial, because the call has already taken place. It is therefore important to distinguish a warning about the returned result from a decision to prevent the call.

A prompt-injection classifier should not be moved to this stage merely because tool output may contain hostile content. By the time the tool result is evaluated there, the content is already in the context window.

pre_output: inspect the final reply

The pre_output stage runs before the reply reaches the user. It can inspect the reply and block a runaway or oversized response.

This is the final point in the four-stage sequence. It does not provide visibility into the original tool arguments that led to the reply, nor does it replace a pre-tool control. Its purpose is to enforce conditions on what the agent is about to send.

The four stages should therefore be selected according to the object being controlled: the arriving message, the pending call, the returned result or the outgoing reply.

Which verdict should a runtime guardrail use?

A verdict defines what happens when a rule matches. The available choices represent different levels of intervention, from recording a pattern to preventing a call or waiting for a named person.

deny

deny prevents the call from happening. The agent receives the verdict and continues without that tool call. This is the direct enforcement option when the rule expresses a condition that can be evaluated from the information available at the relevant stage.

A denial should be tied to a concrete, enforceable property. Tool identity, arguments and length are examples of the structures a policy engine can compare. A rule should not claim to assess meaning that the policy engine cannot read.

require_approval

require_approval holds the call until a named person approves it. It is the right verdict for anything irreversible.

This verdict preserves a decision point without allowing the agent to complete the call automatically. It is particularly useful where the operation itself is clear, but a person must decide whether it should proceed.

warn

warn allows the action to proceed and flags the event. It is the appropriate starting point for a rule that is not yet trusted enough to block traffic.

Warnings let a team observe how a policy behaves before changing its effect. They are also appropriate when the condition is useful as a signal but does not justify preventing the call.

log

log allows the action to proceed and records it. Its purpose is to measure a pattern before deciding what to do about it.

Logging is therefore different from warning. A warning flags the event, while logging records it for measurement. Neither verdict prevents the call.

Why do rules beat wording?

A system prompt saying “only look up orders belonging to the signed-in customer” is a request. A rule saying checkOrderStatus is denied when the order id is not the session’s is a fact about the process.

The distinction is not the wording used to express the instruction. It is where the control is enforced. A system prompt is part of the conversation that the model interprets. A runtime gate evaluates a condition around the running agent and produces a verdict.

This difference appears under prompt injection. An attacker can make the model want the call, but the gate is not in that conversation. The model may be persuaded to select a tool or construct arguments that conflict with the policy. A pre-tool rule can still inspect the tool and every argument before execution.

Express the control as an observable condition

The practical question is whether the requirement can be represented using information available at the selected stage. A condition based on a tool name, an argument or a length is structurally inspectable. A condition that depends on whether the agent’s answer is supported by a knowledge base is not described in the same terms.

This approach also clarifies where a control belongs. A session-related condition concerning an order identifier belongs around the tool call because the tool and its arguments are visible there. A condition concerning an oversized message belongs at pre_input. A condition concerning the size of a result belongs at post_tool.

Keep the gate outside the model’s persuasion loop

The value of a runtime rule is that the model does not get to negotiate with it through the conversation. The rule either permits the action, flags it, records it, holds it or denies it according to its verdict.

That does not mean every requirement should become a blocking rule. It means that requirements suitable for deterministic enforcement should not be left only as wording in the system prompt.

What can a policy engine not enforce?

A policy engine compares structure: a tool name, an argument or a length. It does not read meaning. This boundary is essential when deciding whether a proposed rule should be implemented as a gate.

“Only answer questions the knowledge base can support” is not expressible as a rule of this kind. Writing it as one produces a rule that blocks legitimate traffic while catching nothing. The requirement concerns meaning and support, rather than a directly inspectable tool name, argument or length.

Claims of that shape belong to detection and evaluation, not to the gate. Detection can identify a condition that is not represented as a simple structural comparison. Evaluation can determine how the agent behaves with the attacks that have been tested. A deterministic runtime rule has a narrower purpose: enforcing a condition it can actually evaluate.

Decide whether the condition is enforceable

Before creating a blocking rule, ask what the rule will inspect. If the answer is a tool name, an argument or a length, the requirement may be suitable for a policy. If the answer depends on meaning, support or interpretation, it does not fit the described policy engine.

This is not a reason to discard the requirement. It is a reason to place it in the right control category. A condition that cannot be enforced deterministically should not be presented as though it can be.

Downgrade uncertain rules

When a condition is not yet trusted, warn is the stated starting point. The rule proceeds and is flagged, allowing the team to observe the pattern before deciding what to do about it.

log serves a related purpose when the immediate goal is measurement. The event proceeds and is recorded. Once the pattern is understood, the team can decide whether the appropriate response is to retain logging, add a warning, require approval or deny the call.

Where should prompt-injection detection run?

A prompt-injection classifier is its own gate at the input boundary, not a policy. It scores the message before the model reads it and either annotates it or stops the turn from reaching any tool.

This placement is different from a structural runtime rule. The classifier is concerned with the message and its score at the input boundary. The policy engine compares observable structure at the relevant runtime stage. They should not be treated as interchangeable controls.

Scoring tool results with the classifier instead is a common mistake. By then, the content is already in the context window. The input boundary is the point at which the classifier can stop the turn before it reaches any tool.

Separate input detection from tool authorisation

The classifier and the pre-tool rule address different questions. The classifier scores the arriving message. The pre-tool rule inspects the tool call and every argument. A message may pass the input boundary while still producing a tool call that should be denied or held for approval.

Keeping these functions separate also prevents a tool-result check from being mistaken for an input control. A post-tool inspection can warn on a result far larger than expected, but it does not undo the fact that the returned content has already entered the context window.

Use the stage that has the required evidence

A control is only useful when it runs where the relevant evidence exists. Input scoring requires the message before the model reads it. Tool authorisation requires the selected tool and its arguments before execution. Result-size monitoring requires the returned result. Output control requires the reply before the user sees it.

This is the central design constraint across the four stages. The stage is not an implementation detail; it defines what the rule can say.

How should teams introduce runtime guardrails?

The most useful first rule is require_approval on the most irreversible tool the agent has: a refund, a send or a delete. The stated reason is that its value does not depend on predicting the attack.

This is a practical starting point because it focuses on the consequence of the tool operation rather than on predicting every way an attacker might influence the model. The call is held until a named person approves it.

From there, teams can classify additional requirements by stage and verdict:

• Use pre_input for a message condition, including an oversized or scored message.
• Use pre_tool for a condition involving the tool or any argument.
• Use post_tool for a condition involving the tool result’s size.
• Use pre_output for a condition involving the reply before delivery.
• Use deny when the enforceable condition must prevent the call.
• Use require_approval when a named person must approve the call.
• Use warn when the rule is not yet trusted enough to block.
• Use log when the immediate purpose is measuring a pattern.

Testing remains part of this process. Testing tells you what the agent does with the attacks you have. Guardrails constrain what it can do with the ones you do not. Most rules worth having are written from something a test found.

A new rule takes effect within one keepalive of the running agent. Nothing restarts and no traffic leaves the process. This makes rule changes a runtime policy concern rather than a restart-dependent change.

Key takeaways

• Runtime guardrails are deterministic rules evaluated inside the running agent.
• The four stages are pre_input, pre_tool, post_tool and pre_output.
• A stage can only inspect information available at that point in the process.
• deny prevents a call, while require_approval holds it for a named person.
• warn and log allow the call to proceed while flagging or recording the event.
• Meaning-based requirements belong to detection and evaluation, not to a structural policy gate.

Common questions

Are guardrails the same as a firewall in front of the model?

No. A proxy in front of the model sees requests and responses. A runtime guardrail runs inside the agent process and sees the tool call and its arguments — which is where the damage is, and which a proxy cannot see at all.

Do guardrails replace testing before release?

No. Testing tells you what the agent does with the attacks you have. Guardrails constrain what it can do with the ones you do not. Most rules worth having are written from something a test found.

How fast does a new rule take effect?

Within one keepalive of the running agent. Nothing restarts and no traffic leaves the process.

What is the most useful first rule?

require_approval on the most irreversible tool the agent has — a refund, a send, a delete. It is the one rule whose value does not depend on predicting the attack.

Can a pre-tool rule inspect a tool result?

No. A pre_tool rule can inspect the tool being called and every argument. The result only exists after the call, so a rule concerned with what came back belongs at post_tool.

Should every requirement become a blocking rule?

No. A policy engine compares structure such as a tool name, an argument or a length; it does not read meaning. Requirements that cannot be enforced deterministically belong to detection and evaluation. An uncertain enforceable rule can start as warn rather than deny.