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 costs money depends on one.

What protects an order is that the money gate is mechanical. The part of Layout that drives a checkout cannot obtain a card without a claim our server minted for a confirmed order, and confirmation is checked server side against a stored total. A sentence on a web page cannot mint a claim, raise a spending limit, or satisfy a confirmation, no matter how convincingly it is phrased or who it claims to be from. See money controls.

Around that gate 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 the payment action is unavailable until the money conditions are met. 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 at the moment of ordering is what the user is shown, and the total they approve 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 user, 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 user 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.

Instructions we give a host model are about being useful and truthful: call the tool rather than promise to, relay our confirmation verbatim, 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.