Technical Reference

Glossary.

Definitions of key terms in the Attested Governance protocol, cryptographic verification, and runtime governance instrumentation.

Agentic AI GovernanceThe discipline of managing autonomous AI agents: defining permissions, monitoring behavior, producing verifiable evidence, and recording policy decisions at runtime. AGA supplies a signed record of each decision it records, checkable offline. Logging and observability systems may also provide independently collected or integrity-protected records; compare what each mechanism binds and verifies.

AI Agent SecuritySecuring autonomous AI agents against manipulation, drift, unauthorized tool use and gaps in forensic evidence. The discipline spans identity, authorization, runtime governance and audit. AGA addresses AI agent security through a two-process separation where the agent lacks the signing key only when the gateway runs under an OS identity whose secrets the agent cannot read.

Three-Part GovernanceThe AGA governance model: Decide, Detect, Capture. Capture here means capturing bypass attempts; it is not the Capture step of the architecture sequence on /technology. Decide ships in aga-proxy, which signs PERMITTED or DENIED for each tools/call and does not forward a call it denies (its default profile, permissive, denies nothing on policy grounds; policy denial needs --profile standard or restrictive, or a --policy file in allowlist or denylist mode; known issue 7 on /security describes the calls refused without a receipt). Detect ships narrowly in aga-mcp-server 3.6.0 through 3.6.2: a rule-based check of its own governed tools (unauthorized tools, rate limits, forbidden sequences), run when the client calls measure_behavior; the rules are the baseline the client supplies at attest_subject, and with none it finds nothing. aga-proxy has none. Capture of bypass attempts exists only in the demo orchestrator, not in a published package.

Runtime GovernanceGovernance controls operating during system execution rather than at build time or during periodic audits. In AGA, the gateway's signed decision at each governed tool call. Measurement on a schedule is in the private reference runtime; the published aga-mcp-server measures on request.

Attested Governance Artifact (AGA)The product name also used for the signed policy object in its architecture. In aga-mcp-server 3.6.0 through 3.6.2 that object is the Policy Artifact below.

Policy ArtifactThe object aga-mcp-server 3.6.0 through 3.6.2 mints and seals at attestation. It holds the subject identifier (a hash of its bytes and a hash of its metadata), the policy reference and version, the sealed baseline hash and its salt, issued, effective and expiration timestamps, the issuer key, enforcement parameters (measurement cadence, TTL, triggers, measurement types), a disclosure policy and evidence commitments, with one signature over all of them. Tamper-evident once signed; the client can mint a new one through attest_subject. Ed25519-signed in the published packages; the ML-DSA-65 + Ed25519 composite is a library export, not the live default.

Evidence BundleA portable package containing signed receipts, a signed checkpoint, and Merkle inclusion proofs. It does not contain the policy; on aga-proxy each receipt carries a SHA-256 reference to it. Verified offline through six cryptographic checks, seven with a pinned issuer key, without network connectivity. A field name repeated in the file still verifies, because the verifiers read the last copy (known issue 5 on /security).

Gateway (Governance Engine)The runtime boundary that evaluates calls against policy and records each decision as a signed receipt. The gateway holds the signing keys; when it runs under its own identity, the governed subject holds none. On aga-proxy the subject has no tool that changes its policy; in aga-mcp-server 3.6.0 through 3.6.2 the client can re-attest its own baseline through attest_subject.

Receipt ChainA hash-linked sequence of receipts where each receipt includes the hash of the previous, creating a tamper-evident decision history. Checked against a pinned gateway key, deleting or reordering any receipt breaks the chain; the key holder can re-sign a different history. A field name repeated in the file still verifies, because the verifiers read the last copy (known issue 5 on /security).

Decision ReceiptA cryptographically signed record documenting a policy decision. Includes timestamp, policy reference, action details, and previous receipt hash for chain linking. The exported receipts are tool-call decisions and, in aga-mcp-server, behavioral drift findings; phantom capture exists only in the demo orchestrator.

