Open control profiles: reference controls for AI systems.
Draft control specifications for AI systems, open for technical review: what each control requires, where it is enforced, how a third party would verify it and the evidence it leaves, with a JSON version and an observation schema. Illustrative, not a claim of conformity.
What a control profile is.
A control profile is a versioned set of reference controls for one kind of system: the environment a model or agent is evaluated in, or an agent acting in production. Each control is anchored to a layer of the five-layer stack and to the patterns that implement it, and it states the evidence it leaves in a shape a machine can read.
The profiles are draft control specifications, written in the open and licensed CC BY 4.0. Every control keeps a stable id, every change is in the changelog, and nothing is marked reviewed until a named reviewer has reviewed it. They are illustrative, not a claim of conformity and not legal advice.
From concept to evidence.
A control is the step where an idea from the Body of Knowledge becomes something a system must do and a reviewer can check.
- Concept What governance means for the system
- Pattern A reusable way to build it
- Control What must hold, and how to check it
- Implementation The tool or config that enforces it
- Evidence (layer 5) The record a third party can read
Seven properties of a useful control.
- One objective The outcome it secures, in one sentence a reviewer can hold it to.
- Named failure modes The observable events that mean it failed, not only what it intends.
- An enforcement point Where it acts: on a pull request, at deploy, at runtime or on a schedule.
- A verification someone else can run How a third party who did not build it would check it: inspect, test, observe or attest.
- Evidence it leaves The artefact it produces and the stack layer that keeps it, in a machine-readable shape where one exists.
- A failure response What happens when it fails: deny the action, hold it for a human decision or raise an alert.
- Checked mappings and sources The obligations, standards and threats it answers, each id checked against the site registers, and the sources it rests on.
Profiles.
79 reference controls across 5 profiles, all drafts open for technical review.
-
Evaluation Environment Control Profile
Draft control specifications for the environment a model or agent is evaluated in: the harness, tools, credentials, network, monitoring and stop conditions around it, and the evidence a run leaves.
9 controls (AIGE-CTL-EVAL-001 to AIGE-CTL-EVAL-009): 9 specified.
-
Agent Runtime Control Profile
Reference controls for AI agents at runtime, derived from the 31 agent controls of chapter 23. Every control is a draft: it restates the chapter, carries no verification procedure yet and is open for technical review.
31 controls (AIGE-CTL-AGENT-001 to AIGE-CTL-AGENT-031): 31 derived from chapter 23.
-
Data Admission and Privacy Control Profile
Reference controls for the data AI systems learn from: admission before a job reads a dataset, the right to use each source, lawful basis and purpose, fitness for purpose, integrity, lineage and downstream use. Every control is a draft derived from site patterns, record schemas and chapters 14 and 19, open for technical review.
12 controls (AIGE-CTL-DATA-001 to AIGE-CTL-DATA-012): 12 derived from site patterns, record schemas and chapters of the Body of Knowledge.
-
Assurance and Evidence Control Profile
Reference controls for testing an AI system before release, for the evidence every control writes and keeps, and for the integrity of the model artefacts and bill of materials a release ships with. Every control is a draft: it restates site material, carries no verification procedure yet and is open for technical review.
12 controls (AIGE-CTL-ASSURE-001 to AIGE-CTL-ASSURE-012): 12 derived from site patterns, record schemas and chapters of the Body of Knowledge.
-
Deployment and Monitoring Control Profile
Reference controls for AI systems in use, from the deployment decision and the go-live review to staged rollout, monitoring, incident reporting, deactivation and retirement. Every control is a draft derived from the site's patterns, record schemas and chapters 15 to 17, open for technical review.
15 controls (AIGE-CTL-DEPLOY-001 to AIGE-CTL-DEPLOY-015): 15 derived from site patterns, record schemas and chapters of the Body of Knowledge.
Controls by stack layer.
Each control has one home layer of the stack, where it is enforced or where its evidence is kept.
Layer 01: Govern-as-Code
Layer 02: Inventory & Transparency
- AIGE-CTL-AGENT-001 Registry entry
- AIGE-CTL-AGENT-002 Its own identity
- AIGE-CTL-AGENT-018 MCP server admission gate
- AIGE-CTL-AGENT-027 Data classes recorded, with the DPIA linked
- AIGE-CTL-DATA-002 Dataset Card for Every Admitted Version
- AIGE-CTL-DATA-003 Training-Data Rights Ledger Row per Source
- AIGE-CTL-DATA-004 Lawful Basis and Assessment per Processing Stage
- AIGE-CTL-DATA-008 Fitness-for-Purpose Checks Before Admission
- AIGE-CTL-DATA-009 Signed Snapshot Integrity
- AIGE-CTL-DATA-010 Lineage from Training Runs to Admitted Sources
- AIGE-CTL-DATA-011 Rights Changes Propagated to Affected Models
- AIGE-CTL-DATA-012 Registered Downstream Consumers of Outputs
- AIGE-CTL-ASSURE-010 Model Artefacts Signed at Build and Verified Before Load
- AIGE-CTL-ASSURE-011 Safe Model Formats and Digest-Pinned Third-Party Models
- AIGE-CTL-ASSURE-012 AI Bill of Materials per Build
- AIGE-CTL-DEPLOY-001 Deployment decision record before use
- AIGE-CTL-DEPLOY-002 Instructions for use held and followed
- AIGE-CTL-DEPLOY-007 Re-assessment when a change goes beyond what was foreseen
- AIGE-CTL-DEPLOY-013 Shadow AI discovery and registry reconciliation
Layer 03: Evals & Red Teaming as Evidence
- AIGE-CTL-EVAL-008 Harness and Configuration Attestation
- AIGE-CTL-EVAL-009 Evaluation Validity Checks
- AIGE-CTL-AGENT-013 Independent trajectory evals
- AIGE-CTL-ASSURE-001 Test Plan Frozen Before Evaluation
- AIGE-CTL-ASSURE-002 Release Blocked Below the Eval Threshold
- AIGE-CTL-ASSURE-003 Signed Test Report Against the Plan
Layer 04: Runtime Controls & Observability
- AIGE-CTL-EVAL-001 Authorization Boundary
- AIGE-CTL-EVAL-002 Network Egress Control
- AIGE-CTL-EVAL-003 Credential Isolation
- AIGE-CTL-EVAL-004 Tool and Action Mediation
- AIGE-CTL-EVAL-005 Monitoring Integrity
- AIGE-CTL-EVAL-006 Stop Conditions
- AIGE-CTL-AGENT-003 Read-only tools
- AIGE-CTL-AGENT-005 Tool allow-list, deny by default
- AIGE-CTL-AGENT-006 Checkpoint before every write
- AIGE-CTL-AGENT-007 Runtime guardrail on every tool call
- AIGE-CTL-AGENT-008 Execution budgets
- AIGE-CTL-AGENT-009 Approval log, bound to the call
- AIGE-CTL-AGENT-010 Per-agent circuit breaker
- AIGE-CTL-AGENT-011 Drilled kill switch
- AIGE-CTL-AGENT-012 Trajectory anomaly detection
- AIGE-CTL-AGENT-014 Reversible, bounded actions only
- AIGE-CTL-AGENT-015 Checkpoints on irreversible actions, failing closed
- AIGE-CTL-AGENT-016 Code runs only in a sandbox
- AIGE-CTL-AGENT-017 Output and egress filter
- AIGE-CTL-AGENT-019 Local MCP servers sandboxed
- AIGE-CTL-AGENT-020 MCP authorisation (spec 2026-07-28)
- AIGE-CTL-AGENT-021 Replace long-lived secrets with short-lived credentials
- AIGE-CTL-AGENT-022 Delegation, never impersonation
- AIGE-CTL-AGENT-023 Memory write gate and rollback
- AIGE-CTL-AGENT-024 Retention and erasure for personal data in memory
- AIGE-CTL-AGENT-025 Accountability across hops
- AIGE-CTL-AGENT-026 Stopping third-party agents at your boundary
- AIGE-CTL-AGENT-028 Prompts under change control
- AIGE-CTL-AGENT-031 Tell people they are dealing with an AI system
- AIGE-CTL-DEPLOY-003 Oversight by trained people with authority to stop
- AIGE-CTL-DEPLOY-005 Staged rollout with pre-registered rollback criteria
- AIGE-CTL-DEPLOY-006 Pinned versions and a tested path back
- AIGE-CTL-DEPLOY-008 Monitoring plan with thresholds, owners and consequences
- AIGE-CTL-DEPLOY-009 Fairness monitored by group in production
- AIGE-CTL-DEPLOY-012 Deactivation triggers, degraded modes and suspension
- AIGE-CTL-DEPLOY-014 Sanctioned AI gateway for staff use
- AIGE-CTL-DEPLOY-015 Retirement runbook with access and data removal
Layer 05: Assurance & Continuous Compliance
- AIGE-CTL-EVAL-007 Incident Evidence Preservation
- AIGE-CTL-AGENT-004 Traces
- AIGE-CTL-AGENT-029 Telemetry on the OpenTelemetry GenAI conventions
- AIGE-CTL-AGENT-030 EU AI Act hooks for a high-risk purpose
- AIGE-CTL-ASSURE-004 Common Signed Evidence Record
- AIGE-CTL-ASSURE-005 Live Control Status from the Assurance Store
- AIGE-CTL-ASSURE-006 Control Observations Filed Against Control Ids
- AIGE-CTL-ASSURE-007 Machine-Readable Evidence in OSCAL
- AIGE-CTL-ASSURE-008 Evidence Retention as Code
- AIGE-CTL-ASSURE-009 Internal Audit Answered from the Evidence Store
- AIGE-CTL-DEPLOY-004 Go-live decision with conditions as code
- AIGE-CTL-DEPLOY-010 Deployer log retention
- AIGE-CTL-DEPLOY-011 Serious incident reporting clocks
How these profiles relate to certifications and frameworks.
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.
How to adopt a profile.
- Pick the profile that matches the system. An evaluation harness and the environment around it take the evaluation environment profile; an agent that acts through tools in production takes the agent runtime profile.
- Map each control to your maturity level. Mark which controls you already run, which you can evidence and which are gaps, level by level of the maturity model.
- Use the mappings. Each control names the obligations, standards and threats it answers, so a gap reads straight onto the obligation register.
- Emit observations. Record every check of a control as an observation (control id, subject, expected, observed, status, timestamp and evidence), so the result is evidence a third party can read, not a claim.
How to review a control.
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.
Read the first profile.
Evaluation Environment Control Profile, v0.2: 9 draft controls for the environment a model or agent is evaluated in.