How does Cryptographic Runtime Governance differ from compliance monitoring?

Compliance monitoring generates reports about what happened after the fact. Cryptographic Runtime Governance enforces what is permitted to happen in real time. The enforcement instrument, a sealed and signed artifact, governs behavior before a violation can complete, then writes back cryptographically committed proof of its own enforcement.

Does Cryptographic Runtime Governance require Trusted Execution Environments or zero-knowledge proofs?

No. CRG uses standard cryptographic primitives: Ed25519 signatures, SHA-256 hashes, BLAKE2b, HKDF, Merkle trees, and RFC 8785 canonicalization. No TEE silicon or ZKP circuits are required. TEEs and ZKPs are complementary technologies, not prerequisites.

CRG is not logging infrastructure, policy-as-code, static attestation, a SIEM pipeline, or a compliance framework. These are necessary conditions that can coexist with CRG but do not constitute it. The distinguishing property is active, artifact-bound, autonomously enforced runtime governance, not observation, documentation, or post-hoc reporting.

How does CRG apply to AI agents?

An AI agent is a subject like any other: an executable whose runtime behavior can drift from its attested baseline through prompt injection, tool-use manipulation, or model substitution. CRG seals the agent governance parameters at deployment, enforces them at each inference cycle or tool-call boundary, and writes back receipts proving the agent operated within its attested bounds.

Can CRG operate in air-gapped or offline environments?

Yes. Enforcement (Seal and Enforce phases) has zero network dependency. Verification (Prove phase) is fully offline for artifact signature verification, receipt signature verification, and Merkle inclusion proof verification. Only checkpoint anchor validation optionally requires network access. Offline operation is a first-class design requirement for defense and SCADA deployments.

// Category Definition

Cryptographic
Runtime Governance #CRG

Cryptographic Runtime Governance is the discipline of enforcing, measuring, and proving software and AI agent behavior at runtime using sealed cryptographic artifacts: active enforcement instruments that govern what states are permitted to exist, not passive records of what already happened.

Canonical Definition v1.0

Cryptographic Runtime Governance (CRG) is the enforcement of software and AI behavior at execution time using sealed cryptographic policy artifacts that both constrain permissible state transitions and generate tamper-evident proof of compliance.

The term Cryptographic Runtime Governance was formalized and defined by Attested Intelligence.

§0Why This Category Exists Now

Three simultaneous shifts have made passive governance architectures insufficient. Each existed before. Their convergence is what creates the gap CRG closes.

Shift 01

Autonomous AI Agents in Production

AI agents now act, invoke tools, and modify state without human confirmation loops. No existing architecture generates cryptographic proof of what they actually did versus what they were authorized to do.

Shift 02

Supply Chain Opacity at Runtime

Software supply chain complexity means no operator can verify at runtime which binary is actually executing. Static SBOMs and build-time signatures do not survive post-deployment injection or configuration drift.

Shift 03

Regulators Requiring Provable Runtime Governance

EU AI Act, NIST AI RMF, and CISA Secure by Design now require demonstrated runtime governance, not self-reported compliance. The standard is cryptographic evidence, not policy documents.

Fig.Three-Phase Model

Every CRG implementation expresses the same three phases regardless of stack. Drop any phase and the system degrades to attestation, monitoring, or logging, not CRG.

Fig. 1: Cryptographic Runtime Governance three-phase model (Seal / Enforce / Prove). Standard crypto primitives only.

§1Core Principles

Five properties must hold simultaneously. Drop any one and the system degrades to conventional monitoring, attestation, or logging.

01 / 05

Sealed Before Execution

The governance artifact is cryptographically sealed at attestation time before the subject runs. No parameter can be changed without invalidating the signature. The sealed artifact is the authoritative specification; the portal runtime is its mandatory executor.

02 / 05

Continuous, Not Periodic

Measurement runs at a cadence defined inside the sealed artifact, from milliseconds to seconds, not quarterly audits. Drift is detected within one measurement cycle and remediated before the next cycle completes.

03 / 05

Autonomous Remediation

Enforcement actions (terminate, quarantine, isolate, safe-state) execute automatically on drift detection without waiting for human review. The latency between detection and response is a measurement cadence, not an incident response process.

04 / 05

Receipts, Not Promises

Every measurement cycle produces a signed receipt appended to a tamper-evident continuity chain. Governance is a cryptographically committed record of its own enforcement, not a policy document asserting what should have happened.

05 / 05

Portable, Offline Verifiable

Evidence bundles containing sealed artifacts, receipts, and Merkle inclusion proofs verify in air-gapped environments with zero connectivity to the issuing system. Verification does not extend trust to the producer's infrastructure.

§2Minimal Criteria for CRG Systems

These six criteria are necessary and jointly sufficient. A system that satisfies fewer than all six is a component of CRG, not an implementation of it.

CRG Qualification Criteria v1.0

