Resources
ReferenceSecurity
Read-only role checklist
What the host, the customer, and the SDK each own. Prefer a dedicated SELECT-only user or read-only IAM principal.
docs/security.mdIf the stored user can DELETE, a missed validation case is a write. Prefer credentials that cannot write even if the SDK is wrong.
| Typical credential | Prefer | |
|---|---|---|
| Postgres | URI or host / user / password | CONNECT + SELECT only |
| Firestore | Service account JSON | Read-only IAM, not Editor |
| Later drivers | URI or provider config | Equivalent read-only role |
Customer checklist
- Create a read-only role (SELECT only, or IAM that can only read).
- Restrict schemas and collections. Do not expose payroll if the product does not need it.
- Use TLS. Do not disable SSL in production.
- Network-restrict if you can (allowlist, VPC, tunnel, private link).
- Rotate credentials when people leave, and revoke access when you disconnect.
Stolen credentials should still be read-only. That is why the database role is the lock, and why SDK checks are extra layers.
Keep going
Guide
Security model
Treat generated queries as untrusted. SDK checks are extra — the lock is a read-only database role.
Pattern
Run a model-written query
The app owns the model and the API key. DB SDK takes the catalog out, treats the query as untrusted input, and runs a bounded read.
Reference
Postgres
First SQL driver: connection, introspection from information_schema, parameterized SELECT, limits and timeouts.