Extensions and MCP

Ódinn treats extension and MCP manifests as metadata—not trust. Installation records a package but leaves it disabled and untrusted.

Safe lifecycle

1. Inspect the manifest and provenance.
2. Verify the immutable bundle or entrypoint digest.
3. Install it disabled.
4. Grant only the capabilities it needs.
5. Enable it deliberately.
6. Inspect its first run and audit record.
7. Disable or roll back when it is no longer needed.

Install and inspect:

odinn extension install --manifest ./extension.json
odinn extension list

Enable with explicit grants:

odinn extension enable \
  --id example-tool \
  --grant web.read \
  --trust

Execution adapters

Container is the default for third-party executable code. It verifies the complete bundle and runs with a read-only mount, no network, dropped capabilities, no-new-privileges, and bounded CPU, memory, processes, temporary storage, time, and output.

Unconfined process is for fully trusted local code only. It runs with the Ódinn operating-system user’s filesystem and network authority. Enabling it requires verified entrypoint integrity, explicit trust, an unsafe-sandbox acknowledgement, and an impact confirmation.

Neither adapter makes external effects reversible.

MCP

MCP extensions use the same audited Sentinel and capability boundary as other extensions. Their tool calls use a structured JSON-RPC adapter. Direct execution that bypasses the runtime boundary is rejected.

Disable and roll back

odinn extension disable --id example-tool
odinn extension rollback --id example-tool

Disabling prevents future invocation. It cannot undo changes already made outside the local workspace.

Advanced: invoke a reviewed extension

odinn extension run \
  --id example-tool \
  --capability web.read \
  --input-json '{"query":"release notes"}'

Structured input is validated, bounded, policy-checked, and audited.