The signed-in user

Who is asking, how the copilot reaches your API as them, and what happens when they sign out or switch accounts.

Three different things identify something in Rendel, and only one of them is anybody's permission to do anything.

	What it is	What it proves
App key (`rd_pk_…`)	Ships in your app or page. Names your app and its environment (test or live).	Nothing about the person. Anyone with your app has it.
`identify`	The id of the person signed in to your app, from your own sign-in.	Who the conversation belongs to: their history, their memory, the person a confirmation was shown to. With identity verification on, an HMAC from your backend proves it.
User token	The signed-in person's own token for your API, from your auth library.	Whatever your API decides it proves. Your API checks it, as it does for your own app.

Your agent wires all three with one prompt: see Sign-in and identity.

When the token reaches us, and when it does not

Actions registered in your app run in your app, with your app's own session. The token never needs to leave the phone or the page.
Actions connected in the console and set to the signed-in user's token are called by our server, with the token your app hands over on that question, as Authorization: Bearer. It is used for that call and dropped. It is never stored, logged, shown in the console, or put in front of the model.
Any other console action uses a key you stored, an account made for the copilot, or nothing. Those may only read.

When it is asked for

Before every question. Return the current token: if your auth library refreshed it in the meantime, the new one is used. Return null when nobody is signed in. A provider that throws costs that question the token, not the answer.

What changes something, and for whom

A console action that changes something (a POST, PUT, PATCH or DELETE you marked as such) needs all of this:

It runs as the signed-in user. The database refuses any other kind of credential for it.
The turn names the person with identify (proved by HMAC if you verify identities). With nobody named, it is not offered.
The user confirms it on the card, and the server records that tap for the device that owns the conversation.
The request that continues after the tap names the same person. A token refreshed for them is fine. Somebody else signed in on the same phone is not: the change is not made, and the copilot asks again.

The server then calls your endpoint once, however often the continuation is retried. If the answer is lost on the way back, the copilot says it does not know whether the change happened instead of trying again. See Actions from the console.

Sign-out and switching accounts

reset() clears the conversation on the device, the person, and any card still on screen; the next question is anonymous until the next identify. Calling identify with a different id clears the conversation too. If your app switches accounts without calling either, the server still will not spend one person's confirmation on the next person's token (rule 4 above), but the old answers stay on screen, so call reset() on sign-out.

401 and 403

401 from your endpoint, for a console action called as the user: the person's session has most likely ended. The copilot says so, and the call is not repeated. Your app's next token, from your own refresh, is used on the next question.
403: your API said this person may not do this. The copilot tells them it cannot be done here. Nothing retries it.

Testing with a real account

On the console's Test page, Talk as signs in to your API as a test user, or creates one through your app's own sign-up, and sends the token with each question the way your app would. See Test as a real user.

Who enforces permissions

Your API. The copilot can reach only the actions you connected, only as the person asking, and only after they confirm anything that changes something; what that person is allowed to change is your API's decision, exactly as it is for your own app.