A user clicks Send after an assistant says, “Send invoice to Alice,” because the UI makes that summary look like the thing that will happen.
The UI then executes a request whose real recipient is bob@vendor.com, and the user only learns that after the fact when the invoice lands in the wrong inbox.
Nothing in that failure requires the model to “hack” the product.
The failure happens at the interface boundary where generated text becomes something a human approves, and the UI lets the assistant’s fluent description stand in for the parameters that will actually execute.
The next example is a tiny assistant UI that shows the mismatch directly when we click the button.
Generate custom courses on any topic — with hands-on practice, AI guidance, and visuals built in.
Already have an account?
This code makes the problem concrete by separating what the UI says from what the action would send, and the click reveals the real payload the product would transmit.
The mismatch we just saw lands because a frontend assistant flow has multiple distinct stages, and each stage can produce a different kind of unsafe belief.
We can name four stages the frontend controls and tie each one to the same “send invoice” scenario so later fixes attach to the right point in the flow.
The value of separating these stages is that each one needs a different interface control, and a warning banner at the wrong stage does not prevent the outcome.
The next diagram pins the two boundaries that matter most in this course, where text becomes DOM and where approval becomes a request.