> Call POST /v1/check before a tool that writes. DENY means do not invoke the tool. For clean Markdown of any page, append .md to the page URL. For the complete index, fetch https://docs.withwrit.com/llms.txt. # ISO/IEC 42001 > How Writ supports an ISO/IEC 42001 AI management system: the Annex A controls Writ operates, and the evidence each one produces. # ISO/IEC 42001 ISO/IEC 42001 is a management system standard. It certifies an organization's AI governance: its AI policy, its named roles, its risk and impact processes, and the controls it operates, recorded in a Statement of Applicability drawn from Annex A. A product cannot be 42001 compliant, and Writ does not claim to be. What a product can do is operate specific controls and produce the records an assessor asks for. That is Writ's role. When your agents write to real systems, Writ checks every write against your policy before it happens, routes the sensitive ones to a named human sponsor, and keeps a tamper-evident record of every decision. The mapping below covers the Annex A controls Writ supports, what Writ does for each one, and the evidence it leaves behind. Controls Writ does not touch are listed at the end, because an honest Statement of Applicability needs both halves. ## The mapping | Annex A control | What it asks for | What Writ does | Evidence produced | | ------------------------------------------------- | -------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | A.2.2 AI policy | A documented AI policy, approved and applied | Your policy is expressed as machine-enforced rules per verb: ALLOW, DENY, or STEP_UP. Writ enforces the policy at the point of action instead of leaving it in a document. | The policy itself, versioned. Every receipt carries the `policyVersion` that decided it. | | A.3.2 AI roles and responsibilities | Named roles accountable for AI systems | Every agent acts under a named human sponsor. Sponsors grant, step up, and revoke. The kill switch and per-principal disable are sponsor actions, attributed to a person. | Receipts record `sponsorId`, `agentId`, and `principalId` on every action; revocations are receipts too. | | A.4.4 Tooling resources | Documentation of the tooling resources an AI system uses | `writ scan` inventories the write surface: every place an agent can mutate state, in code you run and in repos connected through the GitHub App, with a risk class (db, money, auth, email, fs, network) and score per site. | Scan manifests per repo and commit, with drift against the previous scan. | | A.5.2, A.5.4 Assessing impacts of AI systems | A process that assesses what an AI system can affect | Writ does not run your impact assessment. It supplies the technical input assessors usually lack: which writes exist, which move money or credentials, and which are ungated today. | The scan's risk profile: ungated sites ranked by class and score. | | A.6.2.5 AI system deployment | Control over how an AI system reaches operation | CI attestation manifests and the GitHub App gate what ships: scans run on push and pull request, and a per-installation fail threshold can turn the check run red when ungated writes pass your limit. | Check runs with findings, ungated count, Writ Score, and drift headline on the exact commit. | | A.6.2.6 AI system operation and monitoring | Monitoring of the AI system in operation | Live monitoring of agent behavior in production: a streaming feed of every decision, a DENY-only stream for the writes stopped, drift alerts when a new scan changes the write surface. | The live audit stream (SSE, SIEM-ready), the dashboard's action feed, and the Agent Action Report per period. | | A.6.2.8 AI system recording of event logs | Event logs recorded across the AI system life cycle | Every decision (ALLOW, DENY, STEP_UP, REVOKE) is written as a receipt in a tenant-specific, hash-chained audit log. Altering a stored receipt breaks the chain and is detectable on demand. | Receipts with `prevHash` and `chainHash`, verifiable via `./writ verify-chain` or `GET /v1/receipts/verify`. This is the same mechanism that supports NIST SP 800-53 AU-9; see [Audit log](/audit-log). | | A.8.4 Communication of incidents | A way to communicate AI incidents to interested parties | STEP_UP decisions page the sponsor by email with the verb, target, purpose, and receipt ID. DENY events stream to your SIEM in near real time. | Step-up notification emails (rate-limited per write), the DENY stream, and the receipts behind both. | | A.9.2 Processes for responsible use of AI systems | Documented processes for using AI systems responsibly | Responsible use is enforced, not just documented: an agent can only perform the verbs policy allows, for the purpose stated at check time, and anything marked STEP_UP needs a human grant before it proceeds. | Policy plus the complete decision record showing it was followed, action by action. | | A.9.4 Intended use of the AI system | The AI system is used as intended | Every check binds a verb, a target, and a declared purpose. Grants are purpose-bound: an approval for one purpose does not authorize another, and off-policy writes are denied before they happen. | Receipts record `verb`, `target`, and `purpose` for every attempted action, allowed or not. | | A.10.2 Allocating responsibilities | Responsibilities allocated across the AI value chain | The sponsor model allocates responsibility in the record itself: your organization owns the policy, a named sponsor owns each approval, and the agent's actions are attributed end to end. Third-party and supplier agents are gated by the same checks. | Attribution fields on every receipt, plus per-agent and per-sponsor reporting. | ## What Writ does not cover Annex A also asks for things no enforcement tool can do for you. Writ does not write your AI policy (A.2), run your impact assessments (A.5), govern your training or operational data (A.7: data quality, provenance, preparation), or manage your supplier contracts (A.10.3, A.10.4). Those stay with your governance program. Writ's job starts where that program meets running systems: the moment an agent acts. ## Using this in your Statement of Applicability For each control above, Writ is a supporting control inside your AI management system, not the system itself. Your assessor determines applicability and compliance for your deployment, the same as with any control tooling. What Writ changes is the quality of the evidence: instead of reconstructing agent behavior from application logs after the fact, you hand the assessor a complete, tamper-evident record of what your agents attempted, what policy decided, and which human approved the rest.