How it works

Operation firstCopy Anchor Link

Mihe does the thing. Ask it to mark an order complete and the order is marked complete, through your permission model, with a confirmation when it matters and a record of what happened. When it cannot do something, or the user is better off doing it themselves, it shows them where: it navigates, highlights, focuses an input or opens a form. Showing is the fallback, not the product.

What the assistant knowsCopy Anchor Link

Two things, from two places:

• The registry, published from your build. It lists your screens, the actions the assistant may run, and any walkthroughs. It is what the assistant is allowed to do, and it lives on our side, so nothing in the browser can add to it.
• The live context, sent by the SDK as the user moves around: which screen they are on, the summary values on it, and the components it can point at. It is what the assistant can see.

A turnCopy Anchor Link

1. The user asks, by typing or speaking.
2. Policy decides what the model is offered. From the registry, it takes the actions that are enabled, available on this screen, and allowed by the permissions in the user's token. An action the user may not run is never offered, so the model is never shown something it may not do.
3. The model proposes a tool call, or answers in words.
4. Policy checks the call. The input is validated against the action's schema, and the permissions are checked again. The model's output never reaches an effect without passing this check. The code that talks to the model cannot even import the code that decides.
5. If it needs confirming, the user sees a card. Otherwise it runs.
6. Your app runs it. A frontend action runs your handler in the browser. A backend action is a signed HTTP call to your server.
7. The result goes back to the model, which tells the user what happened.

Every attempt is written to the audit log, including the ones policy refused.

Why the card is worded by your registryCopy Anchor Link

The confirmation card shows the action's label and description from your registry, and the exact input the action will receive. Nothing on it is written by the model.

That is the defence against prompt injection. Text inside your own data, a product name or a customer note, can try to instruct the assistant. It cannot change what the user is shown they are approving, and it cannot ask for an action the user is not already allowed to run. See permissions and risk for where the line is.

Typed or spokenCopy Anchor Link

A spoken request and a typed one go through the same dispatch, with the same policy, the same confirmations and the same audit log. Voice is an input, not a second system.