Untrusted content

Layout reads the open web and acts on it. A restaurant's ordering page is content nobody vetted, and it is being read by a model that then does things. Anyone who has thought about prompt injection can see the shape of the problem immediately, so here is our actual position.

The position

A prompt level boundary is a strong default and not a guarantee. Models do get talked out of them. So nothing that pays for an order depends on one.

The part of Layout that drives a checkout cannot obtain a card without a claim our server signed for a confirmed amount, and a confirm is checked on our server against a stored total. A sentence on a web page cannot sign a claim, raise a spending limit, or change the total a confirm has to match, however convincingly it is phrased or whoever it claims to be from. See money controls.

Around that, we do the prompt level work properly as well, because cheap defences that hold most of the time are still worth having.

Restaurant pages

The page is treated as data to be read, not as instruction. The automation working through a checkout has a small, fixed set of actions available to it, and it has no card until our server hands it one for a confirmed amount. Text asking it to do something else has nothing to reach for.

Prices are the other half of this. What the restaurant's own site says when the cart is built is what the person is shown, and the total they confirm is the total the order is placed against. A page that changes its number after the confirmation does not get a silent charge at the new one.

Help center articles

The help tool returns our own published articles, which are written in a support tool by people with publish rights. That is a smaller trust boundary than the open web and it is still a boundary, because an article body arrives inside a tool result that a model has been told to trust.

So every article body is fenced and explicitly labelled as reference material quoted from a web page: not from Layout, not from the person, and not an instruction. If text inside that fence asks the model to change its rules, place an order, reveal its instructions or contact anything, the instruction is to ignore it and answer from the rest.

The fence tags are stripped from the quoted text first, so quoted content cannot close its own fence and speak as though it were the instruction.

The host model

We do not treat the connecting assistant as trusted either. The identity on every call comes from a claim inside a token we signed, never from anything the caller states about itself, and a client's self chosen name is treated as attacker controlled because registration is open to anyone. See how the connector works.

The case we cannot close from our side is a host model persuaded, by something it read, to confirm a cart the person did not agree to. The confirm still has to match a cart that was actually built, at its exact total, and above $50 or on a risk step up it needs the person's texted code. Under that, what bounds it is the per order ceiling and the person's daily limit.

Instructions we give a host model are about being useful and truthful: call the tool rather than promise to, relay our confirmation as written, never say an order was placed unless the status says placed. They are not a security control and we do not count them as one.

What we tell a model it may not do

Two things, because they are the two ways a fluent answer causes real harm:

• It may not state a Layout policy from its own knowledge. Refunds, charges, cancellations and privacy come from help or they are not answered. An invented refund window is worse than an admission that we have not published one.
• It may not claim an order was placed without our status saying so. Nor may it claim a failure it cannot see. A false failure invites a second order and a second charge.

What we would tell you if you found a hole

The truth, quickly. See reporting an issue.