Behavioral Drift DetectionPart 2 of the three-part governance model. In aga-mcp-server 3.6.0 through 3.6.2 it is a rule-based check of the server's own governed tools (unauthorized tools, rate limits, forbidden sequences), run when the client calls measure_behavior and recorded as a signed receipt when it finds drift (marked PERMITTED unless the finding is enforced); the rules are the baseline the client supplies at attest_subject, and with none it finds nothing. It is detective-only unless the call asks to enforce. Statistical tests on tool-call distribution and rate are architecture, not shipped. aga-proxy has no drift detection.

Phantom ExecutionPart 3 of the three-part governance model, in the demo orchestrator only: when an agent attempts to bypass governance via alternative tool paths, the agent receives spoofed success responses while real outputs are withheld, and each attempt is captured as a signed record. It is not in a published package. In aga-mcp-server 3.6.0 through 3.6.2, quarantine instead refuses each governed call with a DENIED receipt. The reason that receipt signs overstates this: it says all outputs are severed and inputs captured for forensic analysis, but 3.6.0 through 3.6.2 refuses only its four governed tools, its ungoverned tools (attest_subject among them) keep working, and the captured inputs stay in memory and are never exported. The governed client can lift a quarantine, revocation or termination by calling attest_subject, and the exported bundle does not record that call.

Launch GateIn the architecture, the check that validates the policy signature and validity window before a governed run starts. In the request-access Kubernetes component it is an admission webhook that refuses a labeled pod whose artifact fails; it checks the artifact against the key the artifact carries and pins no issuer key, so a re-signed artifact passes. The published packages do not include it.

Merkle CheckpointA Merkle tree computed from receipt leaf hashes and signed by the gateway. It fixes the order and count of the receipts within one gateway's chain and enables offline inclusion proof verification.

Leaf HashIn an Evidence Bundle, the SHA-256 of the canonical receipt including its signature. Receipts commit to their arguments through arguments_hash, so anyone verifies chain and Merkle integrity without the argument contents. In 3.6.0 through 3.6.2 a path-constraint denial names the offending path in its signed reason, and a denied-pattern denial names the matched pattern.

Sealed HashThe cryptographic hash of a subject's state captured at policy sealing time. Used as the integrity baseline for drift detection.

SubjectThe governed entity a Policy Artifact names, identified by a hash of its bytes and a hash of its metadata. In the published packages it is measured on request, from content the client supplies; nothing in them monitors a model or a container.

Tool AuthorizationThe static decision where the gateway evaluates each tool call against the policy. Each tools/call it evaluates is recorded as a signed PERMITTED or DENIED receipt, except the calls known issue 7 on /security describes as refused without a receipt; in-path, aga-proxy does not forward a call it denies. Its default profile, permissive, denies nothing on policy grounds; policy denial needs --profile standard or restrictive, or a --policy file in allowlist or denylist mode.

Verification: six checks, seven with a pinned issuer keyThe evidence bundle verification process: (1) structural floor, the algorithm and key are valid and every receipt matches the strict schema; (2) every receipt signature verifies; (3) chain and ordering, receipts link by previous_receipt_hash with non-decreasing canonical timestamps; (4) Merkle inclusion proofs verify and the proof set is a bijection over the receipts; (5) the gateway-signed checkpoint binds the recomputed Merkle root, leaf count, and chain head; (6) envelope consistency, the bundle's stated roots match what was recomputed. A seventh check, gateway key match, runs only when a pinned issuer key is supplied. A field name repeated in the file still verifies, because the verifiers read the last copy (known issue 5 on /security).

Two-Process SeparationThe architectural boundary where the gateway (signing keys, decision logic) and the Subject (governed agent) run as separate processes. The subject holds no signing key when the gateway runs under its own identity, and the gateway is its only path to tools when the deployment makes it so.

Adjacent technologies.

Action Risk vs Output RiskAction risk arises when autonomous agents take actions: tool invocations and system state modifications. It is distinct from output risk (hallucinations, bias, toxic content). AGA addresses action risk through cryptographic governance at the execution boundary. Output risk requires model-level defenses, which are complementary but separate.

Zero-Knowledge Proof (ZKP)A cryptographic protocol that proves a computation was performed correctly without revealing the inputs. ZKP systems verify computational correctness. AGA addresses a different question: which decisions were recorded, and was that record altered? AGA does not use ZKPs. The two approaches are complementary.

