# AATS v0.9 — Public Working Draft

**AI & Agentic Trust Standard** · Version 0.9.0 · 2026-09-12 · Draft editor: ColomboAI

## 1. Purpose and scope

AATS defines controls and evidence for trust in deployed AI applications and agents. Its unit of assessment is a declared deployment boundary: named application/agent versions, identity and owners, model and provider routing, memory, tools, data stores, permissions, policy, execution environments, and connected services. The same model in another harness or permission context is a different assessment scope. AATS is vendor-neutral and does not require any MC-1 product.

An applicant MUST publish a scope record identifying system IDs, organization, deployment environments, capability level, intended users, data classes, consequential actions, exclusions, assessor, and evidence period. Exclusions MUST be justified and visible to the assessor. A significant capability increase requires reassessment before the new capability is represented as certified.

This draft is a technical standard and proposed assurance method. It does not establish legal compliance, regulatory approval, or an accredited certification body. Jurisdictional duties remain with the operator.

## 2. Normative language and assessment result

`MUST`/`MUST NOT` denote requirements; `SHOULD` denotes a recommended control whose omission needs documented rationale; `MAY` denotes an option. The requirement IDs in [the control catalog](controls/README.md) are normative. For each applicable `MUST`, the assessor records **PASS**, **FAIL**, **NOT APPLICABLE**, or **INSUFFICIENT EVIDENCE** with evidence references, test date, boundary, and rationale. `NOT APPLICABLE` is allowed only when the underlying capability/resource is absent from the declared scope. `INSUFFICIENT EVIDENCE` does not count as a pass.

Evidence MUST be attributable to its source, time bounded, integrity protected, access controlled, and reproducible or independently inspectable. AATS does not require disclosure of proprietary hidden model reasoning. An assessor can use decisions, tool calls, inputs/outputs where lawful, policy evaluations, and outcomes instead.

## 3. Capability gates

The level is set by the most consequential capability available through direct execution **or delegation**. Disabling a capability only in a user interface does not lower the level if a service account or tool path can still exercise it.

| Level | Capability | Gate before operation | Minimum assurance cadence |
|---|---|---|---|
| 0 | Informational AI, no material autonomous tool execution | Identity, data/model/provider governance, privacy, baseline evaluation and logging | On material change and at least annually |
| 1 | Read-only retrieval or tool access | L0 plus scoped read authority, data isolation, tool inventory, access logs | On material change and at least quarterly |
| 2 | Tool-using agent that can call bounded tools but cannot persist external changes | L1 plus tool authentication, instruction security, containment, behavioral tests | On material change and at least monthly |
| 3 | Write-capable agent or persistent state mutation | L2 plus transaction authorization, least privilege, rollback/recovery, human oversight policy | Continuous control/event monitoring; independent review at least semiannually |
| 4 | High-impact autonomous action, including material financial, administrative, or production changes | L3 plus pre-action risk gate, independent adversarial evaluation, tested suspend/kill path, heightened incident response | Continuous monitoring; independent review at least quarterly |
| 5 | Critical autonomous system where failure can cause severe harm, safety impact, or essential-service disruption | L4 plus safety case, independent domain evaluation, fail-safe behavior, human override, recovery exercises | Continuous monitoring; independent review at least quarterly and after every material change |

Cadences are draft maximum intervals; applicable law or contract may demand more. At L3–L5, controls that depend on a runtime signal MUST be evaluated at execution time or by an enforcement point on the action path; a periodic inventory alone cannot establish authorization.

## 4. Certificate classes

| Class | Scope | Eligibility |
|---|---|---|
| AATS-AI | AI application without material autonomous execution | L0, optionally L1 |
| AATS-Agent | Agent with tools, memory, or delegated authority | L1–L3 |
| AATS-Autonomous | Agent capable of consequential autonomous actions | L3–L4 |
| AATS-Critical | High-impact regulated, safety, physical, or essential-service deployment | L4–L5 |
| AATS-Enterprise | Defined organization-wide AI estate | Inventory coverage, per-system applicable class, and estate controls; does not turn unknown systems into certified systems |

