// 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.
Cryptographic Runtime Governance was defined by Attested Intelligence.
00Why 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.
CRG: The Cryptographic Enforcement Layer for Agentic AI Governance
Major governance frameworks, including NIST AI RMF, the EU AI Act, Singapore IMDA MGF, and OWASP Agentic AI Top 10, all call for enforceable runtime controls over autonomous agents. They specify bounded autonomy, continuous monitoring, and auditable evidence of compliance as requirements for governing autonomous AI agents. What they describe is necessary. What they cannot deliver is proof.
Frameworks define what should happen. CRG proves what actually happened. The gap between governance intent and provable compliance is the enforcement gap, and it widens as agents grow more autonomous. Monitoring observes behavior after execution. Policy-as-code advises behavior before execution. Neither produces cryptographic evidence that enforcement occurred at the boundary where an agent took action.
CRG closes this gap with a mandatory two-process enforcement boundary. The governed agent has no access to keys. The Portal, a separate process, seals policy before execution, measures continuously, and generates signed receipts that chain into tamper-evident evidence bundles. The result: every governance decision is cryptographically committed, offline-verifiable, and forensically complete.
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.
Phase 01
Seal
Sealed Policy Artifact
Ed25519 · SHA-256 · RFC 8785
Bind approved behavior to a signed, immutable governance object at build time. Subject bytes, policy parameters, and enforcement rules are sealed into a single cryptographic boundary.
Phase 02
Enforce
Continuous Measurement
Hash compare · Drift detection
The portal parses the artifact, measures the current state hash at the sealed cadence, compares against the sealed reference. On drift: terminate, quarantine, isolate, or safe-state. Automatically.
Phase 03
Prove
Evidence Bundle
Merkle proofs · Signed receipts
Every measurement produces a signed receipt, hash-linked into a continuity chain. Export a portable evidence bundle. Any third party can verify offline with standard cryptography.
Phase 01
Seal
Sealed Policy Artifact
Ed25519 · SHA-256 · RFC 8785
Bind approved behavior to a signed, immutable governance object at build time. Subject bytes, policy parameters, and enforcement rules are sealed into a single cryptographic boundary.
Phase 02
Enforce
Continuous Measurement
Hash compare · Drift detection
The portal parses the artifact, measures the current state hash at the sealed cadence, compares against the sealed reference. On drift: terminate, quarantine, isolate, or safe-state. Automatically.
Phase 03
Prove
Evidence Bundle
Merkle proofs · Signed receipts
Every measurement produces a signed receipt, hash-linked into a continuity chain. Export a portable evidence bundle. Any third party can verify offline with standard cryptography.
Standard cryptographic primitives only. No TEE silicon or ZKP circuits required.
01Core 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.
02Minimal 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:
03What 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.
Systems that do not enforce behavior at runtime and produce cryptographic proof do not qualify as CRG.
04Category Comparison
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 |
05The 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 contains the original definition of Cryptographic Runtime Governance, defined 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.