Trusted Execution Environment (TEE)A 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. A deployer may run the gateway inside one; AGA does not consume or verify TEE attestation quotes.

Confidential ComputingA paradigm where data is protected during processing using hardware-based TEEs. AGA's privacy-preserving feature operates differently: receipts commit to arguments by hash, so a third party verifies integrity without the argument contents. In 3.6.0 through 3.6.2 tool names are plaintext, a path-constraint denial names the offending path, and a denied-pattern denial names the matched pattern.

Cryptographic primitives.

Ed25519Elliptic 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-65Post-quantum lattice-based signature algorithm (NIST FIPS 204). Claimed in FIPS 204 to be in NIST security category 3, with 3,309-byte signatures and 1,952-byte public keys. Used in the hybrid composite signature mode.

Hybrid Composite SignaturesThe post-quantum signing mode, implemented and cross-verified as a library export. Classical Ed25519 is the live signature in the published gateway and CLIs, and nothing in them switches it to the hybrid. Where the library profile is used, it produces both Ed25519 and ML-DSA-65 signatures over the same artifact, and verification requires both to pass, with no downgrade fallback. Ed25519-only artifacts from existing deployments remain verifiable.

SHA-256Cryptographic hash function (FIPS 180-4) used for content addressing, chain linking, leaf hash computation, and integrity verification throughout the protocol.

BLAKE2b-256Hash function (RFC 7693) used in the private Go runtime's chain genesis and identity sealing. No receipt, chain, checkpoint or verification step in the published packages uses it; aga-mcp-server 3.6.0 through 3.6.2 carries one unused helper for it.

JSON Canonicalization (JCS-lineage)Sorted-key JSON canonicalization in the JCS lineage, defined by the conformance vectors rather than literal RFC 8785. It gives deterministic bytes for signing, and the published verifiers agree on it across the conformance corpus.

Merkle TreesNo-prefix binary SHA-256 hash trees (defined by the conformance vectors, not RFC 6962; no 0x00/0x01 node prefixes) used for checkpoint binding with inclusion proofs. A tail dropped from a bundle fails against its required signed checkpoint, though an earlier genuine export still verifies. The format lets a verifier check offline that one receipt belongs to a checkpoint without the entire chain; the published verifiers check the whole bundle.

Keep reading

Related pages.

Technology Patent Docs

Glossary.

Core concepts.

Agentic AI Governance

AI Agent Security

Three-Part Governance

Runtime Governance

Attested Governance Artifact(AGA)

Policy Artifact

Evidence Bundle

Gateway (Governance Engine)

Technical terms.

Receipt Chain

Decision Receipt

Behavioral Drift Detection

Phantom Execution

Launch Gate

Merkle Checkpoint

Leaf Hash

Sealed Hash

Subject

Tool Authorization

Verification: six checks, seven with a pinned issuer key

Two-Process Separation

Adjacent technologies.

Action Risk vs Output Risk

Zero-Knowledge Proof(ZKP)

Trusted Execution Environment(TEE)

Confidential Computing

Cryptographic primitives.

Ed25519

ML-DSA-65

Hybrid Composite Signatures

SHA-256

BLAKE2b-256

JSON Canonicalization (JCS-lineage)

Merkle Trees

Related pages.

Glossary.

Core concepts.

Agentic AI Governance

AI Agent Security

Three-Part Governance

Runtime Governance

Attested Governance Artifact(AGA)

Policy Artifact

Evidence Bundle

Gateway (Governance Engine)

Technical terms.

Receipt Chain

Decision Receipt

Behavioral Drift Detection

Phantom Execution

Launch Gate

Merkle Checkpoint

Leaf Hash

Sealed Hash

Subject

Tool Authorization

Verification: six checks, seven with a pinned issuer key

Two-Process Separation

Adjacent techno­logies.

Action Risk vs Output Risk

Zero-Knowledge Proof(ZKP)

Trusted Execution Environment(TEE)

Confidential Computing

Crypto­graphic primitives.

Ed25519

ML-DSA-65

Hybrid Composite Signatures

SHA-256

BLAKE2b-256

JSON Canonical­ization (JCS-lineage)

Merkle Trees

Related pages.

Adjacent technologies.

Cryptographic primitives.

JSON Canonicalization (JCS-lineage)