An applicant MUST claim a level and class consistent with measured capability. AATS-Enterprise MUST enumerate covered systems and coverage gaps. Criticality is determined by impact, not industry label alone. An assessor MAY assign a higher level than the applicant requested.

## 5. Control model

The 25 domains in [controls/README.md](controls/README.md) are the minimum catalog. Every domain has at least one normative test and expected evidence. Controls apply in proportion to actual capability and data exposure. Dependencies are cumulative: higher levels inherit lower-level controls. Privacy, identity, accountability, incident response, and change management are never waived solely because a system is read-only.

For each control the operator MUST maintain a control owner, mechanism, scope, evidence source, verification procedure, last result, and remediation ticket when failing. The assessor MUST sample both configured controls and actual runtime events, including at least one negative/denial test for authorization or containment at L2–L5. Sensitive test data MUST be minimized and handled under the system's privacy policy.

## 6. Evidence and attestations

An evidence record MUST include control ID, subject/scope ID, source, collection time, assessment time, method, assessor or automated verifier, result, cryptographic digest, and access classification. Signed evidence SHOULD use a documented signature algorithm and key rotation procedure. A digest proves integrity of the retained object; it does not prove that the source was truthful. The assessor MUST test source reliability and collect corroborating evidence for critical controls.

The operator MUST retain enough historical evidence to reconstruct every certificate state transition throughout the certificate lifetime and the declared retention period. Evidence containing personal data MUST be access controlled, redacted for public release, and deleted under applicable retention policy. Public registry records MUST contain only the minimum claims needed to verify a certificate.

## 7. Continuous certification

Certification is an independent decision tied to a fixed scope, standard version, class, level, assessor, issue date, expiry, and ongoing evidence obligations. The state machine and precedence rules are normative in [assurance/certification.md](../assurance/certification.md). A technical platform MAY calculate readiness and technical verification, but MUST NOT self-issue an `AATS Certified` claim on behalf of an independent assessor.

Every material model, provider, prompt/policy, tool, MCP server, identity, permission, memory, code, data-route, or environment change MUST be evaluated for certification impact. A new unauthorized capability or critical-control failure MUST prevent continued ACTIVE display. A published state MUST include reason codes, effective time, and latest verification time. Expiry or withdrawal MUST resolve to REVOKED, not an indefinitely stale ACTIVE state.

## 8. Trust score

A score MAY summarize readiness or technical status across identity, privacy, data, authorization, containment, tools, models, providers, monitoring, incidents, behavior, and change management. The published score MUST disclose weighting, scope, evidence recency, missing controls, and calculation version. It MUST NOT override a critical failure, substitute for an independent decision, or be displayed as a certificate. The state and the failed critical control MUST remain prominent even if the numerical score is high.

## 9. Independent assessment

Assessors MUST be organizationally independent of the operator and implementation vendor for the assessed decision; declare conflicts; document competency; follow a repeatable sampling and testing plan; preserve workpapers; and sign the final opinion. Evaluator access MUST be scoped, time limited, least privilege, and logged. The assessor MUST be able to challenge operator-provided evidence and run or witness tests. ColomboAI may contribute tools, but product telemetry alone cannot be the sole basis for independent certification.

## 10. Interoperability

The [schemas](../schemas/README.md) define portable JSON records for system scope, evidence, certificates, trust passports, and state events. Implementations MAY use other internal forms if they can export semantically equivalent records. IDs SHOULD be stable, opaque identifiers; credentials SHOULD support signature verification and revocation/status checking without contacting one vendor. AATS control IDs and version MUST appear in exports.

## 11. Safety and privacy limits

Publishing a passport or registry record MUST NOT expose secrets, raw prompts, private user data, or exploit details. Incident and evaluator records need stronger access controls than public certificate metadata. AATS is not a guarantee that an AI system is safe or error-free; its claim is bounded to specified controls, evidence, time, and scope.

## 12. Revision path

v0.9 is ColomboAI-led and open to public review. v1.0 requires documented working-group review of control clarity, evidence burden, and assessor independence. Later revisions use public RFCs and semantic versioning as described in [governance](../governance/README.md). Normative changes are never retroactively assumed to be satisfied by an old certificate.