The Takeout Model

So far in this series I have laid out the problem; AI tools need access to exactly what we want protected, and the layer that should manage that access does not exist yet for agents. In this essay I want to describe what that layer looks like, and the good part is you need zero technical background for it.

It’s a takeout restaurant.

Your agent is the diner. It’s hungry, it walks up to the counter, orders off the menu, pays. The cashier punches it in, the kitchen cooks the meal and bags it, the bag is placed in the serving window, the diner takes it home.

Now look at what the diner could not do. It never entered the kitchen, never saw the pantry, never touched an ingredient, never talked to the chef. It didn’t cook a dish, it picked off a menu and walked out with nothing except its own order.

That is the whole architecture, in a nutshell.

The diner is the agent. It has a reason to want something done, it can read the menu, place orders, receive the bag, and it holds no keys, no credentials to anything behind the counter. All its power runs through ordering off a defined menu. Today’s agent has the kitchen keys, it walks behind the counter, goes through the walk-in and the pantry, does what it wants. Customers do not get to do that in restaurants, and agents should not get to do it with data.

The menu is the capability catalog, a finite declared list of what can be ordered. Every item has a name, declared inputs and outputs, declared side effects, declared scope. Read documents in the supplier contracts folder the acting user has access to. Draft a reply to an email the acting user has open. Initiate a payment up to a set threshold with hardware key confirmation. If it is not on the menu it cannot be ordered, the diner cannot invent dishes. And the menu belongs to the operator, the IT admin, the compliance officer, not the agent’s developer and not the model provider. The operator decides what is available to which diners, and swaps items in and out as the threats change.

The cashier is the policy enforcer. Every order gets checked, is it on the menu, is this diner allowed to order it, does the pattern look fraudulent, is it over the limits. If any check fails the order never reaches the kitchen. And here is an important detail, the cashier never tastes the food. Policy gets enforced on the order without opening the bag, so the enforcement layer physically cannot leak the data it governs. The cashier can also refuse, an order that smells wrong even though it is technically valid gets held while someone calls the manager.

The kitchen is the system of record, the documents, the emails, the customer records, the financial systems. The kitchen has stations and each station has its own specialist and nobody has the run of the whole kitchen. Nobody outside sees in. Health inspectors check that the kitchen meets standards without watching every meal get made.

The chef and the serving window are the ephemeral sandbox. An order comes in, a chef spins up, pulls only the ingredients on the ticket, cooks, hands the bag through the window and stops existing. The next order gets a new chef and a clean station, nothing carries over, the chef cannot pocket ingredients and cannot cook anything the ticket didn’t say. The hardware for this exists today, ephemeral microVMs, attested execution environments, sandboxes that destroy themselves between tasks. The hard part is not the chef, it is arranging everything else so the chef is the only path from order to meal.

The receipt is the audit trail. Every order produces one, it names the diner, the cashier, the chef, the station, the time, the order, what came out, the payment. Receipts are hash chained so each one locks the next, you cannot quietly edit an old receipt without visibly breaking the chain. One copy goes to the diner, one goes to the back office where an inspector watches patterns across everything the restaurant served today. The cashier sees one order at a time, the inspector sees the whole day.

So that is six layers, diner, menu, cashier, kitchen, chef, receipt, and each one does a job you can explain to someone non technical.

A few things fall out of this. No layer trusts any other layer, the cashier doesn’t trust the diner, the kitchen doesn’t trust the cashier, the chef checks the ticket, the log trusts nobody, so to do real damage you have to compromise several independent layers at the same time and that is exponentially harder than compromising one. Each layer only sees what its job needs, the cashier enforces policy without seeing the meal, the chef sees ingredients but not the diner, the diner sees the meal and never the kitchen, so privacy here is not a policy someone bolted on, it is just the shape of the thing. And the operator owns the configuration, the menu, the policies, the escalation rules. The same architecture runs in a bank with tight policies or in a startup with loose ones, the architecture does not pick the policy, it enforces whatever the operator writes.

And everything is provable. Receipts prove what happened, hardware attestation proves the chef was real, external audits verify the kitchen. When the regulator asks how do you know your agents are safe, the answer is not our vendor says so, the answer is a receipt chain and an attestation report.

That last one is the one that matters most for adoption, and I say this from experience. Banks and insurers and hospitals and government agencies cannot deploy agents at scale until they can produce receipts for what their agents did, receipts an auditor can independently verify. Right now the technology does not pass the institutional smell test, and the takeout model is what passing it looks like.

But an architecture is only as good as the people who can actually use it. If only senior platform engineers can configure agent policies, it fails exactly where it is needed most.

In the next essay I will introduce you to Tanaka.