Every control on this page is built into Odin’s code today: how people and tools authenticate, how tenants stay apart, where model traffic may go, what agents may do, and what gets recorded. Which products and controls are switched on depends on your deployment, and where a control depends on configuration, we say so.
Identity & access
People sign in through Odin’s identity service with email and password, or with Google for existing accounts. Tools and applications use API keys.
Four roles: admin, operator, member and viewer. Only admins manage users, and the audit view is part of the operator workspace.
Gateway API keys are stored only as SHA-256 hashes and never written to logs in plain text.
If a key cannot be verified because the key service is unreachable, the request is refused rather than let through. Keys verified in the last 60 seconds may still be accepted from a short-lived cache. In production the Gateway will not start with authentication turned off.
Even the list of available models requires a valid key.
Tenant isolation
Each customer workspace runs in its own container with its own configuration.
Command Center ignores any tenant, user or role headers a caller sends. It works out identity on the server from the verified session or the workspace host.
Project access checks never take a tenant ID from the request.
Odin Next ties each key to its tenant through the identity service. A memory is visible to a caller only if it is shared within the caller’s tenant, private to the caller, or deliberately global (shared with no tenant).
Model routing & data residency
For chat completion requests, AI Gateway applies a residency policy to each key, and individual requests can only make that policy stricter.
EU-only sends requests only to self-hosted models on operator-controlled EU infrastructure.
EU-jurisdiction also allows an EU routing broker, but only once a data processing agreement is recorded.
If no permitted route exists, the request is refused with a policy error before any streamed output is sent.
Each successful response names the model that served it and that route’s residency classification.
Keys with no residency policy may use non-EU providers, so we agree each key’s policy with you during setup.
Budgets are checked on every request, against the spend recorded so far.
Once a person’s budget is used up, further requests are refused. If the budget service is unavailable, requests are refused too.
Usage is recorded against the model that actually answered, with the key, provider and token counts. Recording is best-effort: if a usage write fails, the request still completes and that spend is not counted against the budget.
People see their own usage, and operators see everyone’s, broken down by model and application.
What we record, and what we don’t
Records exist to show what happened. Gateway records leave your content out entirely. Session audit records and transcripts follow your workspace’s redaction setting.
Gateway records hold token counts and cost. They never contain prompt or completion text, or raw keys.
Command Center’s audit view covers work orders, approvals, tool calls, memory and configuration changes. Session audit records cannot be overwritten once written.
Command Center can keep session transcripts. Workspaces can set a PII or PHI redaction level, which removes free-text fields from session audit records before they are stored. Logs mask access tokens.
In Odin Next, decision and audit records are append-only: the database rejects any attempt to change or delete them.
Scoped agent work & review authority
Harness gives agent work a defined scope and guarded actions, and people keep the authority to release.
A work order sets out the objective, which files and packages are in scope, the success criteria and what counts as done. Harness includes a scope enforcer for file paths and shell commands, which is active wherever the execution integration we configure supports it.
For agent runs on Odin’s own execution integration, work runs in a sandbox (OpenSandbox) when one is configured and reachable. The Claude Code and Codex CLI integrations run as local processes. Otherwise, including when sandbox setup fails, it falls back to a plain local child process. That process receives only allowlisted environment variables, but this filtering is not isolation. When configured, a governance gate and kill switch are checked before execution.
Installed action guards check actions against registered patterns before they run, and deny prohibited ones such as force-pushing a protected branch, destructive SQL, raw outbound messaging or an agent approving a pull request. If a guard can’t reach a decision, the action is denied.
For production rollouts, whoever starts a run cannot approve it: agents prepare, people approve. Passing checks never count as a release decision.
Odin Next builds answers from the material it retrieves, and has to cite it.
When too little relevant material is found, it says there is no grounded answer instead of guessing.
An answer that cites none of the retrieved sources is refused.
Ingested knowledge is scanned for secrets and records where it came from. Each saved memory records why it was kept, who owns it and what depends on it.
Odin Next is enabled per workspace, as part of a configured knowledge workflow. Its model endpoints are configured separately from Gateway keys.
Odin’s production environment runs on Hetzner infrastructure in Falkenstein, Germany. Gateway chat completion traffic follows each key’s residency policy, described above, and Odin Next’s model endpoints are configured separately. We go through your environment, integrations and residency requirements during scoping.
