Security & Supply Chain

Release Signing

Every release is signed at multiple levels, but not all signatures cover the same artifact boundary:

Layer	Method	What it covers	Verification
CI release artifacts	Sigstore cosign (keyless, OIDC)	Published GitHub release archives consumed by downstream packaging	`cosign verify-blob`
Local macOS validation binary	Apple Developer ID (YubiKey)	Operator workstation build produced before publish	`codesign -dvvv`
Provenance	GitHub Attestations (SLSA)	CI build provenance for published release assets	`gh attestation verify`

The manual YubiKey step signs the local validation binary. Homebrew and other package surfaces are derived from CI-built release assets, not from the locally signed binary.

Verify a Release

# Cosign (CI-signed releases)
cosign verify-blob omegon-0.21.1-aarch64-apple-darwin.tar.gz \
  --signature omegon-0.21.1-aarch64-apple-darwin.tar.gz.sig \
  --certificate omegon-0.21.1-aarch64-apple-darwin.tar.gz.pem \
  --certificate-identity-regexp '.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

# GitHub Attestations
gh attestation verify omegon-*.tar.gz --repo styrene-lab/omegon

SBOM

Every release includes a CycloneDX Software Bill of Materials (omegon-sbom.cdx.json) listing all Rust crate dependencies with versions. The SBOM is itself signed with cosign.

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/*"]
}

Process Safety

The agent executes tools directly — no sandbox. The operator is responsible for reviewing tool calls.
All tool calls are logged in the conversation with full arguments and results.
Esc or Ctrl+C cancels the active turn immediately.
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).