AI Agent Guardrails: Let the Agent Propose, Let the Door Decide

The agent finishes its draft. It calls the publish endpoint. The door opens its checklist and the agent waits outside. That is the whole pattern.

The short answer

An AI agent guardrail is a deterministic checker that sits between the agent and the action it wants to take. The agent proposes. The checker decides. The checker does not read the brief, does not care how good the work is, and cannot be talked out of a refusal. A rule in the agent's instructions is a guideline. A rule in the checker's code is a guardrail. The difference is that code does not forget and cannot be convinced.

The pattern: a locked door the agent cannot open from the inside

I run an autonomous content pipeline for my platform. An agent writes articles. A second agent drafts daily journal entries. Both call a publish endpoint when they are done. Both hit a door that has no idea who called it and no interest in the reason.

The door runs a fixed set of checks. The checks run in the same order every time. The order is not alphabetical or random. It is deliberate: cheaper, faster, and more decisive checks go first. A piece blocked by the first check never reaches the sixth.

Why the checks are in code and not in the prompt

A prompt rule and a code rule look the same on day one. By day thirty they are not the same thing.

The agent that calls my resource door has no idea what the checks are. It gets back a result. It does not get a list of rules it could study and work around. That is the design. A door that explains itself is not a door.

One check that no revision can clear

Most holds are fixable. An agent revises the piece and tries again. One hold is not.

The door carries a career-promise classifier. It looks for reader-aimed outcome promises: sentences that tell the reader they will reach a director title, clear a salary figure, or land a promotion within a fixed timeline. If it finds one, the piece is held with the reason "career-claims" and that reason is permanent. The code says revisedOnce is irrelevant.

Here is the part people miss: the career classifier runs on every category, not just pieces labeled "career". If an agent tries to label the piece "marketing" to dodge the rule, the rule still fires. The code closes the category-relabel bypass on purpose.

I built this because the cost of a false negative is a published earnings claim. The cost of a false positive is a held piece that waits for a human. I will take the false positive every time.

What the door writes when it refuses

A refusal is not silence. The door writes a row to the database with enough detail for a human to review it.

The journal door uses a different failure mode, and the reason matters

My platform publishes two kinds of content: resources and daily journal entries. Each has its own door. The resource door can hold a piece for human review. The journal door cannot.

The journal door protects anonymity. It runs a linkability gate over the entry text before it writes anything to the database. If the gate finds a violation, the door returns a 422 and nothing is stored. There is no held state for scrub violations. The comment in the code is direct about why: a held leak is still a leak sitting in the DB.

The linkability gate is also not fooled by creative spelling. It scans three variants of every text: the original, a percent-decoded version, and an accent-folded version. A founder who writes their name with accented characters still gets caught, because the accent-folded form collapses onto the deny token it is imitating.

The other design decision I find interesting: the journal door resolves which lane a request comes from before it does anything else. Two lanes exist. The automated lane and the human-tap lane. The code checks for the automated token first. If the automated and human tokens were ever accidentally set to the same value during a rotation, checking automated first means that mistake costs a hold. Checking human first would mean the scheduled run gets the human lane's authority with no one watching. The comment in the source is blunt: the ordering is load-bearing and it was wrong once.

What fail closed means in practice when you design these

Fail closed sounds obvious until you have to pick the failure mode for each specific check. The two doors I built make different choices and both are right for their surface.

• The resource door fails to hold. A piece that triggers any check stays in the database as a held row. A human can read it, override it, or let it expire. The cost of a false positive is a delayed article.
• The journal door fails to reject. A scrub violation returns a 422 and writes nothing. The cost of a false positive is a lost journal entry. That is acceptable because a leak in the database is not.
• The cadence check in the resource door fails to hold when the database read fails. A null window holds rather than lets a database blip silently disable the rate cap.
• The image gate in the linkability checker fails to reject on unknown image formats. Only formats the code can actually inspect are allowed. An unknown format is treated as a violation, not a pass.

The design choice you make about what fail closed means is the most load-bearing decision in the whole system. Get it wrong and you have a guardrail that looks like it works until the day it matters.

Key takeaways

• An agent guardrail is a deterministic checker between the agent and its action. The checker does not trust the agent that called it.
• Rules in code enforce themselves. Rules in prompts rely on the model, which can drift, reason around them, or forget.
• The check order is a design decision. Cheaper and more decisive checks go first. A piece that fails early never reaches the later checks.
• One hold reason can be permanent. The career-promise classifier fires on every category to close the relabel bypass, and a hit cannot be cleared by revision.
• Fail closed means picking a specific failure mode for each check, not just agreeing the system should be cautious.

Frequently asked questions