Security overview
Layout lets an AI assistant place a real, paid order at a restaurant on a person's behalf. That is a system with somebody's money and somebody's address inside it, reached through a model that a stranger can type into. This section is how that is held together, written for the people whose job is to check.
What the system does
A person asks their assistant for food. The assistant calls Layout. Layout works out which restaurant and which location, reads that restaurant's live menu, builds the order on the restaurant's own ordering site in a cloud browser, and stops at a priced cart. The person is shown the total and confirms it. Only then does Layout complete the restaurant's checkout, paying with a Layout virtual card rather than the person's own.
No merchant integration is involved, and no merchant account of the user's is either. There is no delivery, and Layout does not sign in to loyalty accounts.
The boundaries
There are three, and they are worth naming separately because they fail differently.
- The assistant is untrusted input. A host model can be talked into anything by the person typing at it, or by text on a web page it read. So no model, ours or a host's, is load bearing for authorization, spend, or identity. Everything that matters is checked on our servers against a signed token and a stored record.
- The restaurant's website is untrusted content. We read it and act on it, so the money gate has to survive a site that lies about a price, and our own agent is stopped mechanically rather than asked politely to behave.
- Our own blindness is not the customer's problem. A check that cannot run has no opinion. It does not silently pass and it does not veto an order on the basis of something it could not read.
The rules the code is built to
These are enforced in code, not documented as intentions.
- Nothing is spent without a confirmation from the user, on a total we calculated and showed them, and the gate is mechanical. There is no wording that waives it. See money controls.
- No order is claimed as placed without evidence, and no failure is claimed without evidence either. A confident false failure invites a duplicate order, so uncertainty is stated as uncertainty.
- Card numbers never reach a log, a model, a trace, or our database. They live in a PCI vault belonging to our payment provider. See card data.
- A user reads only their own rows. Isolation is enforced in the database itself rather than by every query remembering to filter.
- Observability never delays or alters an order. Telemetry is fire and forget.
Where to go next
The short brief: what the connector asks for, what it can do, and who to contact.
How the connector worksThe OAuth flow, the token, the scope, and revocation.
Money controlsThe confirmation gate, the daily limit, and the card a merchant charges.
Data we storeWhat is kept, what is not, and who it is shared with.
Updated September 2, 2026
