Access-control model
Access decisions in Advania ALT are based on role and ownership. There are no per-resource ACLs or shared-with-user mechanics at launch — the mental model is deliberately simple.
What you see
| Resource | As a Developer | As an Admin |
|---|---|---|
| Your own API keys, KBs, sessions | Full read/write | Full read/write |
| Other users' API keys, KBs, sessions | Not visible — the API returns 404 | Full read/write |
Developers only see and manage what they created. Admins can see and act on any resource in the account.
Response codes
| Scenario | Status |
|---|---|
| Resource doesn't exist, or you don't own it (as Developer) | 404 Not Found |
| Endpoint requires Admin role, caller is Developer | 403 Forbidden |
| Endpoint requires a signed-in user, caller uses an API key | 403 Forbidden |
| API key lacks the required scope | 403 Forbidden |
| Guardrails blocked the request | 403 Forbidden, type: guardrail_error |
404 on missing/other-user resources (rather than 403) is deliberate — a Developer cannot distinguish "doesn't exist" from "exists but I don't own it."
Practical guidance
- Treat
403as non-retryable — get the right role, scope, or auth type first - Log
x-request-idon every failed call — support uses it to look up the request - Don't build role detection into your client — treat capability failures as "not available to me right now"