Security by structure, not by patch

OmegaOS™ Kernel is fail-closed by default, append-only by structure, and advisory-only by design. Every mitigation is structural — built into the schema, the runtime, and the deployment model.

Threat model

🔒

Unauthorized data access

Mitigated by Row-Level Security (RLS) enforced per tenant at the Postgres level, plus API key authentication with ~285 bits of entropy.

📓

Audit trail tampering

Mitigated by append-only schema. Runtime services (hovo_app) can only INSERT — no UPDATE or DELETE on ledger tables. Revocations create new records.

🔑

License bypass

Mitigated by Ed25519 offline verification. Public key embedded at compile time. No license server, no network dependency. Tampered tokens fail cryptographic check.

🔎

Leaked builds

Mitigated by build fingerprinting. Every binary embeds git_sha + build_timestamp + customer_tag at compile time. Fingerprint appears in health checks and decision logs.

Fail-closed by default

When the upstream PDP is unreachable or evaluation fails, the gateway defaults to DENY in enforce mode. This is controlled by OPA_FAIL_MODE, which defaults to closed.

Fail-open systems silently grant access when they break. Fail-closed systems block access when they break. For compliance-sensitive environments, fail-closed is the safe default.

Scenario	Fail-Closed	Fail-Open
OPA unreachable	403 Forbidden	Synthetic allow (logged)
Internal error	403 Forbidden	Synthetic allow (logged)
License expired	Auto-downgrade to OBSERVE

Advisory-only design. OmegaOS™ Kernel produces structured decisions that inform human operators. It does not autonomously execute downstream actions. In observe and shadow modes, it is purely advisory.

Row-Level Security

Every query runs through Postgres RLS policies. The hovo_app role can only access rows matching the current tenant context, set at the start of each transaction.

Even if an attacker achieves SQL injection through the application layer, they cannot access another tenant's data — the database enforces isolation at the row level.

Role	RLS	Used By
hovo_admin	BYPASSRLS	CLI tools, migrations
hovo_app	Enforced	hovo-api, hovo-gateway

Key guarantee: hovo_admin is never used by runtime services. It is restricted to operator tools that run separately.

Append-only ledger

Six ledger tables are INSERT-only for the runtime role. No decision can be retroactively altered.

 -- Grants for hovo_app (runtime services): GRANT INSERT ON
decisions,
  proofs,
  proof_revocations,
  decision_events,
  decision_proofs,
  claims
TO hovo_app;
-- No UPDATE or DELETE granted.
-- Revocations are new INSERT records, not deletions.
-- Full history is always available for audit. 

Evidence integrity

HMAC-SHA256 chain of custody from external source to decision record.

External connectors (CRIF, Zefix, WorldCheck) sign each evidence item with HMAC-SHA256, creating an unforgeable chain of custody from external source to decision record. Evidence arriving without a valid HMAC signature can be flagged or rejected at ingestion — proving data integrity at the application layer, independent of transport encryption.

Domain separation tags (OMEGAOS:EVIDENCE:v1:) prevent hash collision across security contexts.

Property	Value
Algorithm	HMAC-SHA256
Domain separation	`OMEGAOS:EVIDENCE:v1:`
Scope	Per-evidence item, per-connector
Verification	At ingestion — before decision

Cryptographic proof chain

Three independent cryptographic layers — each verifiable without trusting the others.

Merkle Tree (RFC 9162)

Each decision is chained into an append-only Merkle tree. Any retroactive modification breaks the root hash. Inclusion proofs are verifiable in O(log n) operations without revealing other decisions.

Ed25519 Signatures

Export manifests, licenses, and build attestations are signed with Ed25519. Public key embedded at compile time. Verification is fully offline — no external service required.

RFC 3161 Timestamps

Merkle roots are periodically anchored to a qualified Time Stamping Authority (RFC 3161, compliant with ZertES and eIDAS). Provides legally-binding proof of decision timing admissible in Swiss and EU courts.

Formal verification

The five system invariants are formally specified in TLA+ and verified by the TLC model checker over finite state spaces. This is model checking — exhaustive exploration of a bounded state space — not theorem proving.

The verified invariants are:

Indeterminate is the primitive — T/F require resolve()
Append-only ledger — no UPDATE, no DELETE
Determinism — same inputs produce same outputs
Tenant isolation — no cross-tenant data access
No automatic irreversible action — human-in-the-loop required

Specification	Scope
OmegaResolve.tla	Determinism, no primitive T/F, tenant isolation
OmegaLedger.tla	Append-only, hash chain, no mutation
OmegaInvariants.tla	All 5 invariants combined

Nuance: TLC verifies invariants over a finite model. This proves absence of violations in the explored state space. For full mathematical proof, formal theorem proving (e.g. Coq, Isabelle) would be required — this is not claimed.

API key authentication

Format: delk_ + 48 alphanumeric characters (~285 bits entropy)
Storage: bcrypt hashed (cost 12) — plaintext shown once at generation
Rotation: Maximum 2 hashes per tenant for zero-downtime key rotation
Mapping: API key → tenant_id is the single source of truth for RLS context

License verification

Algorithm: Ed25519 signature verification
Key management: Public key embedded in binary at compile time
Network: Fully offline — no license server, no phone-home
Fallback: Expired/invalid tokens auto-downgrade gateway to OBSERVE

Build watermarking

Every binary embeds a forensic fingerprint at compile time for traceability.

 # Fingerprint embedded at build: { "git_sha": "abc12345",
"build_timestamp": 1739712000,
"customer_tag": "acme-corp" } # Appears in: # - /gateway/health response # - /api/v1/health response # - Structured logs for every decision 

Customer tag binding: Licenses can optionally include a customer_tag that must match the build's embedded tag. Mismatched tags cause the license to fail — preventing license reuse across different customer builds.

Network hardening

Kubernetes

NetworkPolicy restricts traffic: only the gateway accepts external connections. The API is cluster-internal only. Admin tools run as one-off Jobs, not persistent deployments.

HTTP limits

Max body size: 1 MiB (configurable). Request timeout: 30 seconds. OPA connect timeout: 3 seconds. OPA read timeout: 10 seconds. All configurable via environment variables.

Container security

Non-root user (65534), read-only root filesystem, all capabilities dropped, seccomp RuntimeDefault profile. No privilege escalation allowed.

Infrastructure & Jurisdiction

The infrastructure supporting this website is hosted in Switzerland and operates under Swiss jurisdiction.

Data hosted within Switzerland
Subject to Swiss legal framework
No intentional transfer of data outside Switzerland
No third-party behavioral analytics

Explore deployment options

Security architecture is consistent across all editions. Choose the deployment scope that matches your governance requirements.

Explore Editions