Control Mappings
How Cryptographic Runtime Governance maps to NIST, SSDF, and CoSAI controls.
Important: References to NIST, CISA, SLSA, and other standards are informational mappings to support governance discussions. This is not certification, endorsement, or compliance advice.
Attested Intelligence™ is not affiliated with, approved by, or endorsed by NIST, CISA, or any standards body. These mappings are provided as a conceptual alignment guide only. Actual compliance depends on implementation context and auditor assessment.
Receipt Specification
Governance Receipt (15 fields)
| Field | Type | Description |
|---|---|---|
| receipt_id | string | Unique receipt identifier (UUID) |
| receipt_version | string | Schema version ("1.0") |
| algorithm | string | Signing algorithm identifier |
| timestamp | string | ISO 8601 UTC timestamp |
| request_id | string | number | null | MCP request identifier (type preserved) |
| method | string | MCP method ("tools/call") |
| tool_name | string | Name of the tool being called |
| decision | string | PERMITTED or DENIED |
| reason | string | Human-readable decision rationale |
| policy_reference | string | SHA-256 hash of policy configuration |
| arguments_hash | string | SHA-256 of canonical arguments (tri-state) |
| previous_receipt_hash | string | Chain link to previous receipt |
| gateway_id | string | Signing gateway identifier |
| signature | string | Ed25519 signature (128 hex chars) |
| public_key | string | Ed25519 public key (64 hex chars) |
Canonicalization (RFC 8785)
All JSON serialization uses RFC 8785 JSON Canonicalization Scheme (JCS):
- Object keys sorted by Unicode code point order
- No whitespace outside string values
- ECMAScript Number.toString() for number serialization (1.0 becomes 1)
- Negative zero normalizes to positive zero
- Array element order preserved (not sorted)
Signing and Chain Linking
SigningDigest: Canonical JSON of receipt WITHOUT the signature field. Ed25519 signature computed over these bytes.
ChainDigest: SHA-256 of canonical JSON of receipt WITH the signature field. Used as previous_receipt_hash in the next receipt.
arguments_hash tri-state: absent arguments = empty string, empty object = SHA-256("{}"), content = SHA-256(canonicalize(arguments)).
Evidence Bundle Format
An evidence bundle packages a receipt chain with Merkle proofs for offline verification:
| Field | Description |
|---|---|
| schema_version | Bundle format version ("1.0") |
| bundle_id | Unique bundle identifier (UUID) |
| algorithm | Algorithm suite ("Ed25519-SHA256-JCS") |
| generated_at | ISO 8601 bundle creation timestamp |
| gateway_id | Signing gateway identifier |
| public_key | Ed25519 public key (64 hex chars) |
| policy_reference | SHA-256 of policy configuration |
| receipts | Ordered array of GovernanceReceipt objects |
| merkle_root | SHA-256 Merkle root of receipt leaf hashes |
| merkle_proofs | Inclusion proofs for each receipt |
| offline_capable | Boolean (always true) |
Five-Step Verification
Verify bundle and all receipts use "Ed25519-SHA256-JCS". Fail closed on unknown algorithms.
For each receipt: remove signature field, canonicalize, Ed25519 verify against public_key.
First receipt: previous_receipt_hash = "". Each subsequent: previous_receipt_hash = SHA-256(canonical(prev receipt WITH signature)).
Walk each proof from leaf to root via sibling hashes. Constant-time compare computed root to bundle merkle_root.
Proof count = receipt count. Each proof's leaf_hash = SHA-256(canonical(receipt WITH signature)). Leaf indices sequential.
Algorithm Identifiers
| ID | Signature | Hash | Canonicalization |
|---|---|---|---|
| Ed25519-SHA256-JCS | Ed25519 (64-byte signature) | SHA-256 (32-byte digest) | RFC 8785 JCS |
Additional algorithm suites may be defined in future versions. Verifiers must reject unknown algorithm identifiers (fail closed).
Cross-Language Conformance
Three verified implementations ensure interoperability:
TypeScript
MCP Gateway (Cloudflare Workers)
94 tests
Python
SDK (PyNaCl)
97 tests
Go
Verifier CLI
cross-verify all bundles
30 shared test vectors across 9 categories ensure byte-for-byte canonical output, identical signatures, and matching Merkle roots.
NIST AI RMF 1.0
AI Risk Management Framework (NIST AI 100-1)
| Control | Requirement | Mechanism | Evidence Field(s) | Verification Step |
|---|---|---|---|---|
| GOVERN 1.1 | Policies established | Policy reference hash in governance receipts | receipt.policy_reference | Verify policy_reference matches expected configuration hash |
| GOVERN 1.3 | Oversight mechanisms | Signed governance receipt chain | receipt.decision, receipt.previous_receipt_hash | Verify receipt signatures, validate chain continuity |
| MAP 1.5 | Risk documented | Evidence bundle with Merkle root commitment | bundle.merkle_root, bundle.policy_reference | Verify Merkle proofs, confirm bundle consistency |
| MAP 3.1 | Benefits/costs assessed | Receipt chain analysis (PERMITTED vs DENIED ratios) | receipt.decision, receipt.reason | Count decisions by type, analyze denial reasons |
| MEASURE 2.3 | Effectiveness tracked | Timestamped receipt chain with tool-level decisions | receipt.tool_name, receipt.decision, receipt.timestamp | Verify receipt signatures, analyze decision patterns over time |
| MEASURE 2.6 | Feedback incorporated | Policy reference versioning across bundles | bundle.policy_reference (changes across bundle versions) | Compare policy_reference across sequential bundles |
| MANAGE 2.4 | Incidents documented | DENIED receipts with reason codes | receipt.decision: DENIED, receipt.reason | Filter denied receipts, verify signatures, analyze reasons |
| MANAGE 4.1 | Risk response deployed | Evidence of denied tool calls | receipt.decision: DENIED, receipt.tool_name | Verify denial receipts exist for high-risk tools |
NIST SSDF
Secure Software Development Framework (SP 800-218)
| Control | Requirement | Mechanism | Evidence Field(s) | Verification Step |
|---|---|---|---|---|
| PO.1.1 | Security requirements defined | Policy reference hash embedded in every receipt | receipt.policy_reference | Verify policy_reference is consistent across receipt chain |
| PO.3.2 | Roles and responsibilities | Ed25519 public key binding per gateway | receipt.public_key, bundle.public_key | Verify public_key matches authorized gateway |
| PS.1.1 | Software protected | Signed receipt chain with tamper detection | receipt.signature, receipt.previous_receipt_hash | Verify chain integrity, detect any modification |
| PS.2.1 | Software integrity verified | Bundle verification (5-step process) | verification_result.overall_valid | Run offline verifier, confirm all 5 steps pass |
| PW.4.4 | Cryptographic practices | Ed25519 signatures, SHA-256 hashing, RFC 8785 JCS | receipt.algorithm: Ed25519-SHA256-JCS | Verify all signatures using declared algorithm |
| PW.8.1 | Testing and verification | Cross-language test vectors (30 vectors, 3 implementations) | Test vector conformance across Python, TypeScript, Go | Run cross-language test suite, confirm all vectors pass |
| RV.1.1 | Vulnerabilities identified | Receipt chain analysis for anomalous patterns | receipt.decision: DENIED, receipt.reason | Analyze denied receipts for security-relevant patterns |
| RV.3.3 | Root cause analyzed | Receipt chain forensics with timestamps | Full receipt chain with timestamps and reasons | Reconstruct event timeline from chain |
NIST SP 800-53 Rev. 5
Security and Privacy Controls (Selected)
| Control | Requirement | Mechanism | Evidence Field(s) | Verification Step |
|---|---|---|---|---|
| AU-2 | Event Logging | Governance receipt per tool call decision | receipt.tool_name, receipt.decision, receipt.timestamp | Verify all tool calls have corresponding receipts |
| AU-9 | Audit Information Protection | Ed25519 signed, hash-chained receipts | receipt.previous_receipt_hash, receipt.signature | Verify chain integrity, detect tampering |
| AU-10 | Non-repudiation | Ed25519 signatures on all receipts | receipt.signature, receipt.public_key | Verify signatures against published gateway key |
| CM-2 | Baseline Configuration | Policy reference hash in receipt chain | receipt.policy_reference, bundle.policy_reference | Verify policy_reference is consistent and expected |
| CM-3 | Configuration Change Control | Policy reference tracking across bundle versions | bundle.policy_reference (compare across versions) | Detect policy_reference changes between bundles |
| SI-4 | System Monitoring | Continuous receipt generation for all tool calls | receipt.timestamp, receipt.tool_name | Verify receipt timestamps show continuous monitoring |
| SI-7 | Software Integrity | Bundle Merkle root and receipt chain integrity | bundle.merkle_root, merkle_proofs | Verify Merkle proofs, confirm bundle consistency |
| SA-10 | Developer Configuration Management | Cross-language test vector conformance | 30 test vectors, 3 verified implementations | Run cross-language test suite, confirm all pass |
CoSAI MCP Security Threat Coverage
12/12Coalition for Secure AI (CoSAI), OASIS Open Project, January 2026
The CoSAI MCP Security whitepaper identifies 12 core threat categories and nearly 40 distinct threats specific to Model Context Protocol deployments. AGA maps to mechanisms in all 12 categories through its governance architecture.
| ID | Threat Category | Domain | AGA Governance Mechanism |
|---|---|---|---|
| T1 | Improper Authentication | Identity & Access | Ed25519 receipt signatures, gateway public key binding, algorithm fail-closed verification |
| T2 | Missing Access Control | Identity & Access | Gateway-level tool allowlist/denylist, PERMITTED/DENIED receipts with policy reference |
| T3 | Input Validation Failures | Input Handling | Arguments hash in receipts (SHA-256 of canonical tool arguments), tamper-evident chain |
| T4 | Data/Control Boundary Failures | Input Handling | Policy-driven tool governance (permitted tools, denied tools), signed decision records |
| T5 | Inadequate Data Protection | Data & Code | Arguments stored as SHA-256 hash only (not plaintext), Merkle proof for selective disclosure |
| T6 | Missing Integrity Controls | Data & Code | SHA-256 hash chaining, Ed25519 signatures, Merkle tree binding, offline verification |
| T7 | Session/Transport Security | Network & Transport | Ed25519 signed receipts with timestamps, receipt chain continuity, bundle-level Merkle root |
| T8 | Network Isolation Failures | Network & Transport | Offline-capable evidence bundles, no external service dependencies for verification |
| T9 | Trust Boundary Failures | Trust & Design | Policy reference committed in receipts, gateway as trust boundary, decisions recorded not delegated |
| T10 | Resource Management | Trust & Design | Per-tool decision tracking, receipt chain provides complete audit trail of tool call volume |
| T11 | Supply Chain Failures | Operational | Cross-language test vectors (30 vectors), three verified implementations, deterministic signatures |
| T12 | Insufficient Observability | Operational | Signed receipts, tamper-evident continuity chain, Merkle anchoring, offline evidence bundles |
NSA AI/ML Supply Chain Risks and Mitigations
Joint Cybersecurity Information Sheet (March 2026)
| NSA Recommendation | AGA Mechanism | Claim/Embodiment |
|---|---|---|
| Verify data integrity with checksums, hashes, digital signatures | Subject Identifier (bytes commitment + metadata commitment) | Claim 1(b) |
| Maintain verified model registry with integrity checks | Sealed Policy Artifact with immutable reference hash | Claim 1(d) |
| Use lineage tracking for data provenance | Continuity Chain with structural metadata linking | Claim 3 |
| Perform initial and periodic performance testing | Continuous measurement at policy-defined cadence | Claim 1(f), Embodiment 1-10 |
| Maintain SBOM documentation | SBOM digest measurement and sealed verification | Claim 7, Embodiment 5 |
| Cryptographic signing across model lifecycle | Ed25519 signatures on artifacts, receipts, and chain events | Claim 1(d), Claim 3(b) |
| Use trusted computing environment with Zero Trust | Portal runtime boundary, agent holds no signing keys | Claim 1(e), Section F |
| Quarantine and test externally sourced components | Launch Gate validation, blocks execution if initial hash fails | Claim 1(e)(ii) |
The NSA guidance recommends these measures as best practices. AGA provides the cryptographic enforcement mechanism that makes them operationally verifiable.
EU AI Act
High-risk AI system requirements (enforcement: August 2, 2026)
| EU AI Act Article | Requirement | AGA Mechanism | Evidence |
|---|---|---|---|
| Article 9 | Risk management system | Policy Artifact encodes risk parameters and enforcement thresholds | policy_reference, enforcement_parameters |
| Article 12 | Recordkeeping | Continuity Chain with signed receipts for every enforcement event | Full receipt chain with timestamps |
| Article 13 | Transparency | Evidence Bundles exportable for third-party audit | bundle_manifest, Merkle proofs |
| Article 14 | Human oversight | Enforcement actions (TERMINATE, QUARANTINE, SAFE_STATE) with signed receipts | receipt.decision.action |
| Article 15 | Accuracy, robustness, cybersecurity | Continuous drift detection against sealed integrity baselines | MEASUREMENT_OK / DRIFT_DETECTED receipts |
These mappings describe architectural alignment, not legal compliance advice. Actual compliance depends on implementation context and assessment by qualified legal counsel.
Evidence Artifact Summary
Policy Artifact provides:
- Governance policy establishment (GOVERN)
- Baseline configuration (CM-2)
- Security requirements (PO.1.1)
Enforcement Receipt provides:
- Event logging (AU-2)
- Non-repudiation (AU-10)
- Incident documentation (MANAGE)
Continuity Chain provides:
- Audit protection (AU-9)
- Change control (CM-3)
- Effectiveness tracking (MEASURE)
Evidence Bundle provides:
- Offline verification capability
- Third-party audit support
- Portable evidence packaging