In short
The model sees the names, descriptions and parameter types of the actions you registered, plus whatever app state you chose to pass, and nothing else. It does not browse your database, it does not hold your API keys, and the sentence your customer typed reaches it as data rather than as an instruction it may follow.
On this page
What is actually in the prompt
A reasonable worry about putting a model inside a banking or insurance app is that it quietly gets handed everything. It does not, and the list is short enough to read in one line: action names, action descriptions, parameter types, and the app state you pass.
That is the whole input. An action's description is a sentence you wrote about one of your endpoints; it is not the endpoint's data. When the assistant needs a customer's actual balance it does not recall it — it asks for an action to be run, and your API answers.
So the honest way to put it is that the model knows the shape of what your app can do, and nothing about who is using it beyond what you decided to pass.
Text is data, never an instruction
The sharper version of the worry is prompt injection: a customer types something that reads like an order, or a field in your own app state contains a sentence someone put there earlier, and the assistant obeys it.
App state and user text are data, never instructions. They are carried into the turn as material to reason about, not as directions to follow, and the guardrail that says so sits in the prompt itself rather than in a filter bolted on afterwards.
This is also why a write never rests on the model's word. A change is drawn on a confirmation card our servers build from your action and the validated parameters — the model never emits one — and nothing moves until the person taps it.
POST, one stream, and one row of usage. The stream ends whenever the server needs something from the device; the device answers by opening the next one. Nothing is held open waiting.Where the keys and values live
The key in your app's build is a publishable key, and it cannot reach your console, your other apps or your secret keys. Somebody pulling your APK apart gets a key that can start conversations for that one app and nothing more.
The credentials your actions need are a separate story: a saved key goes only to its own host, so a key you saved for one API is never attached to a request going somewhere else. Placeholder values are encrypted at rest.
Underneath, every query runs under the app's tenant context, and row-level security enforces it again. Two layers, because one of them is a thing a person could get wrong.
What anyone keeps, and for how long
The row people check first is the provider's. API inputs and outputs are deleted on a short fixed schedule, which is the answer to the question security reviews actually mean when they ask whether a model is trained on their customers.
Feedback is worth naming too, because it is the one place a customer types freely and nobody expects it to be read later: a rating and its typed reason are masked before storage.
| Who | What they hold | For how long |
|---|---|---|
| Your app's build | A publishable key for that app | Until you rotate it |
| Rendel | Conversations, under your app's tenant context | Your app's retention setting |
| The model provider | API inputs and outputs | A short fixed schedule, then deleted |
| A rating someone leaves | The rating and its typed reason, masked | Stored masked, not raw |
Questions
No. It sees action names, descriptions and parameter types, and the app state you pass. Data arrives only when an action you registered is run and your API answers.
App state and user text are data, never instructions. A write also waits on a confirmation card our servers build from your action and the validated parameters, so a sentence alone changes nothing.
It is a publishable key. It cannot reach your console, your other apps or your secret keys.
The provider deletes API inputs and outputs on a short fixed schedule. `/docs/reference/security` is the page to send a security reviewer.
