Portal documentation
Reference for tenant admins and developers. Use it to understand portal areas, API access, key scopes, and signed audit exports.
- Portal architecture →
portal.tonia.ca gives each tenant admin and developer the areas they need, without exposing customer prompts, secrets, or admin tokens.
- Admin API →
Endpoints exposed by the tonia backend at /v1/admin/*. The portal server authenticates to Priv server-side; browser sessions never receive Priv credentials.
- Per-key scope model →
Every tonia_* API key has a scope that controls which providers, categories, and data handling rules it can use.
- Audit chain →
Schema entries (audit.db). Every admin mutation emits an entry signed through HD secp256k1 derivation. The tools/verifier.py verifier checks everything offline.
Portal architecture
The portal is separate from customer API traffic. Use it to manage access, review policies, issue keys, and export audit evidence. Send application traffic to the API gateway, not to the portal host.
portal.tonia.ca/ ├── /signin Invite-only sign-in ├── /tenant/[slug]/ Tenant admin ├── /dev/[slug]/ Developer workspace ├── /status Public service status └── /trust Public trust hub
Admin API
These endpoints are wired directly by the portal:
POST /v1/admin/tenantsGET /v1/admin/tenantsPOST /v1/admin/tenants/<slug>/api-keysPOST /v1/admin/tenants/<slug>/byok-upstreamGET /v1/admin/audit-export?tenant=<slug>
Use the portal screens to list, rotate, revoke, and issue keys, adjust policy and DLP settings, and manage restriction profiles. Browser sessions never receive backend credentials.
Per-key scope model
Every tonia_* API key has a scope. The scope controls provider access, allowed request categories, DLP behavior, audit labels, and whether a developer can issue the key for themselves.
Audit chain
Schema entries (PRIV-API/src/tonia/db/schema_audit.sql). Hash-chained, signed through HD secp256k1 derivation at m/44'/111111'/0'/0/n. The offline verifier (~80 LOC) lives in tools/verifier.py.