Fail closed, by construction.
Anubis is a security control, so the interesting question is not what it does when everything works. It is what it does when something breaks, when a credential leaks, or when a tenant boundary is tested.
Everything that is not an exact allow refuses.
There is exactly one path on which a governed tool call executes: an HTTP 200 whose body is a JSON object whose decision is exactly allow.
Every other condition is a refusal - timeout, transport failure, DNS failure, authentication failure, scope failure, validation failure, payload too large, idempotency conflict, persistence failure, policy unavailable, an unparseable body, a missing decision field, a value outside the closed vocabulary, or an exhausted retry budget.
Anubis being unreachable stops your agent. That is the design, not a degradation. A runtime that proceeds when its authorization service is down was never governed by it - so plan capacity and availability accordingly.
The backend cooperates with clients that only read the body: a 401, 403 or 503 carries "decision": "block" at the top level, so an integration that never inspects the status code still refuses. The SDKs go further and raise, so an authentication failure can never be pattern-matched as a policy outcome.
Identity is not a parameter.
An agent authenticates with a runtime credential in one header. That credential resolves exactly one organization, one agent and one environment, server-side, plus an explicit scope set. POST /api/runtime/evaluate requires the runtime:evaluate scope.
Identity is never a request parameter. The deprecated agent_id and organization_id fields, and context.environment, are treated as assertions: if present and inconsistent with the credential, the call is refused with a 403. They can never select a different agent.
Missing, malformed, unknown, revoked, expired, wrong-environment and foreign-agent credentials all produce the same code. A more specific answer would turn the endpoint into an oracle for which credentials exist.
401 runtime_auth_invalid
Issued once, stored never.
| Issued deliberately | Only an admin can issue a credential, and only for a specific agent. Issuing one for a revoked, retired or suspended agent is refused - it would undo the kill switch. |
|---|---|
| Stored as a hash, shown once | Anubis keeps no copy of the secret. It is displayed at issue and is never retrievable. Losing it means rotating, not looking it up. |
| Rotated and revoked as audited operations | Both are control-plane actions written with their audit entry in the same transaction. Neither is retried automatically, because neither is idempotent - a failure is reported and left for a human. |
| Invalidated by environment promotion | Promoting an agent between environments invalidates its existing credentials. The recovery is rotation, deliberately. |
| Never present in logs or errors | The credential appears in no repr, exception message or log record in either SDK. Evidence rows carry only a key prefix. |
| Server-side only | The TypeScript SDK is Node-only and ships no browser build, because there is no safe way to hand a credential to a browser. |
Roles on the server, isolation in the database.
Control-plane sign-in is handled by Supabase Auth. Roles are enforced server-side, not in the interface: viewer, owner, security_lead and admin.
Two separations matter. Only a security_lead can resolve an approval, and only an admin can administer runtime credentials. An agent credential can do neither - which is what stops an agent approving its own held action.
SSO, SAML and OIDC are not implemented today.
The organization is the isolation boundary. Every agent, policy, credential, decision, approval and audit entry belongs to exactly one organization, and nothing crosses.
You never send an organization id; it is resolved server-side from whichever credential authenticated the call. An id belonging to another organization is reported as not found, identically to an id that does not exist - so the API cannot be used to probe for the existence of another tenant's records.
Isolation is enforced in the database as well as the application: tables carry row-level security, and both paths scope on the authenticated tenant rather than on a value from the request.
The record commits before the answer.
Each accepted evaluation commits its runtime event, its approval if the call was held, and its audit entry in one transaction, before the response is returned. A decision that could not be recorded is returned as a 503 refusal rather than as permission.
Control-plane mutations follow the same rule. A policy edit, lifecycle transition or credential operation whose audit entry cannot be written is rolled back - an action that was not recorded did not happen.
Tool arguments are not stored. input is handed to the decision engine and only a non-reversible fingerprint of its shape reaches the evidence row, so the audit trail does not become a second copy of the data your agents touch.
What Anubis does not protect.
Being precise about what Anubis does not protect is more useful than a longer list of what it does.
Coverage is yours
Anubis governs the calls that ask it. A code path that never calls evaluate is ungoverned, and containment cannot reach it either.
Unwrapped originals bypass
Adapters wrap tool objects; they do not intercept your process. Guard at construction and hand only guarded objects to the agent.
The end user is not authenticated
context.user is recorded, not verified. Anubis does not check who the agent claims to be acting for.
No rate limiting
A valid credential may be used at any rate. Your ingress may add one; do not build a client that depends on being throttled.
Pre-execution only
After an allow, Anubis observes nothing. It does not sandbox, contain or monitor a running tool, and it cannot undo a side effect.
TLS is yours to terminate
The credential is a bearer token. There is no request signing and no nonce, so TLS is the transport defence.
What we do not claim.
Anubis holds no third-party security certification. There is no SOC 2 report, no ISO 27001 certificate, and no third-party penetration test result to share. If a vendor questionnaire asks, that is the answer.
We are also not going to put a compliance badge on this website before it is earned. Everything above describes how the product is built; it is not an attestation, and it has not been audited by anyone outside the company.
Also not implemented today: SSO, SAML and OIDC; SIEM export; hash-chained tamper-evident audit; rate limiting; a hosted Anubis service; and a production deployment package with observability, backup and restore, or DR tooling.
Reporting a security issue.
If you believe you have found a vulnerability in Anubis or in this website, email security@use-anubis.com. Please include enough detail to reproduce the issue.
We will acknowledge your report and keep you updated while we investigate. We will not pursue legal action against researchers who report in good faith, avoid privacy violations and service disruption, and give us reasonable time to respond before disclosing publicly.
There is no paid bug bounty programme at this time.
Private access
Send us the questionnaire.
We would rather work through your security review honestly than discover a mismatch during a pilot.