Control maps.
How Cryptographic Runtime Governance maps to six frameworks: NIST AI RMF, NIST SSDF, NIST SP 800-53, CoSAI MCP Security, the joint AI/ML supply chain guidance and the EU AI Act.
These are technical cross-references, not certification or a legal compliance assessment. As of September 28, 2026, NIST says AI RMF 1.0 is under revision. The mappings below identify the editions they use; no forthcoming revision is treated as final.
Filed public comments.
We participate in the open processes shaping how AI agent activity gets identified, authorized, and audited. The record below states what was filed and when, nothing more.
NIST NCCoE Concept Paper
Accelerating the Adoption of Software and AI Agent Identity and Authorization
Public comment filed March 4, 2026. The comment proposed a demonstration scenario for a governed AI agent in a simulated operational-technology environment, ending in an offline audit: a party with no network path to the originating system reaches a verdict on the agent's decision record using only a public key and the evidence bundle.
As filed on 2026-03-04, describing the architecture. Several capabilities it names are not in the published packages; see /trust.
NIST CAISI RFI
Security Considerations for Artificial Intelligence Agents (Docket NIST-2025-0035)
Public comment filed March 4, 2026, on the RFI published at 91 FR 698. The twelve-page comment recommended continuous runtime measurement producing signed receipts on a tamper-evident audit chain, verification tiers that scale with deployment consequence, and offline verifiability for agents operating in critical-infrastructure environments.
As filed on 2026-03-04, describing the architecture. Several capabilities it names are not in the published packages; see /trust.
Filing a public comment is participation in an open process. It does not imply that NIST or NCCoE received, reviewed, endorsed, or acted on the submission, and no engagement should be inferred from its presence here.
Six proposed minimum criteria.
Six minimum criteria the foundational paper proposes for standardizing the Attested Governance category. We offer them as a starting point for the community to refine, and we welcome other designs that satisfy them. Source: “Attested Governance: Runtime Integrity for Autonomous Systems”, §6.4.
Sealed reference states
PartialCriterionProduce cryptographically sealed, signature-bound artifacts binding subject identity, policy reference, and governance parameters, where any modification made without the issuer's key is detectable against the issuer's pinned key.
In AGAPartial. In aga-mcp-server, attest_subject mints an Ed25519-signed Policy Artifact with a composite hash over subject identity (bytes commitment + canonicalized metadata), policy reference, and governance parameters. Without the issuer's key, any change to it invalidates the signature, which a check against the issuer's pinned key catches. In the published package the issuer key is generated per process, so no issuer key survives a restart to pin (a delegated child artifact from delegate_to_subagent checks only against that process's issuer_public_key), and a pinned-issuer check ships in the request-access Go runtime. In 3.6.0 through 3.6.2 the governed MCP client can call attest_subject itself, so the subject can re-seal its own reference. aga-proxy uses a JSON policy file; each receipt signs the SHA-256 of its canonical JSON.
Paper §6.4 C1
Continuous runtime measurement
PartialCriterionMeasure runtime state against the sealed reference at a policy-specified cadence, producing a signed cryptographic commitment for each measurement.
In AGAPartial. The published aga-mcp-server measures on request, over content the caller supplies, and signs each measurement. Its artifact carries a cadence field (1000 ms by default) that nothing in the published package reads. Scheduled measurement exists only in the private reference runtime (evaluation access).
Paper §6.4 C2
Tiered verification levels
SpecifiedCriterionSupport tiered verification calibrated to deployment consequence, with the tier expressed in receipt metadata so relying parties can apply appropriate confidence thresholds.
In AGABronze, Silver, and Gold tiers are specified. Verification of Merkle-checkpointed evidence bundles is implemented today. The explicit tier-metadata fields and the tier-specific components (external timestamps, HSM isolation, TEE attestation) remain specified architecture; they are not instantiated in the published packages.
Paper §6.4 C3
Offline-verifiable evidence bundles
ImplementedCriterionProduce evidence bundles verifiable using standard cryptographic primitives and the issuing authority's public key alone, without network connectivity to the producing system.
In AGAEvidence bundles verify with Ed25519, SHA-256, and the issuing authority's public key, with no network connectivity to the producing system. The browser verifier runs client-side; its logic mirrors the open-source aga-verify CLI, which is the one to audit.
Paper §6.4 C4
Standardized artifact formats
ImplementedCriterionUse machine-parseable, cryptographically interoperable artifact formats that a common verifier procedure can validate identically across multiple independent implementations.
In AGAJCS-lineage JSON canonicalization, Ed25519 (RFC 8032) and SHA-256. Six verifier configurations across three toolchains (JavaScript, Go, Python) render identical verdicts on 54 of the 61 cross-stack conformance cases, as the harness feeds them (it re-serializes the parsed cases, so the leaf_index case spelled 0.0 runs as an integer; see /spec). The remaining 7 cases are raw files, and the in-server engine receives parsed objects rather than file bytes, so those 7 are verified by the other five configurations; the spec's canonical vectors pin byte-for-byte canonical output. Outside the corpus the verifiers differ in both directions (/security).
Paper §6.4 C5
Policy-constrained disclosure with cryptographic evidence
PartialCriterionSupport structured disclosure of governed evidence under policy constraint, producing cryptographic evidence of what was disclosed, what was withheld, under what policy version, and with what rationale.
In AGAPartial. aga-mcp-server ships a demonstration disclosure taxonomy with PROOF_ONLY, REVEAL_MIN and REVEAL_FULL modes and signed substitution receipts recording the original claim id, substitute id, policy version and reason code. In 3.6.0 through 3.6.2 REVEAL_MIN returns the value unmodified, the default inference-risk lists are empty, and disclosure outcomes are not in the exported evidence bundle.
Paper §6.4 C6
Receipt format.
The governance receipt is a 15-field record, canonicalized with a JCS-lineage scheme, Ed25519-signed without its signature field, and hash-chained to its predecessor. Receipts package into an evidence bundle with Merkle proofs that a conformant verifier validates in six checks, seven with a pinned issuer key. The full schema, canonicalization rules, algorithm identifiers, and cross-language conformance results live on the specification page.
15
Receipt fields
6
Verification checks
61
Classical cross-stack cases
+28
Post-quantum vectors
NIST AI RMF 1.0
AI Risk Management Framework (NIST AI 100-1)
Each requirement is quoted from NIST AI 100-1. Only subcategories for which a mechanism shipped in 3.6.0 through 3.6.2 supplies evidence are listed; the mechanism does not by itself achieve the outcome, and every other subcategory is not addressed.
| Control | Requirement | Mechanism | Evidence Field(s) | Verification Step |
|---|---|---|---|---|
| GOVERN 1.4 | The risk management process and its outcomes are established through transparent policies, procedures, and other controls based on organizational risk priorities. | A policy applied at the tool-call boundary; aga-proxy signs the SHA-256 of its canonical JSON into every receipt | receipt.policy_reference (aga-proxy; empty in aga-mcp-server 3.6.0 through 3.6.2), receipt.decision | Verify receipt signatures against the pinned key; canonicalize the policy you were given (derivePolicyReference in @attested-intelligence/aga-mcp-server/sep) and confirm policy_reference equals its SHA-256 |
| MEASURE 2.8 | Risks associated with transparency and accountability – as identified in the MAP function – are examined and documented. | A signed, hash-chained record of each governed tool-call decision, which a reviewer examining accountability risks can verify offline against a pinned key | receipt.decision, receipt.reason, checkpoint | Run aga-verify offline with the gateway key pinned out of band |
| MEASURE 3.1 | Approaches, personnel, and documentation are in place to regularly identify and track existing, unanticipated, and emergent AI risks based on factors such as intended and actual performance in deployed contexts. | DENIED receipts record attempted tool calls outside policy in the deployed system; aga-proxy's default profile, permissive, denies nothing on policy grounds; policy denial needs --profile standard or restrictive, or a --policy file in allowlist or denylist mode | receipt.decision: DENIED, receipt.reason, receipt.tool_name, receipt.timestamp | Verify signatures and chain, then filter DENIED receipts; a verifier cannot confirm every call was recorded |
| MANAGE 4.1 | Post-deployment AI system monitoring plans are implemented, including mechanisms for capturing and evaluating input from users and other relevant AI actors, appeal and override, decommissioning, incident response, recovery, and change management. | The exported evidence bundle, a post-deployment record usable in incident response | receipts, Merkle proofs, signed checkpoint | Verify signatures, chain and checkpoint offline |
| MANAGE 4.3 | Incidents and errors are communicated to relevant AI actors, including affected communities. Processes for tracking, responding to, and recovering from incidents and errors are followed and documented. | A bundle a vendor can hand to an affected party, who checks it without access to the vendor's systems | evidence bundle and the gateway key pinned in advance | The recipient runs aga-verify offline |
What each artifact provides
Policy binding provides:
- Policy identity in each aga-proxy receipt (GOVERN 1.4)
- The policy's canonical JSON hash in each aga-proxy receipt, as a reference for one configuration item (input to a CM-2 baseline)
- Evidence that aga-proxy's applied policy changed, as a new policy hash (for CM-3 review)
Governance Receipt provides:
- Event logging for governed calls (AU-2)
- Signatures bound to the gateway key, not to a person (AU-10)
- Evidence for incident documentation (MANAGE 4.3)
Receipt chain provides:
- Cryptographic integrity protection of audit records (AU-9(3))
- A record of denied tool calls, for risk tracking in deployment (MEASURE 3.1)
- Integrity of the record itself, not of the software (SI-7)
Evidence Bundle provides:
- Offline verification capability
- A post-deployment record usable in incident response (MANAGE 4.1)
- Portable evidence packaging