The Agnes API uses a single auth scheme — HTTP bearer tokens — backed by per-tenant API keys. Auth0 JWTs are accepted on a small set of admin and user endpoints (Auth0 web app sessions only); programmatic clients should always use API keys.Documentation Index
Fetch the complete documentation index at: https://docs.lasscyber.com/llms.txt
Use this file to discover all available pages before exploring further.
Bearer header
For example:Live versus sandbox keys
| Prefix | Bills? | Calls upstream models? | Use for |
|---|---|---|---|
ak_… (live) | Yes | Yes | Production traffic. Counts against your monthly token quota. |
ak_test_… (sandbox) | No | No, returns deterministic canned results | Tests, CI, example apps, MCP integration scaffolding. |
Minting and rotating keys
Keys are minted from the dashboard atagnes.lasscyber.com/keys or via the
API (see the API keys reference).
The full key value is shown once at creation and is never available
again — Agnes only stores a salted hash. To rotate:
- Mint a new key with the same description / scopes.
- Roll the new key out to your callers.
- Delete the old key once traffic has fully drained.
Scopes
Each key carries a list of scopes that limit what it can do. The dashboard key creator exposes the full canonical list; the most common bundles are:- Analyzer-only —
analyzer:run, the per-analyzer*:analyzescopes, andanalyzer_logs:read. Suitable for production guard keys that only callPOST /api/v1/analyze/and read their own logs. - Read-only —
*:readscopes only. Suitable for dashboards and one-off audit scripts. - Admin — adds policy / YARA / SDP / safety-policy CRUD and
api_key:*. Mint sparingly; prefer Auth0-based admin via the dashboard.
Tenant resolution
Agnes is multi-tenant. The tenant for a request is resolved automatically:- API key — the key’s owning tenant is used. You cannot send an
X-Tenant-IDheader to override this; the API rejects mismatches. - Auth0 JWT (web dashboard) — the tenant comes from the user’s current selection in the tenant switcher.
Pinning the API contract version
The Agnes API is versioned by date (today:2026-04-16). The version
is metadata on the OpenAPI document, not on the URL. Pin it on each
request to decouple your client from server evolution:
Agnes-Version HTTP header. Future minor server
changes will branch on it to keep older clients working. See the
Versioning policy for the full lifecycle.
Email verification
The API requires that the user behind a JWT-authenticated request has a verified email address. If a JWT request lands without a verified email, the API returns403 with code: "email_not_verified". API key requests
are exempt; verification is a one-time human step.
If you hit this, see email_not_verified.
Common pitfalls
X-API-Keyis not supported. Older docs occasionally reference this header; the production API only acceptsAuthorization: Bearer.- Do not put keys in client-side code. Treat API keys like passwords. The browser SDK is intentionally bound to dashboard JWTs, not API keys.
- One key per integration. It is much easier to revoke a single compromised key than to rotate one shared key across many services.
Next
- Quickstart — your first call end to end.
- API keys — programmatic CRUD and the audit log.
- Errors → unauthorized — what
401looks like and how to recover.