Control Framework Mappings

A machine-readable mapping from Permit v1 fields and audit-export-bundle artifacts to specific control IDs across 15 published frameworks. Use this when you need to answer “which Keel evidence can support which control evidence requirement?”

The canonical artifact lives in the open Permit Spec repository:

JSON: keelapi/keel-permit/mappings/control-frameworks.schema-mapping.json
Verification methodology + framing-discipline guardrails: keelapi/keel-permit/mappings/README.md

What’s mapped

Framework	Coverage	Permit fit
California Civil Code §1798.105(d)	(d)(2) security/integrity carve-out; (d)(8) legal-obligation carve-out	Permit timestamp + retention support deletion-exception defense
11 CCR §7150 / §7152 / §7155 (CPPA ADMT regulations)	Risk Assessment Requirements effective Jan 1, 2026	Permit decision + decision_details provide direct support for §7152(a)(3)(G); §7152(a)(6)(A)(iv) via policy_id versioning
EU AI Act Article 12 + 26(6)	High-risk AI logging + deployer ≥6-month retention	Hash chain + Production 180d retention exceeds 26(6) floor
GDPR Article 17(3)(b)	Legal-obligation deletion carve-out	Permit retention scoped to legal/regulatory requirement
AICPA SOC 2 Trust Services Criteria (2017 with Revised Points of Focus 2022)	All 33 common criteria CC1.1 through CC9.2	Hash chain + signed exports map to CC7.2 (anomaly monitoring + change detection); CC8.1 (change management) via policy versioning; CC9 (risk mitigation) via budgets
NIST AI RMF 1.0	Functions GOVERN, MAP, MEASURE, MANAGE with subcategories	14 subcategory mappings; strongest under GOVERN 1.4, MAP 1.1, MEASURE 2.7
ISO/IEC 42001:2023	Clauses 4-10 + Clause 3 definitions + Annex A controls	Clause 9 (Performance evaluation) + Annex A.6.2.8 (AI-System Recording of Event Logs) are the strongest fits — Keel substrate IS this control
OWASP Top 10 for LLM Applications (2025)	LLM01:2025 through LLM10:2025	9 item mappings; strongest under LLM06 (Excessive Agency) — Permit is the pre-execution authorization record for governed agent actions routed through Keel
MITRE ATLAS	14 tactics + ~50 techniques	13 technique mappings concentrated in AI Model Access, Execution, Exfiltration, Impact tactics
OWASP API Security Top 10 (2023)	API1:2023 through API10:2023	8 item mappings; API4 (Unrestricted Resource Consumption) and API5 (Broken Function Level Authorization) are the strongest evidence-support fits
OWASP ASVS v5.0.0	All 17 chapters	6 chapter mappings under V4, V8, V11, V13, V14, V16
FedRAMP / NIST SP 800-53 Rev 5	AU, AC, CM, CA, IR, SI, SC families	23 control mappings; AU family is the strongest fit (AU-9 Protection of Audit Information, AU-10 Non-repudiation, AU-12 Audit Record Generation)
CIS Critical Security Controls v8.1	All 18 controls	7 control mappings; Control 8 (Audit Log Management) is the strongest fit
PCI DSS v4.0.1	All 12 requirements	4 mappings narrowly scoped to AI workloads that touch a customer’s Cardholder Data Environment; Requirement 10 (Log and monitor) is the primary fit
AIUC-1 (Q3-2026 edition)	50 requirements, scoped per agent through an auditor-signed Statement of Applicability	4 control mappings; E015 (agent activity logging) is the strongest fit, plus B006.3’s pre-execution hook component, D003 (restrict unsafe tool calls), and A008.3 (secure credential storage). Evidence support only — certification is granted by an accredited auditor, never by a tool

What is verified vs draft

Four verification tiers, distinguished in the JSON’s verification_status block:

Verbatim verified (20 entries) — control IDs and titles fetched directly from an authoritative source on 2026-05-10 (AICPA TSP Section 100 PDF, iTeh ISO/IEC publication preview, NIST 800-53 Rev 5 catalog, OWASP/MITRE/PCI SSC publications, etc.).
Verbatim verified (pre-2026-05-10), 2 entries — EU AI Act Art 26(6) and GDPR Art 17(3)(b), verified in earlier work.
Two-source corroborated, 1 entry — ISO/IEC 42001:2023 individual Annex A control titles (ISMS.online + Mindsetcyber agree on all 38 IDs and semantic content; differ only on stylistic conventions). Exact verbatim typography remains medium-confidence pending the paywalled official Annex A pages.
Partially verified, 1 framework (AIUC-1, added 2026-08-13) — the A008.3, B006.3, D003, and D004 control titles were fetched verbatim from the AIUC-1 evidence catalog on 2026-08-13, along with the scoping facts (50 requirements; auditor-signed Statement of Applicability). The E015 series is corroborated from secondary sources only and is labelled as unverified everywhere it appears in the JSON. In particular, no AIUC-authored source confirms the sub-control decimals (E015.2, E015.4) or their classification — cite the logging fit as E015, and do not quote the sub-control IDs as verbatim.

