ISO/IEC 42001:2023 · NIST AI RMF 1.0
Control mapping: ISO/IEC 42001 and NIST AI RMF
What a signed receipt is evidence for, and what it is not.
Permission Protocol implements specific controls; it is not a conformance target. The relationship is the one an MFA provider has to SOC 2: one control inside your program, not the program. Each row below carries exactly one status, Implements, Provides evidence for, or Not addressed, defined in the legend. This page is a sibling of the AIUC-1 mapping and the Agentic Trust Framework mapping. Weighing whether to build this evidence layer yourself? Start with build or buy.
About this mapping
ISO/IEC 42001:2023 is cited by Annex A control identifier and title, with a one-line paraphrase in our own words; the standard's text is copyrighted and is not reproduced here. NIST AI RMF 1.0 (NIST AI 100-1) is public domain, and each subcategory is quoted verbatim. Statuses were checked against the shipped code on 2026-09-08. Surfaces: MCP · CI/CD.
Permission Protocol performs the control for actions inside a gate, and a receipt proves it happened.
Permission Protocol does not perform the control. The receipt is an artifact an auditor can use as evidence toward it.
Outside Permission Protocol's scope. The row names what typically addresses it.
ISO/IEC 42001:2023 Annex A controls and management-system clauses
Identifier and title from the standard. Paraphrase and status are ours.
A.2.2AI policyAI policy
The organization documents a policy for how it develops and uses AI.
Your governance function writes the AI policy, usually tracked in a GRC platform. Permission Protocol enforces one consequence of it, which gated actions wait for a named human, and does not author the policy.
A.3.2AI roles and responsibilitiesAI roles and responsibilities
Roles and responsibilities for AI are defined and allocated.
The receipt for each gated action records the decider: the policy engine, or a human signer recorded as a role class (human or founder) on the execute lane. That is evidence a defined role decided, not a per-person identity record. Mapping roles to named people lives in your IAM and org chart.
A.5Assessing impacts of AI systems (A.5.2 to A.5.5)Assessing impacts of AI systems (A.5.2 to A.5.5)
The organization assesses what its AI systems could do to individuals, groups, and society.
Impact assessment is a governance deliverable owned by your risk function. Permission Protocol never judges whether an action is a good idea, only whether it was authorized.
A.6.2.5AI system deploymentAI system deployment
Deployment follows a defined plan and checks before the system goes live.
Scoped to the agent code to production gate. Deploy Gate holds an agent-authored merge until policy clears it or a named human signs, and the CI job verifies and redeems the signed receipt before the deploy proceeds. Permission Protocol performs the release-authorization step; deployment planning, rollback criteria and environment readiness are yours.
A.6.2.6AI system operation and monitoringAI system operation and monitoring
The organization defines how the AI system is run and watched once in use.
Kill-switch enforcement runs at the live choke point before any policy evaluation: a global freeze, agent pause or capability pause denies the next gated action, fail-closed, and issues a signed DENY receipt. That receipt is evidence the stop control fired. Monitoring of model behavior, drift and performance is not something Permission Protocol does.
A.6.2.8AI system recording of event logsAI system recording of event logs
Significant events across the AI system's life are logged.
Scoped to gated actions only. Each gated action issues an Ed25519-signed receipt recording the agent, action, input hash, decision, reason codes, policy version, decider and timestamp. The public receipt page and API re-run signature verification on every view, and a receipt altered after signing shows as unverified with the decider withheld. Actions that do not route through an MCP Guard or CI/CD gate produce no receipt; your platform logs cover those.
A.7Data for AI systems (A.7.2 to A.7.6)Data for AI systems (A.7.2 to A.7.6)
Data used to build and run AI systems is managed for quality, provenance and preparation.
Data governance lives in your data platform and DLP tooling. The PII/PHI export gate holds the release until a named human signs; it does not inspect or govern the data itself.
A.8.4Communication of incidentsCommunication of incidents
Incidents are reported to the parties who need to know.
Incident communication is owned by your incident response process and status page. A signed DENY receipt can be an input to that process; Permission Protocol does not notify affected parties.
A.9.2Processes for responsible use of AI systemsProcesses for responsible use of AI systems
Documented processes govern how AI systems are used.
The five gates (money out, agent code to production, production infrastructure mutations, PII/PHI export, identity changes) define which actions require a human signature and which policy clears. Receipts show that process ran on each gated action. Writing the broader responsible-use process is yours.
A.9.4Intended use of the AI systemIntended use of the AI system
AI systems are used only for their documented purpose.
A gate defines what the agent was authorized to do at that choke point, and the receipt binds the exact action and input hash to the decision. That is evidence the authorization scope was honored per gated action, not proof of intended use overall.
Clause 8.1Operational planning and controlOperational planning and control
Processes needed to meet AI requirements are planned, run and controlled.
Receipts are a controlled-operation artifact for the gated slice: each shows which policy version applied and who decided. Planning and control of the rest of your AI operation is outside Permission Protocol.
Clause 9.1Monitoring, measurement, analysis and evaluationMonitoring, measurement, analysis and evaluation
The organization decides what to monitor and measure, then evaluates the results.
Receipts are a measurable series, exportable through the receipts API: approvals, denials, policy clearances and kill-switch denials per gate over time. Permission Protocol does not define your metrics.
Clause 9.2Internal auditInternal audit
Internal audits check the management system at planned intervals.
An auditor can pull receipts for any period and verify each signature independently on the public receipt page or through the API. Receipts are the artifact; the audit programme is yours.
NIST AI RMF 1.0 subcategories
Subcategory text quoted verbatim from NIST AI 100-1. Status and the right-hand column are ours.
GOVERN 1.4“The risk management process and its outcomes are established through transparent policies, procedures, and other controls based on organizational risk priorities.”
Each gate is a transparent control with a named-signer requirement, and the receipt records the policy version that governed each gated action. The risk management process around the gates is yours.
GOVERN 1.5“Ongoing monitoring and periodic review of the risk management process and its outcomes are planned and organizational roles and responsibilities clearly defined, including determining the frequency of periodic review.”
Receipts give the periodic review a concrete input: which gated actions cleared, which held, which were denied, and who decided, per gate. Planning the review and setting its frequency is yours.
GOVERN 1.6“Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities.”
Permission Protocol keeps no inventory of agents or AI systems. Receipts carry an agent ID; an agent registry or your identity provider is where that ID resolves to an owner. Bring your registry.
GOVERN 3.2“Policies and procedures are in place to define and differentiate roles and responsibilities for human-AI configurations and oversight of AI systems.”
Scoped to gated actions. The gate is the human-AI configuration: policy clears the routine, a named human signs the consequential slice, and the receipt binds which class of decider resolved each gated action (policy engine, human, founder). Roles outside the gate remain your policy's job.
GOVERN 4.3“Organizational practices are in place to enable AI testing, identification of incidents, and information sharing.”
Narrowly. A signed DENY receipt records that a gated action was blocked, by which rule or kill switch, at what time: an incident-identification input and nothing more. Testing practices and information sharing are yours.
MAP 3.5“Processes for human oversight are defined, assessed, and documented in accordance with organizational policies from the GOVERN function.”
Scoped to gated actions. The gate is a defined, enforced human-oversight process: the action holds until a named human signs or policy clears it, and the receipt documents the outcome. Whether your gates match your GOVERN policies is an assessment you make.
MEASURE 2.8“Risks associated with transparency and accountability – as identified in the MAP function – are examined and documented.”
Receipts document accountability per gated action: who decided, under which policy version, with the decider bound inside the signature. Examining the transparency and accountability risks themselves is your risk function's work.
MANAGE 2.4“Mechanisms are in place and applied, and responsibilities are assigned and understood, to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use.”
Scoped to actions routed through Permission Protocol. Global freeze, agent pause and capability pause are checked at the live choke point before any policy evaluation. A hit denies the next gated action, fail-closed, and issues a signed DENY receipt. It stops agency through the gate, not the agent process; actions that never route through Permission Protocol are not covered.
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.”
Signed approve and deny receipts are the change-management and override record for gated actions after deployment. Monitoring plans, appeal, decommissioning and recovery are yours.
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.”
Communication with affected parties, response and recovery are owned by your incident response process. A DENY receipt can feed it; Permission Protocol does not run it.
The rows that make the page trustworthy
What Permission Protocol does not do.
- Agent registry or inventory. Bring your registry. Permission Protocol does not inventory agents; it signs the decisions your agents request. An agent registry or your identity provider holds the agent-to-owner record, and receipts carry the agent ID that resolves there.
- Impact assessment. Permission Protocol never judges whether an action is a good idea, only whether it was authorized. Your risk or governance function owns the assessment.
- Data controls. Data quality, provenance, schema validation and DLP live in your data platform and gateway. The PII/PHI export gate holds the release until a named human signs; it does not inspect the data.
- Organizational AI policy authoring. Your governance function writes the AI policy, usually tracked in a GRC platform. Permission Protocol enforces one consequence of it: which gated actions wait for a named human.
- Incident communication. Your incident response process and status page own communication with affected parties. A signed DENY receipt can be an input; Permission Protocol does not send the notice.
- Autonomy levels. Permission Protocol does not implement autonomy levels or automatic demotion. Demotion is a policy change you make, and the gate is where a demoted agent lands.
Attribution, precisely
Decider attribution on the execute lane is a role class (policy engine, human approver, founder) bound inside the signature, with the individual recorded on the approval record. Nothing on this page claims per-person identity attribution. Policy packs are not enforced server-side today; the policy engine that clears routine actions runs a fixed rule set, and threshold logic stays at the choke point during a pilot.
Receipt fields as audit evidence.
Field names from the Permission Receipt Standard, mapped to the question an auditor asks. See the receipt specification and a real signed receipt.
receiptIdWhich record is this?
Stable identifier; resolves on the public receipt page.
tenantIdWhich organization owns this evidence?
Injected by the gateway, never taken from the request body.
agentIdWhich agent requested the action?
Agent-lane identity. The registry that maps it to an owner is yours.
tool, operationWhat was the agent authorized to do?
The action class, for example github and create_pr.
inputHashWas the action that ran the one that was authorized?
SHA-256 of the canonical input. Recompute from the action and compare.
decisionWas the action cleared, held for a human, or blocked?
APPROVED, REQUIRES_APPROVAL or DENIED.
reasonCodesWas the action blocked, and by what?
Names the rule or kill switch, for example GLOBAL_FREEZE_ACTIVE or AGENT_PAUSED.
policyVersionWhich policy version governed the decision?
Recorded on each gated action, so decisions can be replayed against the rule set that applied.
approverDid policy decide, or a human?
policy, human or founder.
deciderId, deciderDisplayWho authorized this action?
Bound inside the signature. A role class on the execute lane: the policy engine, a human approver or the founder.
deciderAuthMethodThrough which credential lane did they decide?
session, api_key or policy. Policy means the deterministic engine cleared or denied it and no human approved.
attributionConfidenceHow strongly is the decision tied to its decider?
credentialed or heuristic. The receipt never claims certainty it does not have.
resolutionTypeWas this a one-time approval, a standing rule, or a denial?
allow_once, allow_always or deny.
scopeIs this production evidence or a demo?
production or demo, inside the signed payload, so a demo receipt cannot pass as production evidence.
createdAtWhen was the decision made?
ISO 8601, set by the server at decision time.
receiptSig, sigAlgWas the record altered after signing?
Ed25519 over the SHA-256 digest of the canonical bytes. Any edit to a signed field after signing fails verification.
receiptVersion, canonicalizationWhich signed field set does this signature cover?
jcs_v2 binds the decider fields; a verifier dispatches on these so old receipts verify under the rules they were signed with.
Standards we map to
Permission Protocol implements approval-gate controls and produces the evidence these frameworks ask for. It is not a conformance target, and this site does not claim conformance. The receipt format each mapping relies on is an open specification.
Walk the mapping with the founder.
Bring your assessor's control list. We go row by row, say which receipt fields answer which question, and say plainly where Permission Protocol does not help.