Security Model

Security Model | Corevexa Docs
CVX Corevexa Docs
Home Getting Started Architecture API Roadmap FAQ

Security Model
Protect the Governance Layer

Layer-7 is a high-value target: if an attacker can bypass policy, forge approvals, or tamper with the ledger, governance collapses. The security model defines threat assumptions, identity standards, secret handling, and hardening requirements.

Threat Model Identity & Signing Secrets Break-Glass
Protect policy + approvals Tamper-evident ledger Default deny if degraded
Security posture: degrade safely. If integrity or identity cannot be verified, governed execution must stop.

Threat Model (What We Defend Against)

The system is designed to assume compromise attempts. The goal is not “perfect security” — it’s to ensure that compromise becomes detectable, containable, and non-silent.

Approval forgery

Attackers attempt to impersonate approvers or inject fake signatures to satisfy authority gates.

Policy tampering

Attackers attempt to weaken gates, swap policy versions, or bypass evaluation.

Ledger manipulation

Attackers attempt to delete, rewrite, or reorder events to hide actions and bypass audit trails.

Execution bypass

  • Direct tool access (execute without Layer-7 enforcement).
  • Gateway downgrade (turn off enforcement checks).
  • Replay attacks (reuse old approvals or tokens).

Insider abuse

  • Privilege misuse (approve outside intended scope).
  • Silent override attempts (skip logging).
  • Break-glass abuse (emergency access without review).
Design objective: attacks may happen, but they must be hard to execute and easy to detect via the ledger.

Security Boundaries

Layer-7 is a boundary between intent and execution. Security is strongest when the execution layer cannot act without a valid, confirmed governance outcome.

Boundary A — Governance Engine

  • Evaluates policy gates and computes risk
  • Routes authority requirements
  • Writes ledger events

Boundary B — Execution Gateway

  • Reads enforcement outcomes
  • Validates ledger confirmation for governed actions
  • Blocks direct execution when governance is missing
Separation doctrine: the engine decides and records; the gateway enforces. If either is bypassed, the system is not Layer-7 compliant.

Identity & Signing

Authority is only real if identity is real. Approvals must be tied to authenticated identities and verifiable signatures. The minimum requirement is authenticated identity + non-replayable approval records.

Identity requirements

  • Authentication: OAuth/OIDC or enterprise SSO
  • Role claims: roles and scopes embedded in tokens
  • Device / session: session binding where possible
  • Non-replayable: approvals include nonce + TTL

Approval signing (recommended)

  • Signed payload: approver signs decision_id + intent + timestamp
  • Verification: engine verifies signature before accepting approval
  • Ledger record: store signature_ref + method (not private keys)
  • Revocation: handle role changes by policy (future decisions)
# Signed approval payload (concept) payload = sha256(decision_id + intent + issued_at + nonce) signature = sign(private_key, payload) ledger.approval.added = { decision_id, actor_id, role, intent, issued_at, nonce, ttl_seconds, signature_ref, method: “signed_payload” }
If signature verification fails, the approval is rejected and the decision remains pending authority.

Secret Handling

The ledger is not a secret vault. Policy decisions must avoid storing secrets in decision payloads. Sensitive values should be referenced, hashed, or stored in a separate secrets system.

Rules

  • Never store raw credentials, API keys, or tokens in the ledger.
  • Store references (vault path, secret id) instead of values.
  • Store hashes for integrity checks (sha256 of normalized value).
  • Encrypt at rest + in transit; limit payload detail by role.

Patterns

  • Pointer pattern: payload includes secret_ref only.
  • Envelope pattern: sensitive blob encrypted; key access restricted.
  • Redaction pattern: log summary; store details elsewhere.
  • Field allowlist: only approved keys can enter the ledger.
If payload contains forbidden fields (secret-like patterns), the engine should deny and emit a policy gate failure event.

Ledger Protection

The ledger must be tamper-evident and access-controlled. Strongest posture uses immutable storage and periodic integrity checks.

Write path controls

  • Append-only storage configuration
  • Write confirmations returned to engine and gateway
  • Hash chain enforced per decision stream
  • Dual-write (optional) to separate storage tiers

Read path controls

  • RBAC summary vs raw payload access
  • Export controls for audit downloads
  • Access logging (who viewed what, when)
  • Break-glass reads produce separate ledger events
A ledger that can be modified silently is not a ledger. It’s a database.

Break-Glass Access (Emergency Mode)

Break-glass is allowed only for real emergencies. It must be explicit, time-bound, scoped, and reviewed. Break-glass does not mean bypassing the ledger; it increases logging and review requirements.

Break-glass requirements

  • Role: L5 (executive) or L4 (security) per policy
  • Reason: mandatory structured reason string
  • TTL: short-lived authorization window
  • Scope: target-bound and action-class-bound
  • Review: mandatory post-incident review event

Break-glass event (example)

{ “event_type”: “breakglass.activated”, “actor”: { “id”: “user_*”, “role”: “executive_approver” }, “payload”: { “reason”: “Incident response – outage mitigation”, “ttl_seconds”: 1800, “scope”: { “action_class”: “deploy_code”, “target_id”: “svc_31” } } }
Break-glass is not permission to skip governance. It is a governed exception mode with stronger audit visibility.

Deployment Hardening

Hardening focuses on reducing bypass paths and ensuring “degraded mode” fails safe. The enforcement gateway must refuse governed actions when identity, policy, or ledger confirmation is missing.

Hardening checklist

  • mTLS between engine, gateway, and ledger
  • Network segmentation (engine not publicly exposed)
  • Strict allowlist for action classes + tools
  • Rate limits and anomaly detection for approvals
  • Immutable policy store (hash-addressed bundles)

Degraded mode behavior

  • Ledger degraded: deny/queue governed actions
  • Identity degraded: deny approvals and require re-auth
  • Policy store degraded: deny (no fallback to unknown policy)
  • Gateway degraded: stop execution (fail closed)
Fail-closed is what makes Layer-7 credible. Fail-open is how governance becomes theater.
Next: Deployment Models Back: Decision Ledger API Reference
Corevexa Docs — Layer-7 Governance Infrastructure
© Corevexa Labs