Security model

Ódinn is designed around one trusted local operator and multiple untrusted inputs: model output, public web content, imported packages, manifests, policies, capsules, and tool output.

Secure defaults

• The single-user gateway binds to loopback.
• Gateway control requires a per-state bearer token or same-site bootstrap cookie.
• Cookie-authenticated mutations require an exact origin.
• Public web reading blocks private-network targets.
• Browser work uses an isolated profile.
• Browser mutations require approval.
• Unknown tools receive the most restrictive safety classification.
• Extensions, agents, and skills install disabled and untrusted.
• State and sensitive records are repaired to owner-only permissions.

Shared execution boundary

Built-in tools and enabled extension or MCP adapters cross the same policy-gated, audited runtime boundary. Visibility to a model does not grant permission to invoke a tool.

Forked workers contain crashes and supervise timeouts. They retain the parent operating-system identity, filesystem, environment, and network authority; they are not a security sandbox.

Network and filesystem controls

Web fetches validate addresses, reject private and metadata ranges by default, and recheck redirects. Browser traffic uses the same domain and network policy. Workspace reads resolve real paths and reject escaping symlinks.

Recovery model

Approvals and browser mutations use durable journals. An interrupted unsafe outcome becomes a review item instead of being silently retried. State backup, installer rollback, Rewind, and capsule verification each cover a defined local recovery problem; none guarantees reversal of remote changes.

Operator responsibility

Use dedicated, least-privilege credentials. Review packages before enablement. Do not weaken network or browser approval settings without understanding the impact.

For a structured adversarial view, read the Threat model. For non-goals, read Known limits.