Bring your IdP. We enforce it.
Admin access runs on server-side OIDC sessions against your identity provider — strict token validation, no client-side tokens, and no master-key escape hatch. Inference runs on hashed virtual keys. The two never mix.
The browser holds a cookie. Nothing else.
Trifrost is the backend-for-frontend: tokens live in server-side sessions, and the browser carries only an HttpOnly cookie. No access tokens in JavaScript, no refresh tokens in local storage, nothing for an XSS payload to steal.
Strict validation
Discovery + JWKS with enforced RS256, issuer, audience, and nonce checks on every login. PKCE on the authorization code flow. Anything that doesn't verify exactly is rejected.
Server-side sessions
Session state lives server-side with a configurable TTL and secure cookie flags. Sign-out actually signs out — revoke the session and the cookie is just a string.
Your IdP, not ours
Any standards-compliant OIDC provider works. Point Trifrost at the issuer, register the redirect URI, and your existing groups and policies drive access.
Department membership follows your IdP groups.
On every login, the IdP's roles claim is intersected with each team's registered external auth claims, and department memberships are recomputed from the result. Move someone in your IdP and their Trifrost access follows at next login — no manual re-provisioning.
Orphaned keys get suspended
When a user drops out of every team, their virtual keys are suspended automatically. Departures and reorganizations don't leave live credentials behind.
Invitation-driven membership
Org membership starts from an admin-issued email invitation — accounts can't self-materialize. On first boot, a single bootstrap admin invitation seeds the default customer; after that, every member is invited.
No master-key escape hatch
There is no secret bearer token that bypasses admin auth. Every admin call requires an OIDC session with a customer membership, resolved to an RBAC role in middleware. The class of vulnerability where one leaked credential opens the whole admin plane does not exist in Trifrost.
Permissions as a resource × operation matrix.
System roles — Admin, Developer, Viewer — plus custom roles you define, granting operations per resource. Roles resolve per customer in middleware, so one person can be an Admin in one org and a Viewer in another.
- Resource × operation permissions, checked on every admin route
- Per-customer roles — membership-scoped, resolved in middleware
- Audited mutations — every write lands in the event log
Keys that can't leak value.
Virtual keys, hashed at rest
sk-bf-* keys are stored as SHA-256 hashes — the database shows prefix and last four only. Validation is timing-safe, keys carry expiry and an is_active toggle, and four auth headers are accepted: x-bf-vk, Authorization, x-api-key, x-goog-api-key.
No credentials go upstream
On the streaming path, client Cookie, Authorization, and virtual-key headers are stripped before the request is forwarded. A provider — or anyone watching its logs — never sees your users' credentials.
Provider keys stay secret
Upstream provider API keys are never returned by admin reads — list or get, the field isn't there. The catalog is org-scoped: another customer's providers and models return 404, and the governance cache fails closed.
Defense in depth on the write path too: all JSONB payloads pass through sanitization before they touch the database.
Data residency by construction.
Trifrost is cloud-hosted, and your deployment runs in your region — inference, event logs, and spend data never leave it. Residency isn't a policy promise; it's where the service physically runs.
Regulatory coverage
Regional deployment maps directly onto GDPR, the UK Data Protection Act, the Australian Privacy Principles, and APAC sovereignty requirements — because the data never crosses the border in the first place.
Compliance, certified
SOC 2 Type II, ISO 27001, and HIPAA — done. Reports and letters of attestation are available under NDA during procurement.