Why there should be no LLM in the authorization path

An authorization decision has one job: given the same request and the same state, answer the same thing. A language model cannot promise that. This is not a philosophical complaint about deterministic AI systems. It is the ordinary engineering reason you would not let a model decide whether a transfer leaves your account, and it is the reason the biggest companies in this category keep shipping the model away from the decision.

Google built its own checkout to keep the model out of the last step

In January 2026 Google launched the Universal Commerce Protocol at the National Retail Federation keynote, with Shopify, Etsy, Wayfair, Target and Walmart involved in building it. On stage, Sundar Pichai said it was available starting that day. The interesting part is not the launch. It is one sentence in the developer documentation, describing what happens when the user reaches payment.

Manual checkout: The user now interacts only with the Google UI to fill in sensitive fulfillment and payment details and submit the order. The Agent is not involved in this part, ensuring determinism.

A company with every commercial incentive to let the agent finish the purchase wrote, in its own documentation, that it takes the agent out of the flow to ensure determinism. The page adds that initially Google renders the interface for the buyer, with more agentic experiences planned later, and the merchant help page says the feature uses the card numbers users already stored in Google Wallet.

That is the trade written down in public: autonomy stops where determinism starts, and the human is the mechanism that guarantees it. It works. It is also, at scale, a confirmation button with better typography. The product question my company exists to answer is what has to exist for the agent to be allowed to finish, and the answer cannot be a model's opinion of your intent.

The spec says it in one line

Google's Agent Payments Protocol, published in September 2025 and donated to the FIDO Alliance in April 2026, defines what it calls mandates: tamper proof, cryptographically signed digital contracts that serve as verifiable proof of a user's instructions. The core concepts documentation states the design principle in six words.

Verifiable Intent, Not Inferred Action: Trust in payments is anchored to deterministic, non-repudiable proof of intent from the user, directly addressing the risk of agent error or hallucination.

Inferred action is what a model does. It reads a context and produces a plausible completion. Proof of intent is what a signature does. It binds a specific instruction to a specific principal, and it can be checked by a third party who was not present. When a protocol designed by a company that sells models writes directly addressing the risk of agent error or hallucination into its spec, the industry has already agreed with the premise of this article. The disagreement is only about where the line falls.

Where I put the line

• The model interprets. It reads the request, argues with itself, picks a merchant, builds a cart. This is where a model is genuinely better than a rule and where it should be allowed to be wrong.
• The engine decides. It takes the action the model proposes, evaluates it against the boundary that was written before the run, and returns allow, deny, or escalate. Same input, same state, same answer.
• The ledger records. Every decision leaves a row that a person who was not there can read later.

Note what this does not do. It does not make the agent smart. It does not remove human judgement from the boundary. It removes human judgement from the millisecond, which is where it was never going to be anyway, and puts it in the document, which is where it can be argued about properly.

How you know it is deterministic

You do not know it because the architecture diagram says so. You know it because you tried to break it. Here is the test I actually run, and I have written this loosely enough that it should be reproducible by anyone who owns an engine: hold the state still, send one hundred identical authorization requests for the same intent in parallel, and read the ledger afterwards.

100 requests, same intent, same key
  expected: 1 allow, 99 identical replays, 1 ledger row, 1 charge
  observed: 1 allow, 99 replays with the identical decision id

restart the engine, replay 20 decisions from the ledger
  expected: byte-identical decisions, same policy version
  observed: identical

Two things make that pass. The decision is a pure function of the request plus the policy version plus the ledger state, so restarting the process changes nothing. And idempotency is keyed on the intent, not on the HTTP request, because an agent retries aggressively by nature. Two identical requests are one intention. One intention is one charge.

That test is in the suite, which is why I am comfortable calling the engine deterministic rather than robust. Verified by test is a phrase I only use about things that run in the pipeline on every commit. Everything else is a design note, and design notes get the label they deserve.

The uncomfortable part of this position

If the engine is deterministic and the boundary was wrong, the failure is legible. That is the point, and it is also the cost. A system that can prove what it was asked to do can also prove that it was asked badly. Autonomy sold as magic disappears; what remains is a clear line between the part that runs and the part that thinks, and a receipt that says which one produced the outcome.

I would rather ship the legible version. The alternative is the one the industry is currently testing: let the model decide, describe the result as intent, and settle the argument later with whatever log happens to exist.

I am building this authorization path into Noesia, and the argument started in the money layer for AI agents. The pieces closest to this one are how the authorization layer works and deterministic authorization for AI agents. If you have a system where the model makes the final call, I would rather hear how you handle the retry than be told the model is reliable. The retry half of the same problem is idempotent payments for AI agents.