The agent bought a chair

Imagine giving an AI assistant a fairly boring job:

Get me a monitor for my home office. Keep it under €800.

It buys a gaming chair. €749, free delivery, excellent reviews.

Apparently, an ergonomic chair would improve your setup more than a second screen. The assistant has thought this through. It has a whole paragraph explaining why, with "load-bearing" (sic!) arguments and a bullet list.

You still need a monitor.

Now look at the purchasing API's side of the story. Valid credentials. Permission to create orders. An available product, a correct price, your actual shipping address.

Everything it checked passed.

I think this is a useful place to start talking about agent authorization. A system can correctly check permissions and still permit an action which has very little to do with what the person asked for.

Who chose the chair?

In an ordinary shopping app, you pick an item and click Buy. The app submits your choice. If a chair arrives, you can usually trace the problem to the selection or the ordering code.

With an assistant, you can hand over more of that choice. It searches, compares products, reads descriptions and works out what to do next. Somewhere in that process, "buy a monitor" became "improve this person's home office."

That small reinterpretation changed what got purchased.

The developer still controls plenty: available tools, business rules, approval steps. But some of the decisions which produce the API call now come from the model interpreting the request and whatever it finds along the way.

This is the distinction I care about when somebody says an agent is "just software."

Yes. Software with more freedom to work out what you meant and act on that interpretation. I would like to know how much freedom, exactly.

Of course, ordinary software makes decisions too. Trading systems, schedulers and purchasing workflows have done that for years. And putting a language model into an application does not automatically give it a free hand. It might only extract a product name before handing control back to a fixed workflow.

Anthropic makes a similar distinction when it separates predefined workflows from agents which let the model direct tool use. For authorization, the interesting part is which choices the system actually hands over.

Can it change the item? Try another supplier? Decide the job needs an email? Keep going when the first attempt fails?

Those are practical questions. "Is it an agent?" gets me considerably less far.

The token was fine

Suppose the assistant's access token carries a permission called orders:create.

That tells the API something useful: the caller may create orders. Depending on the system, other rules might check the employee, the supplier, the amount or whether a manager approved it.

Our imaginary API checked enough to accept the chair. It had no enforced restriction which tied this purchase to a monitor.

The instruction was sitting in the conversation. The API was checking the credentials and the order. The assistant was trusted to connect the two correctly.

There is nothing inherently wrong with trusting software to do its job. Every application relies on that to some extent. What bothers me is treating a successful permission check as evidence that the assistant followed the request. It tells us only that the action passed the rules which were actually checked.

An order limit would have stopped an €819 monitor. It would happily allow our €749 chair. Both the amount and the kind of purchase matter here.

A very convincing purchase request

It is tempting to fix this by asking the assistant to explain its reasoning before it acts.

But the chair already came with an explanation. That was part of the problem. It found a plausible reason to widen the job.

An explanation can help a person review a proposal. I still want the decision to rest on what was authorized. If I agree to the chair after seeing the proposal, fine. The assistant has obtained a different instruction. Until then, "this would be better for you" is a recommendation waiting for an answer.

Existing authorization machinery can help with quite a lot of this. Business rules can restrict product categories. An approval can be tied to a specific order. OAuth even has Rich Authorization Requests for requesting structured authorization details. A short scope name is not the limit of what a system can express.

The awkward work is deciding which parts of the request to turn into enforceable limits, then making sure those limits reach the place that can stop the purchase.

"Under €800" is fairly concrete once delivery and taxes are agreed. "A suitable monitor" needs more judgment. I don't think another signed token makes that distinction disappear.

For this job, I would want the assistant to choose among suitable monitors and come back if it thinks the job should change. That gives it useful room to work without letting a helpful suggestion quietly become a purchase.

My first question when reviewing an agent integration would be simple: which part of the system would have stopped the chair?

If the answer is "we told the model to buy a monitor," then following that instruction is still the boundary we are relying on.