Open control profiles: reference controls for AI systems.

Several public schemes already say what an AI system should control. The profiles here do not replace any of them: they are an open implementation layer, the controls an engineer builds and the evidence they leave, mapped to those schemes where the mapping has been checked.

• AIUC-1, a standard of the Artificial Intelligence Underwriting Company for AI agents: 53 requirements in six domains, two of them now marked retired, with certificates issued by AIUC on the report of an accredited auditor.
• ISO/IEC 42001:2023, the AI management system standard, whose Annex A lists reference controls.
• The NIST AI Risk Management Framework, organised in the Govern, Map, Measure and Manage functions and their subcategories.
• The CSA AI Controls Matrix of the Cloud Security Alliance.

Each control lists its mappings, and each profile page gathers them in one table. An AIUC-1 id appears only where the requirement's public text, read on its own page, plainly covers the same objective; the mapping is this project's reading, not AIUC's. This project is not affiliated with AIUC, ISO, NIST or the Cloud Security Alliance, holds no certificate from any of them, and following a profile here is not conformity with any of their schemes. See also the frameworks and the crosswalk.

Browse the controls by framework in the controls crosswalk: for each obligation, clause or id, the controls that map to it, and for each profile, its controls with their ids per framework.

Public guidance from frontier developers and evaluators now uses the same terms for the environment around a model: OpenAI's account of third-party cyber evaluations (4 Aug 2026) speaks of an authorization boundary and of expectations for isolation, credential handling, monitoring and stop conditions, and Anthropic's guidance for external evaluation partners (31 Aug 2026) covers network isolation, keys kept outside the environment, configuration checked before every evaluation and monitoring that ends an out-of-scope run. The profiles cross-reference that guidance where it evidences a control; they are not derived from it, and no developer or evaluator has reviewed or endorsed them.

Every control is open for technical review. Pick one, check it against a system you run or know, and open the control review form on GitHub: say what is wrong or missing, with the evidence. Reviews, their answers and every change stay public.

• All controls as JSON: every control of every profile, in the envelope of the open data API.
• JSON Schema of the controls dataset: generated from the same registry.
• Control observation schema: the record a check of a control emits: control_id, subject, expected, observed, status, timestamp, evidence.
• Observation example: a filled record that validates against the schema.
• Observation template: the same fields in Markdown, with short guidance.
• Each profile page links every control as JSON, and the whole site's data is in the open data API and on the MCP server.