What Keel is NOT — important framing

Several of the frameworks mapped above have certification/authorization regimes. Keel API, Inc. is NOT certified or authorized under any of them:

Keel is NOT FedRAMP authorized — no JAB Provisional Authorization, no Agency ATO, not listed on the FedRAMP Marketplace. The FedRAMP mapping describes how Keel-produced evidence can support a customer’s NIST 800-53 control implementations within the customer’s existing FedRAMP-authorized boundary.
Keel is NOT PCI-DSS validated — no Attestation of Compliance, no Report on Compliance. The PCI mapping applies narrowly to AI workloads that touch a customer’s Cardholder Data Environment.
Keel is NOT SOC 2 attested — controls are implemented and reviewable today; third-party SOC 2 Type II attestation engagement follows commercial validation. The SOC 2 mapping describes which Trust Services Criteria the Keel substrate supports.
Keel is NOT ISO/IEC 42001 certified — same posture.
Keel is NOT AIUC-1 certified, and Keel does not make an agent AIUC-1 compliant. AIUC-1 certification is per-agent, scoped through an auditor-signed Statement of Applicability, and granted by an accredited auditor — not by any tool. Keel does NOT satisfy D004 (third-party testing of tool calls), which requires qualified third-party assessors performing assessments at least every quarter; Keel’s own conformance tests do not count toward it. AIUC-1 alignment is also not transitive evidence of NIST, ISO, MITRE, or OWASP compliance — their crosswalks identify overlap only.

The mappings describe how Keel substrate supports a customer’s compliance posture, not Keel-side authorization, certification status, legal advice, audit opinion, or a statement that any customer satisfies a control. The customer and its assessor determine sufficiency.

Explicit non-mappings

The JSON also documents 21 explicit non-mappings — controls and frameworks that Keel substrate does NOT address — so over-claim risk is bounded:

13 of 20 NIST 800-53 control families (Physical Protection, Maintenance, Personnel Security, etc.) are entirely customer responsibility, not Keel substrate
12 of 18 CIS Controls (asset inventory, malware defense, network monitoring, training, penetration testing, etc.) are entirely customer responsibility
8 of 12 PCI DSS requirements are out-of-scope for Permit substrate
API7 (SSRF) and API8 (Security Misconfiguration) in OWASP API Top 10 are explicitly not addressed
4 of 14 MITRE ATLAS tactics (Reconnaissance, Discovery, Persistence, Lateral Movement, C2) are SOC/EDR responsibility, not Permit scope
AIUC-1 D004 (third-party testing of tool calls) requires qualified third-party assessors quarterly — not satisfied by Keel’s own conformance tests
AIUC-1 content-safety, B010 secure-code-generation, and red-teaming controls are outside Permit substrate, as are the sandbox, container, filesystem/network, and tool-definition-integrity components of B006.3 (only its pre-execution hook component is mapped)

How to use this

For an auditor or procurement reviewer:

Open the JSON artifact in the keel-permit repo.
Look up the specific control ID you need to evidence (e.g., NIST 800-53 AU-9, SOC 2 CC7.2, ISO/IEC 42001:2023 A.6.2.8).
Read the permit_evidence and evidence_type fields (necessary, direct_support, or partial).
Verify the cited Permit fields against your own audit export — fields are documented in Permit v1 and Closure v2 .

For a developer integrating Keel:

The mapping tells you which Permit fields are evidence-load-bearing for your customer’s compliance program.
Wire-format guarantees in the spec mean these field semantics are stable across Permit v1.

Independent Verification Overview — the verifier’s claim and trust boundary
Three Trust-Root Channels — how verifiers obtain Keel’s public keys
Timestamp Authority Scope — what RFC 3161 timestamps witness and don’t witness
Tampering Detection Matrix — failure codes a verifier emits

The framework mapping artifact is updated whenever a framework releases a new revision or a regulation moves from proposed to adopted. The AIUC-1 mapping is pinned to the Q3-2026 edition and needs reverification each quarter, because AIUC-1 revises quarterly. Last updated: 2026-08-13.