Security & your data
Know what stays on your machine, what is synchronized, and what each credential can do.
On this page
Metadata is the default record
A privacy promise about storage is not a promise that hosted services never see content. The optional gateway necessarily handles request content in memory. In direct device mode, that traffic goes straight from the machine to the provider.
| Data | Handling |
|---|---|
| Prompts, responses, tool arguments | Not stored in the control-plane database |
| Usage and sessions | Model, tokens, cost estimates, timestamps, session/repository identifiers |
| Local provider keys | Remain on the machine in direct and shared-device modes |
| Gateway requests | Pass through server memory; not stored as request bodies |
| Optional stored gateway keys | Envelope-encrypted on the server |
| Handoff notes | Private file you create and review locally |
Use the narrowest credential
Human sessions, CLI access tokens, device tokens, virtual provider keys and the server service token are separate. Customer machines never need the database owner URL. Tokens intended for one route family do not grant generic administrative access.
Tenant tables have Postgres row-level security policies and requests are scoped by workspace identity. Production and staging refuse missing control secrets. Local development requires an explicit insecure-default opt-in if you choose that mode.
Protection has a defined boundary
Only requests routed through Leash are controlled. Killing a stream cannot reverse computation already processed by a provider. Conservative reservations can temporarily overstate spend. Pricing changes and unsupported charge surfaces require explicit review.
Live OAuth, merchant checkout, provider invoices, email delivery, backups and deployment acceptance require real operator verification. A local test suite does not establish those external outcomes.