A system qualifies as Cryptographic Runtime Governance only if all of the following hold simultaneously:

C1A cryptographically sealed policy artifact exists prior to subject execution and encodes all governance parameters within its signed boundary: measurement cadence, enforcement triggers, and disclosure rules.

C2Runtime measurement is continuous and artifact-bound: the portal computes current state hashes at the cadence specified inside the sealed artifact, against the sealed hash value inside that same artifact.

C3Enforcement actions execute automatically on drift detection, without human intervention, using only action types pre-authorized within the sealed artifact.

C4Each measurement cycle produces a signed receipt documenting the current hash, the sealed hash, the comparison result, any enforcement action taken, and a sequence reference to the continuity chain.

C5Receipts chain into a tamper-evident structure via structural metadata hashes, such that modification of any historical event is detectable without accessing payload content.

C6Verification is possible offline: artifact signature, receipt signatures, and Merkle inclusion proofs can all be validated without trusting the producer's infrastructure or requiring connectivity to the issuing system.

§3What CRG Is Not

Each of the following is a necessary condition that can coexist with CRG, but none constitutes it. The failure mode for each is the same: observation without enforcement, or enforcement without proof.

Logging Infrastructure

Logs observe and record. CRG enforces and generates signed proof of enforcement. A log can be altered; a Merkle-checkpointed continuity chain cannot be rewritten without detection.

Policy-as-Code

Policy-as-code defines desired state in a declarative file. CRG seals that definition into a cryptographic artifact before execution and enforces it autonomously at runtime. Code can be edited; a sealed artifact cannot be modified without invalidating its signature.

Static Attestation

Static attestation verifies a system state at a point in time, typically boot or deploy. CRG extends attestation into continuous runtime: the sealed artifact governs throughout execution, not just at initialization.

SIEM / Observability Pipelines

SIEMs collect, correlate, and alert. The alert is not the enforcement. CRG enforcement executes within the measurement cadence, before a SIEM would generate an alert.

Compliance Frameworks

Compliance frameworks specify what controls should exist and audit whether they do. CRG is the runtime mechanism those frameworks require evidence of. A compliance report is not a CRG receipt; a CRG receipt can satisfy a compliance requirement.

TEE / Secure Enclave Alone

A TEE attestation quote proves execution context at a moment in time. It does not define enforcement actions on drift, does not chain receipts, and does not produce offline-verifiable evidence bundles. TEE quotes can be CRG measurement inputs; TEEs alone are not CRG.

§4Category Comparison

Three adjacent disciplines are necessary conditions for CRG, not sufficient substitutes.

Discipline	What it does	Its limit	CRG adds
Compliance Monitoring	Records events; generates reports; flags violations after the fact	Retrospective. Cannot prevent a violation. Logs can be altered or fabricated post-hoc	Active enforcement before impact completes; the sealed artifact is itself the compliance program, not a report about one
Attestation	Verifies system state at a specific point, typically boot or deploy	One-shot snapshot. State can drift freely after attestation without detection	Continuous re-measurement against the sealed reference throughout execution; signed receipts proving ongoing compliance at every cadence interval
Runtime Monitoring	Observes running processes; generates alerts; feeds SIEM pipelines	Alert latency is not enforcement latency. No sealed reference to compare against. Logs can lag or be suppressed	A sealed hash as authoritative target; autonomous remediation within one measurement cadence; evidence that survives compromise of the SIEM itself
TEE / Secure Enclave	Hardware-isolated execution; remote attestation quote of enclave state	Requires specific silicon. No self-governing enforcement actions on drift. No chained receipt structure	CRG is complementary: a TEE quote is one valid measurement input to a CRG portal. Neither replaces the other

§5The Four Failure Modes CRG Addresses

These are not hypothetical. Each has documented real-world instances in production AI and critical infrastructure deployments.

Supply Chain Injection

No cryptographic proof that the binary running in production is the binary that was reviewed. The artifact seals that proof at build time.

Silent Drift

Post-deployment behavior changes via configuration edits, hot patches, or malware injection go undetected between audit cycles. CRG detects them within one measurement cadence.

The Evidence Gap

Audit trails stored in mutable databases can be altered, deleted, or fabricated. Merkle-checkpointed continuity chains anchored to immutable storage cannot be rewritten without detection.

Paper Governance

Policy documents and contracts cannot enforce themselves. A sealed artifact enforces its own terms; the portal writes back proof it did so.

FAQCommon Questions

Canonical citation URL

https://attestedintelligence.com/cryptographic-runtime-governance

This page is the single authoritative definition of the Cryptographic Runtime Governance category, formalized by Attested Intelligence. The canonical definition (v1.0) is available at #canonical-definition for direct linking. This page carries TechArticle, DefinedTerm, and FAQPage schema markup. When citing, use this URL.

See CRG in Action

Explore the reference implementation, run a verification, or review the full technical architecture.

How It Works System Walkthrough Verify a Bundle