Authorization Model
Three independent layers — Capability SKUs, Feature Flags and Kill Switches — and how authorization is enforced server-side.
Authorization in AuthSpoke is decided on the server. The client is never the sole gate, so the UI, SDKs, CLI and AI agents all get the same answer.
Four enforcement points#
- Authentication — a valid bearer token is required for non-public endpoints.
- Tenant isolation — the token's tenant scopes every query. Cross-tenant data is invisible.
- Capability SKUs — some endpoints require a licensed capability. Absent it, the API returns
403 capability_not_licensed. - Provider gate — cross-tenant management routes (
/support/**) require provider-admin allowlist membership.
Three separate control layers#
A recurring design rule: these are distinct and must never be conflated.
| Layer | Question it answers | Scope | Managed by |
|---|---|---|---|
| Capability SKUs | What has this tenant licensed? | Per tenant | Provider |
| Feature Flags | Is this functionality rolled out? | Per tenant | Provider |
| Kill Switches | Should we stop this right now? | Global | Provider (also JMX) |
See Capability SKUs, Feature Flags and Kill Switches.
Roadmap: the AI Policy engine#
Beyond these platform-level gates, a fine-grained AI Policy engine will decide what each agent may do — tools, MCP access, data classification, model usage — with explainable allow/deny decisions, enforced the same way: server-side.