Awa's security boundary has two parts: PostgreSQL privileges determine who can read or mutate queue state, while network placement and callback authentication determine which HTTP surfaces are reachable. Production deployments should separate both.
| Concern | Guidance |
|---|---|
| Database ownership and grants | Database roles and privileges |
| Admin UI, callbacks, workers, and network exposure | Deployable surfaces |
| Callback authentication and custom receivers | Callback security |
- Use a non-login schema owner, a migration login, and a separate runtime login.
- Keep
awa serveon an authenticated operator network. It is a database administration surface, not a public application endpoint. - Put externally reachable callbacks on a callback-only listener or in your own application router; do not expose the admin router with them.
- Configure callback signatures unless an authenticating proxy or trusted network already provides the boundary.
- Use TLS, rotate secrets per environment, and avoid logging callback signatures.
The current 0.6 runtime and the 0.7 development runtime still need broad DML and TRUNCATE privileges on Awa's internal tables. ADR-043 defines a proposed capability-function design for narrower roles; do not treat that future design as a shipped security control.
The admin UI, callback ingress, workers, and maintenance tasks have different exposure profiles. See Deployable surfaces for supported deployment shapes and network boundaries.