Security & Supply Chain

Release Signing

Release archives carry a signed package-manifest bundle. Stable releases add signed SBOM and GitHub provenance evidence. These layers do not cover the same artifact boundary:

The manual YubiKey step signs the local validation binary. Deferred package surfaces such as Homebrew will derive from CI-built release assets when enabled, not from the locally signed binary.

Verify a Release

# Offline package and companion verification
omegon-maintain --json release verify \
  --archive /absolute/path/omegon-<version>-<target>.tar.gz \
  --manifest /absolute/path/omegon-<version>-<target>.tar.gz.manifest.json \
  --bundle /absolute/path/omegon-<version>-<target>.tar.gz.manifest.sigstore.json

# Additional online provenance check
gh attestation verify omegon-*.tar.gz --repo styrene-lab/omegon

The offline verifier accepts only explicit absolute archive, manifest, and bundle operands. It applies compiled repository, workflow, issuer, and tag policy and does not discover, download, extract, or execute release content. GitHub Attestations are supplementary online provenance evidence, not a substitute for package-pair verification.

SBOM

Stable releases include a CycloneDX Software Bill of Materials (omegon-sbom.cdx.json) listing all Rust crate dependencies with versions. The SBOM is signed with cosign. Nightly releases do not publish the stable-only SBOM asset.

Credential Storage

API keys, operator tokens, and OAuth credentials are stored through the secrets engine:

• macOS — Keychain Services
• Linux — Secret Service API (GNOME Keyring, KWallet)
• Windows — Credential Manager
• Recipes — env:, cmd:, keyring:, file:, and vault: references stored without secret values

OAuth tokens are refreshed automatically. JWT claims are extracted for account identity (used by the Codex client for account ID routing).

/secrets set VAULT_ROOT_TOKEN   # Hidden TUI input
/secrets set VAULT_TOKEN keyring:VAULT_ROOT_TOKEN   # Alias one keyring secret to another
/secrets get VAULT_ROOT_TOKEN   # Check resolution without printing the value

HashiCorp Vault Integration

/vault status       # Check Vault connectivity
/vault login        # Authenticate to Vault
/vault configure    # Set Vault address and auth method
/vault init-policy  # Create a least-privilege policy for omegon

For teams that manage secrets through Vault, Omegon can read credentials directly from Vault paths instead of environment variables or the local keychain.

Token auth can also bootstrap from an Omegon-managed keyring secret by adding"secret_name": "VAULT_ROOT_TOKEN" under auth in~/.omegon/vault.json. The token is loaded into the Vault client in memory and is not exported into the shell environment.

{
  "addr": "https://vault.example.com:8200",
  "auth": {
    "method": "token",
    "secret_name": "VAULT_ROOT_TOKEN"
  },
  "allowed_paths": ["secret/data/omegon/*"]
}

Tool and Filesystem Permissions

Omegon mediates operations through layered tool policy and workspace-boundary checks. When a tool targets a path outside the currently trusted workspace, the agent run pauses until you choose a scope in the permission modal. The prompt shows the tool, exact target, and proposed directory before any grant is installed.

A known capability with no matching permission rule currently receives the permission layer's allow default. That default does not admit arbitrary names: privileged calls must resolve a current declared owner, capability, effects, principal, and surface before Omegon issues an execution lease. Unknown or incomplete declarations fail closed.

Dynamic Contribution Trust

Extension, executable plugin, and MCP code requires separate stable-identity admission throughpermissions.trustedContributionCode. Installation, enablement, activation markers, and trustedDirectories are not code-trust grants.

{
  "permissions": {
    "trustedContributionCode": [
      "extension:my-extension",
      "plugin:my-plugin",
      "mcp:project",
      "mcp:acp-client"
    ]
  }
}

Omegon binds each runtime permit to the current admitted source or configuration digest, but the profile grant remains identity-based across updates. Review changed bundles before installing them. Native processes, scripts, local MCP, and current OCI paths are trusted execution, not verified confinement or a security sandbox.

These directory choices apply to workspace-boundary prompts. A policy prompt without a durable grant target remains allow-once even if a frontend offers broader approval wording.

Hands-off permission bypass

Operators who intentionally want a non-interactive, unrestricted Omegon permission posture can opt in when launching the process:

omegon --dangerously-bypass-permissions

This bypasses Omegon's interactive tool-policy and filesystem-boundary mediation for that process. It does not write trusted-directory grants, add trusted contribution IDs, bypass contribution preflight, or mint verified-confinement evidence. It cannot override operating-system permissions, macOS privacy controls, container or mount boundaries, missing credentials, or upstream API authorization. Use it only in an environment where you accept the consequences of every tool call made by the agent and its inherited child runs.

Process Safety

• The agent executes tools directly under a layered tool policy. Per-tool rules can allow, prompt, or deny operations with wildcard subject matching.
• Policy prompts are currently allow-once decisions until durable grants are configured; the no-rule allow default applies only after capability admission and cannot make an unknown tool executable.
• Bash mediation is static and advisory for common shell forms. Hard filesystem containment belongs to the sandbox layer.
• Outside-workspace file prompts wait for an explicit operator decision instead of timing out as denial; run cancellation still unblocks the wait.
• All tool calls are logged in the conversation with full arguments and results.
• Esc or Ctrl+C requests cancellation immediately. The turn remains busy while owned cleanup runs, and effects outside Omegon's ownership boundary may remain unknown or best-effort.
• /status distinguishes strict host-owned cleanup from best-effort or unverified cross-boundary cleanup and reports contribution quarantine diagnostics.
• Session auto-save means you can always audit what happened.
• The --max-turns flag limits how many turns the agent can take before stopping.

License

Omegon is licensed under the Business Source License 1.1. The BSL converts to MIT on 2031-03-19. Non-production use is permitted; production use requires a separate license from Black Meridian, LLC (until the change date).