Glossary
Definitions of key terms in the Attested Governance protocol, cryptographic verification, and runtime integrity enforcement.
Core Concepts
Agentic AI Governance
CoreThe discipline of managing autonomous AI agents: defining permissions, monitoring behavior, enforcing compliance at runtime, and producing verifiable evidence of enforcement. In the AGA architecture, governance operates through three layers: static policy enforcement (Block), behavioral drift detection (Detect), and phantom execution (Capture). Distinct from observability or logging, which record what the agent reports.
AI Agent Security
CoreSecuring autonomous AI agents against manipulation, drift, unauthorized tool use, and forensic evidence gaps. Encompasses identity, authorization, runtime enforcement, and audit. AGA addresses AI agent security through a mandatory two-process enforcement boundary where the agent holds no signing keys.
Three-Layer Governance
CoreThe AGA enforcement model: Block, Detect, Capture. Layer 1 (Static Enforcement) blocks unauthorized tool calls against sealed policy. Layer 2 (Behavioral Detection) monitors tool-call distribution over sliding windows and generates signed BEHAVIORAL_DRIFT receipts when patterns deviate. Layer 3 (Phantom Execution) captures bypass attempts by returning spoofed success responses while forensically recording the complete attack sequence.
Runtime Governance
CoreGovernance controls operating during system execution rather than at build time or during periodic audits. In AGA context, the Portal's continuous measurement and enforcement loop that operates at cadences from milliseconds to seconds.
Attested Governance Artifact(AGA)
CoreA cryptographically signed policy object that defines integrity constraints, telemetry policies, and enforcement mappings for a governed subject. The foundational unit of the Attested Intelligence protocol.
Policy Artifact
CoreA sealed governance object containing integrity baselines, telemetry stream definitions, enforcement rules, and cryptographic signatures. Immutable once signed. Supports Ed25519 (classical), ML-DSA-65 (post-quantum), or hybrid composite signatures.
Evidence Bundle
CoreA portable package containing the policy artifact, signed receipts, continuity chain state, and Merkle inclusion proofs. Verified offline through a five-step process without network connectivity.
Portal (Enforcement Engine)
CoreThe runtime boundary that monitors governed subjects, evaluates drift against policy constraints, and executes enforcement actions with signed receipts. The Portal holds all signing keys; the governed subject holds none and cannot self-authorize.
Technical Terms
Continuity Chain
A hash-linked sequence of receipts where each receipt includes the hash of the previous, creating a tamper-evident execution history. Deletion or reordering of any receipt breaks the chain.
Enforcement Receipt
A cryptographically signed record documenting a policy decision. Includes timestamp, policy reference, action details, and previous receipt hash for chain linking. Receipt types include tool authorization, behavioral drift, and phantom capture.
Behavioral Drift Detection
Layer 2 of the three-layer governance model. A sliding window monitors tool-call distribution and rate over time. When the observed pattern deviates from the sealed baseline beyond configurable thresholds (chi-squared on distribution, z-score on rate), a signed BEHAVIORAL_DRIFT receipt is generated.
Phantom Execution
Layer 3 of the three-layer governance model. When an agent attempts to bypass enforcement via alternative tool paths, the Portal transitions to phantom mode. The agent receives spoofed success responses and believes it succeeded. Real outputs are severed. Every attempted action is captured forensically as signed receipts.
Launch Gate
The mandatory entry point for governed runs. Validates policy signature and time window before allowing subject execution.
Merkle Checkpoint
Periodic Merkle tree computed from receipt leaf hashes and anchored to immutable storage. Provides global ordering and enables offline inclusion proof verification.
Leaf Hash
Hash computed from receipt structural metadata (type, version, timestamps, subject identifier) excluding payload content. Enables third-party chain integrity verification without payload disclosure.
Sealed Hash
The cryptographic hash of a subject's state captured at policy sealing time. Used as the integrity baseline for drift detection.
Subject
Any governed entity monitored by the Portal. Can be an AI agent, model, container, or any system with a measurable integrity state and tool-call interface.
Tool Authorization
Static enforcement (Layer 1) where the Portal evaluates each tool call against the sealed policy. Unauthorized tools are denied. Authorized tools with denied argument patterns are blocked. Every decision generates a signed receipt.
Five-Step Verification
The evidence bundle verification process: (1) verify policy artifact signature, (2) verify each receipt signature, (3) validate receipt chain continuity via previous_receipt_hash, (4) compute leaf hashes and verify Merkle inclusion proofs, (5) confirm computed Merkle roots match the bundle root.
Two-Process Separation
The mandatory architectural boundary where the Portal (signing keys, enforcement logic) and the Subject (governed agent) run as separate processes. The subject never holds signing keys and cannot self-authorize.
Disambiguation
Action Risk vs Output Risk
DisambiguationAction risk arises from autonomous agents taking actions (tool invocations, system state modifications) as opposed to generating outputs. Distinguished from output risk (hallucinations, bias, toxic content). AGA addresses action risk through cryptographic enforcement at the execution boundary. Output risk requires model-level defenses, which are complementary but separate.
Zero-Knowledge Proof(ZKP)
DisambiguationA cryptographic protocol that proves a computation was performed correctly without revealing the inputs. ZKP systems verify computational correctness. AGA addresses a different question: did the system operate within its authorized governance constraints? AGA does not use ZKPs. The two approaches are complementary.
Trusted Execution Environment(TEE)
DisambiguationA hardware-based isolation mechanism (e.g., Intel SGX, ARM TrustZone, AMD SEV) that protects code and data from the host system. AGA does not require TEEs but can deploy the Portal within one for hardware-level non-bypassability. TEE attestation quotes can serve as a measurement input to the Portal.
Confidential Computing
DisambiguationA paradigm where data is protected during processing using hardware-based TEEs. AGA's privacy-preserving feature operates differently: structural metadata linking excludes payload data from leaf hash computation, enabling third-party verification of chain integrity without disclosing sensitive event contents.
Cryptographic Primitives
Ed25519
Elliptic curve signature algorithm (RFC 8032) used for signing policy artifacts and receipts. Provides 128-bit classical security with 64-byte signatures and 32-byte public keys. Default for classical deployments.
ML-DSA-65
Post-quantum lattice-based signature algorithm (NIST FIPS 204). Provides NIST Level 3 security with 3,309-byte signatures and 1,952-byte public keys. Used in post-quantum and hybrid composite signature modes.
Hybrid Composite Signatures
Default signature mode for new deployments. Produces both Ed25519 and ML-DSA-65 signatures over the same artifact. Verification requires both to pass. No downgrade fallback. Ed25519-only artifacts from existing deployments remain verifiable.
SHA-256
Cryptographic hash function (FIPS 180-4) used for content addressing, chain linking, leaf hash computation, and integrity verification throughout the protocol.
BLAKE2b-256
Alternative hash function (RFC 7693) used for artifact fingerprinting. Lower-latency option alongside SHA-256. Hash algorithm is explicit in the artifact schema and included in signatures.
JCS (RFC 8785)
JSON Canonicalization Scheme providing deterministic serialization for cryptographic operations. Ensures hash consistency across all implementations and languages.
Merkle Trees
Binary hash trees (RFC 6962) used for checkpoint anchoring with inclusion proofs. Enable offline verification that a specific receipt is part of a checkpoint without downloading the entire chain.