> For the complete documentation index, see [llms.txt](https://www.aicontrolarchitecture.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.aicontrolarchitecture.org/foundation/06-requirements-catalogue.md). # 06 · Requirements Catalogue This is the normative backbone of the architecture: the numbered, testable control requirements that the pillars implement, the templates capture evidence for, and the crosswalks map to external standards. Where the earlier documents explain *what control means and why*, this document states *what is required.* *** ## How to read a requirement Every requirement has a stable ID and a normative statement: ``` ACA-- e.g. ACA-09-02 ``` * **ID**: `ACA` + two-digit pillar (07–16) + sequence. IDs are stable; requirements are never renumbered, only deprecated. * **Statement**: written with **SHALL** (required), **SHOULD** (expected unless justified), **MAY** (permitted), in the RFC 2119 sense. * **From tier**: the lowest risk tier at which the requirement applies (see below). It also applies to every higher tier. * **Boundary**: the minimum [boundary source](/foundation/03-core-thesis.md) expected: *Declared, Evidenced, Verified, Enforced.* * **Crosswalk**: the external provisions it helps satisfy (see [`mappings/`](/standards-crosswalks/mappings-readme.md)). Each pillar document (07–16) is the authoritative source for its own requirements and their guidance; this catalogue is the consolidated, citable index. *** ## Risk tiers Requirements are graduated by tier. Tier is set in [pillar 07](/the-ten-pillars/07-pillar-ai-inventory-and-classification.md) from a use case's consequence (See/Decide/Do) and autonomy. ``` T1 Baseline every AI use case, including read-only and embedded vendor AI T2 Elevated accesses sensitive data, influences decisions, or has limited autonomy T3 High takes consequential actions, or operates with material autonomy (agents) ``` A requirement marked **From T2** applies to T2 and T3, not T1. *** ## The catalogue Representative requirements per pillar. This set is normative and versioned; it grows as the pillar documents are completed, and full guidance for each lives in its pillar. ### 07, Inventory & Classification | ID | Requirement | From | Boundary | | --------- | ------------------------------------------------------------------------------------------------------- | ---- | --------- | | ACA-07-01 | The organization **SHALL** maintain an inventory of all AI use cases, including embedded and vendor AI. | T1 | Evidenced | | ACA-07-02 | Each use case **SHALL** have a named accountable owner recorded at intake. | T1 | Declared | | ACA-07-03 | Each use case **SHALL** be assigned a risk tier before controls are selected. | T1 | Evidenced | | ACA-07-04 | The inventory **SHALL** be reconciled on a defined cadence and on material change. | T2 | Evidenced | ### 08, Identity & Access Control | ID | Requirement | From | Boundary | | --------- | ------------------------------------------------------------------------------------------- | ---- | -------- | | ACA-08-01 | AI **SHALL** act under a distinct non-human identity, not a user's standing credentials. | T2 | Verified | | ACA-08-02 | AI identities **SHALL** be granted least-privilege access scoped to the use case. | T2 | Verified | | ACA-08-03 | AI access **SHALL** be revocable promptly and completely. | T2 | Verified | | ACA-08-04 | High-tier actions **SHALL** be attributable to the identity and grant that authorized them. | T3 | Enforced | ### 09, Data Boundary Control | ID | Requirement | From | Boundary | | --------- | ----------------------------------------------------------------------------------------- | ---- | --------- | | ACA-09-01 | The data sources an AI may access **SHALL** be explicitly defined and approved. | T1 | Evidenced | | ACA-09-02 | Retrieval **SHALL** be scoped so AI cannot surface data the requester is not entitled to. | T2 | Verified | | ACA-09-03 | Sensitive data classes **SHALL** be excluded or masked unless explicitly permitted. | T2 | Verified | | ACA-09-04 | Third-party processing and retention of data **SHALL** be known and bounded. | T2 | Evidenced | ### 10, Input Control | ID | Requirement | From | Boundary | | --------- | ---------------------------------------------------------------------------------------------- | ---- | --------- | | ACA-10-01 | Untrusted input, including retrieved content, **SHALL** be treated as potentially adversarial. | T2 | Evidenced | | ACA-10-02 | Prompt-injection and manipulation **SHALL** be mitigated proportionate to tier. | T2 | Verified | | ACA-10-03 | System instructions **SHALL** be protected from override by user or retrieved content. | T3 | Enforced | ### 11, Output & Decision Control | ID | Requirement | From | Boundary | | --------- | -------------------------------------------------------------------------------- | ---- | --------- | | ACA-11-01 | Output that influences a consequential decision **SHALL** be identified as such. | T2 | Evidenced | | ACA-11-02 | High-impact decisions **SHALL** require human validation before effect. | T3 | Enforced | | ACA-11-03 | AI-influenced decisions **SHALL** be recorded with the output and rationale. | T2 | Evidenced | ### 12, Tool & Action Control | ID | Requirement | From | Boundary | | --------- | ---------------------------------------------------------------------------------------------- | ---- | -------- | | ACA-12-01 | The tools and actions an AI may invoke **SHALL** be explicitly allow-listed. | T2 | Verified | | ACA-12-02 | High-impact actions **SHALL** require approval or step-up before execution. | T3 | Enforced | | ACA-12-03 | No action class **SHALL** be enforced live without a defined containment or compensation path. | T3 | Enforced | | ACA-12-04 | Every action **SHALL** be logged with the requesting identity, inputs, and outcome. | T2 | Verified | ### 13, Human Accountability | ID | Requirement | From | Boundary | | --------- | ------------------------------------------------------------------------------------------ | ---- | --------- | | ACA-13-01 | A named human **SHALL** own each consequential outcome, decision, approval, and exception. | T1 | Declared | | ACA-13-02 | Risk acceptance for a use case **SHALL** be recorded and attributable. | T2 | Evidenced | | ACA-13-03 | Recovery ownership **SHALL** be assigned before go-live at tier ≥ T2. | T2 | Declared | ### 14, Assurance & Testing | ID | Requirement | From | Boundary | | --------- | ------------------------------------------------------------------------------------------------ | ---- | -------- | | ACA-14-01 | Controls **SHALL** be tested before go-live, proportionate to tier. | T2 | Verified | | ACA-14-02 | High-tier use cases **SHALL** undergo adversarial testing of input, output, and action controls. | T3 | Verified | | ACA-14-03 | Test results **SHALL** be retained as evidence and re-run on material change. | T2 | Verified | ### 15, Monitoring & Evidence | ID | Requirement | From | Boundary | | --------- | ------------------------------------------------------------------------------------------------- | ---- | -------- | | ACA-15-01 | Activity **SHALL** be logged sufficiently to reconstruct what AI saw, produced, decided, and did. | T2 | Verified | | ACA-15-02 | Logs **SHALL** be tamper-evident and retained per policy. | T2 | Verified | | ACA-15-03 | Anomalous or policy-violating behavior **SHALL** be detectable and alertable. | T3 | Verified | ### 16, Containment & Recovery | ID | Requirement | From | Boundary | | --------- | ---------------------------------------------------------------------------------------- | ---- | --------- | | ACA-16-01 | Each tiered use case **SHALL** have a tested means to disable the AI capability quickly. | T2 | Enforced | | ACA-16-02 | High-impact actions **SHALL** have a containment or compensation/rollback path. | T3 | Enforced | | ACA-16-03 | Recovery from an AI incident **SHALL** be owned, documented, and exercised. | T2 | Evidenced | *** ## Using the catalogue * **Assessing a use case:** tier it (07), then apply the requirements at or below that tier, recording the boundary source achieved for each. * **Proving control:** each requirement's boundary column is the bar; a requirement met only at *Declared* when *Verified* is expected is a finding. * **Mapping obligations:** the [crosswalks](/standards-crosswalks/mappings-readme.md) tie these IDs to NIST AI RMF, ISO/IEC 42001, EU AI Act, SR 11-7, NYDFS, and OWASP, so one pass serves many. *** ## Machine-readable form This catalogue is also published as data, generated from this document, in [`controls/`](/machine-readable-catalogue/controls-readme.md): ``` controls/aca-requirements.yaml controls/aca-requirements.json ``` Assessment tooling, agents, and GRC systems can consume that single source rather than re-transcribing the requirements. This document remains authoritative; the data files are built from it and checked against every pillar's table. A future version is expected to add an [OSCAL](https://pages.nist.gov/OSCAL/) profile. *** **Next:** [07 · Inventory & Classification](/the-ten-pillars/07-pillar-ai-inventory-and-classification.md) *Version 0.1.0 · Licensed under the terms in* [*LICENSE.md*](/project/license.md)*.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://www.aicontrolarchitecture.org/foundation/06-requirements-catalogue.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.