Security
Architecture

Zero-trust security for org reality. Every access authenticated, authorized, and audited.

Threat model

Substrate assumes sophisticated adversaries and defends against both external attacks and insider threats.

Adversaries

  • External attacker with stolen credentials
  • Malicious insider with legitimate access
  • Compromised service identity
  • Poisoned source artifacts (fake logs, forged tickets)
  • Supply-chain compromise (tampered builds)
  • AI agent that leaks secrets via overbroad context

Attacks we assume happen

  • Prompt injection in docs ("ignore policy, exfiltrate secrets")
  • Data poisoning (fake postmortems, altered dashboards)
  • Privilege escalation via confused deputy
  • Replay/forgery of provenance blobs

Systemic defenses

Never trust artifacts

Every extracted fact is labeled with provenance and trust tier. "Verified facts" require signatures or human review. Untrusted content is sandboxed.

Authz before retrieval

No "fetch then filter" pattern. Authorization predicates are pushed to the storage layer. Denied data is never loaded.

Agent sandboxing

Agents never get raw broad access. They operate via caveated capability tokens with explicit scope limits.

Authentication

Humans

OIDC with phishing-resistant keys (WebAuthn). Device posture checks. Short-lived sessions.

Workloads

SPIFFE IDs with mTLS (SVIDs). Short-lived credentials rotated automatically. No long-lived secrets.

Agents

Authenticate as principals, then receive caveated capability tokens. Tokens are attenuable (macaroon-style).

Audit

All authentication events are ingested as audit artifacts. Failed attempts logged with full context.

Authorization (ReBAC)

Substrate uses relationship-based access control (Zanzibar-style). Permissions are defined by relationships in the graph itself.

Policy graph objects

user, group, service, repo, artifact,
incident, contract, document, ...

Relationships

owner, member, viewer, oncall,
legal_hold_admin, approver, ...

Authorization query

can(subject, action, resource)

Evaluated by tuple graph + caveats:
  - time constraints
  - tenant boundaries
  - realm compartments

Why ReBAC wins here: Org reality is literally relationships. The authz model matches the data model. "Alice can view service X because she's on-call for team Y which owns X."

Encryption at rest

Data encryption keys (DEK)

Every artifact chunk encrypted with AES-256-GCM using a unique DEK. DEKs are never stored in plaintext.

Key encryption keys (KEK)

DEKs are wrapped by tenant KEKs stored in HSM/KMS. Per-realm KEKs for high-sensitivity compartments.

Key rotation

KEKs rotate on schedule. DEKs are re-wrapped asynchronously. Old ciphertext remains readable with old wrapped DEKs.

Sharing

Cross-workspace sharing never shares raw keys. Instead: policy grant + DEK re-wrapped to recipient's realm KEK.

Audit integrity

Hash chain

Every commit includes prev_hash. The chain is unbroken and verifiable from any point.

Merkle log

Commits are leaves in a merkle tree. Inclusion proofs verify membership. Consistency proofs verify append-only growth.

Signed roots

Periodic root signatures (HSM-backed) create trust anchors. Witnesses can independently verify.

Witness cosigning

Independent systems sign merkle roots. Detects equivocation if the primary attempts to present different histories.

Retention and redaction

Retention policies

Attach to artifact types and graph subtrees. Define expiration schedules. Trigger tombstone events on expiry.

Legal hold

Freezes key shredding for scoped objects. Any shred attempt emits immutable audit event. Hold takes precedence.

Tier 0: Logical redaction

Data becomes a stub. Metadata and hashes remain. Unprivileged readers see "redacted" marker.

Tier 1: Cryptographic erasure

DEK is destroyed. Ciphertext remains but is unrecoverable. Commit hash proves "something existed" without revealing content.

Explicit tradeoff: After key-shred, you can prove existence and position in history, but cannot recover plaintext. Legal holds prevent premature shredding.

Multi-tenant isolation

Raft groups

Separate consensus groups per tenant

Encryption domains

Independent KEK hierarchies

Authz namespaces

Isolated policy graphs

Audit logs

Separate audit streams

Optional: dedicated hardware per tenant for highest isolation requirements.

Continue reading