Data access boundaries
Target Audience: Developers & non-technical users defining how Toucan AI accesses data in multi-tenant products.
TL;DR
Toucan AI separates platform data (stored in Toucan) from your business data (stored in your connected databases). Access to your data is always gated by authentication, permissions, and row-level security — not by copying your warehouse into Toucan.
When to use this
Use this page with Security boundaries (embed) to design a secure integration and understand shared responsibilities.
Three data zones
| Zone | What it is | Where it lives |
|---|---|---|
| Platform | Accounts, dashboards, chart configs, AI history, encrypted DB credentials | Toucan AI database |
| Your database | Tables and rows (source of truth) | Your infrastructure |
| Request-time results | Rows returned for a chart or AI answer | Processed per request — not a bulk Toucan copy |
See Data storage & retention for query flow and caching.
How access is enforced
- Embed tokens carry identity, permissions, and attributes for security rules (all database configuration can be passed as attributes).
- Row-level security (RLS) filters which rows each user can query.
- Column-level security (CLS) can restrict which columns are visible.
- Organization isolation separates one customer’s Toucan configuration from another’s.
Security responsibilities
| Responsibility | Your app / backend | Toucan AI platform |
|---|---|---|
| End-user authentication | ✅ | — |
| Embed token generation | ✅ | — |
| API key storage | ✅ | — |
| Define RLS attributes & rules | ✅ | — |
| Enforce RLS at query time | — | ✅ |
| Store platform config & AI history | — | ✅ |
| Store your table data | ✅ (your DB) | — (queries only) |
Typical risks
- Missing RLS on sensitive tables
- Sensitive content in AI chat that gets stored in conversation history