Privacy and security
What screen data leaves the device, how identifiers are masked before it does, and the one control that does not apply to mobile apps.
Screen state is the most sensitive payload in this product: it is your own form fields, mid-KYC, with a customer's identifiers in them. This page states plainly what happens to them.
Identifiers are masked on the device
Before any screen frame is sent, values are scanned and replaced. This happens in the app, on the phone, before the network.
| Detected | Becomes |
|---|---|
| PAN | [PAN] |
| Aadhaar | [AADHAAR] |
| Card and account numbers | [CARD] |
| Phone numbers | [PHONE] |
| Email addresses | [EMAIL] |
The agent is told a field is filled, empty or rejected, and what the validation message says. It is not told the number, because it does not need it to help.
The same rules run again on our side, so a value missed on the device is still caught before it reaches the model.
Add your own formats
Policy numbers, customer references, internal ids — anything with a shape we cannot know about:
Register these once when your app boots, not per screen. A masking rule you have to remember to apply on each screen is the rule that will be missing from the screen that matters.
What is stored
- Conversations — transcripts and outcomes, in your call history, exactly as web and phone conversations are.
- Actions — which action ran, on which screen, and whether it succeeded. This is what lets you measure recovered drop-offs.
- Screen state — used to shape the conversation as it happens. It is not kept as a separate record after the conversation ends.
Values already masked on the device are masked everywhere downstream. There is no unmasked copy to recover.
The publishable key in a mobile app
The domain allowlist does not protect a mobile app.
It works by checking the web origin a browser reports, and a mobile app does not send one. So the allowlist you configured for your website — and the wording on Install & domains — does not cover your app.
Treat a publishable key shipped inside an APK or IPA as public, because anyone can extract it. What bounds it today:
- Rate limits per key and per address
- Single-use, short-lived connection tickets — one per conversation, not replayable
- Your agent's own credit limits
Mobile app attestation — binding a key to your signed app via Play Integrity and App Attest — is in progress. If your risk assessment needs it before launch, raise it with us and we will sequence it with your rollout.
What the SDK never does
- Never reads the screen by itself. It reports only the fields you pass to
useGraineScreen. There is no screen recording and no accessibility scraping. - Never opens the microphone until you call
start(). - Never performs an action you did not implement and register.
- Never asks for a permission on your behalf.
Data residency and compliance
Conversations are processed in the region configured for your organisation. For DPDP, SOC 2 and audit documentation, see Enterprise security.

