Guardrails won't save you

The danger with commercial AI agents is not that they say something unsafe. It is that they do something unauthorized, politely, in a customer-facing message, before any human sees it. Guardrails check whether the words are toxic. Almost nothing checks whether the action was allowed. That gap is where the money leaks, and closing it is a different job than filtering content.

I build in this space, so treat that as disclosure and judge the argument on its own. The argument does not need my product to be true.

Start with the case everyone cites

A grieving passenger asked Air Canada's website chatbot about bereavement fares. The bot told him he could book at full price and claim the discount retroactively within 90 days. That policy did not exist. When he claimed the refund and was refused, he took the airline to a tribunal. Air Canada's defense was remarkable: it argued the chatbot was "a separate legal entity responsible for its own actions." The tribunal rejected that outright and ordered the airline to pay. The dollar figure was small. The signal was not: a company owns what its AI tells a customer.

That single case contains the whole argument. The failure was not a security failure. Nobody hacked the chatbot. It was not toxic, it did not leak data, it was not jailbroken in any technical sense. It was fluent, confident, and on-brand, and it made a commitment the business never approved. Every AI guardrail on the market would have let it through, because inventing a refund policy is not a content violation. It is an authority failure, and content filters do not look for those.

Why "AI safety" became the wrong frame

The guardrails industry was built for a real and different problem: models that say harmful, biased, or toxic things, or get tricked into leaking data or following an injected instruction. The tools that address that, content filters, injection detection, PII redaction, are genuinely good and genuinely necessary. None of this argues against them.

But commercial agents introduced a failure mode that safety vocabulary does not name. The agent does something perfectly courteous and perfectly on-brand that it had no authority to do. It offers a discount past its limit. It guarantees a delivery date nobody approved. It issues a refund the policy forbids. It states a term that is not the company's term. There is nothing unsafe about the text. The problem is the authority behind it, and we kept reaching for safety tools because safety was the vocabulary we had.

Three layers, and where the money leaks

It helps to separate three things that all get called "guardrails," because conflating them is why teams feel covered when they are not.

• Access. Can this agent call the refund tool at all? This is identity and permissions, the OAuth and scopes layer. It is well understood and largely solved.
• Safety. Is the output toxic, leaking data, or carrying a prompt injection? This is the guardrails layer. Also well understood, and improving fast.
• Authorization. Is this specific action, this discount, this promise, this refund, one the agent was actually allowed to take under the company's own commercial policy? Almost nobody has this.

The expensive failures all live in the third layer. In the Air Canada case, the agent had permission to answer the question, so access passed. The answer was not toxic, so safety passed. It was simply not authorized, and there was no layer checking for that. The same shape holds for every case below.

The pattern across the incidents

I keep a running tracker of these, and the pattern is consistent and not the one people expect. None of them were hacks. Air Canada's bot invented a policy. Cursor's support bot invented a device-lockout rule that never existed and triggered a wave of cancellations before anyone inside the company saw the thread. A UK retailer's chatbot was talked into 80% off an 8,000 GBP order over an hour of patient conversation, then the customer threatened legal action when the shop tried to cancel.

The common thread is the opposite of dramatic. No malware, no breach, no jailbreak in the security sense. Just fluent, confident, on-brand text that happened to cost money or create legal exposure. Every content guardrail in place passed each one, because granting a discount is not a content problem. It is a policy problem, and no policy check was standing between the agent and the send button.

And it is not a rare tail. A late-2025 Gravitee survey found 82% of US companies using AI agents had seen one behave in unexpected ways in the prior year. A March 2026 study, Before the Tool Call, citing an industry survey, reported that 27.2% of engineering teams had already given up on framework-provided authorization and hand-rolled their own checks at the tool-call boundary. Teams feel the gap. Most are just filling it by hand.

What authorization actually is

Authorization is not a smarter content filter. It is a check that reads the action the agent is about to take, compares it to a policy the business actually wrote, and returns a decision before the action ships. The policy describes commercial limits, not language: discount authority, forbidden commitments, approved claims, required disclaimers, spend caps, per-customer budgets. The check returns one of four outcomes:

• Allow. The action is within policy. Send it.
• Rewrite. A fixable violation. A compliant version comes back, already re-checked, ready to send instead.
• Require approval. The action exceeds someone's authority. It waits for a named human.
• Block. A hard violation. It does not ship, and the record says why.

The record matters as much as the decision. When a customer claims the agent promised something, "our prompt said not to" is not evidence. A signed decision record showing what was checked, against which policy, and what shipped, is. That is the difference between a description of good intentions and proof of a control.

This is the thing I build, and I would rather you evaluate the idea than the tool. The idea stands without me: if an agent can create commercial liability, something has to decide whether the action was authorized, and it has to decide before the action happens, not summarize it afterward.

What is still unsettled, honestly

This is a young category and a lot is genuinely open. The legal theory is still developing: the Air Canada ruling is an influential tribunal decision rather than settled law across jurisdictions, and the platform-liability suits now testing whether the vendors behind an agent share the exposure are undecided. The standards are early; the Cloud Security Alliance's AARM specification is one serious attempt to name this layer, and it is new. The tooling, mine included, is young.

But the direction is clear enough to act on. Agents are moving from drafting to doing. The moment an AI can spend money, make a promise, or state a policy on your behalf, "we told it not to" stops being a defense. Something has to check the action, not just the words.

Guardrails ask whether the AI is behaving. Authorization asks whether it is allowed. You need both, and right now almost everyone only has the first. If you want to see the second one work, the live demo runs a violating message against an editable policy and returns the decision in a couple of seconds, no signup.