Compliance Checklist: 25 Enforceable Boxes Across the Seven Properties

Twenty-five yes/no checks, grouped by the seven properties: a system either does it or it doesn't. The long form is the 22 auditor questions.

Where the checks come from:

  • Eighteen from the reports. Observed practice in Anthropic's architecture, Brex's governance principles, and Intercom's audit story.
  • Seven from this handbook. The three dependency-provenance items are prescriptions no vendor ships today. Four more harden the audit-trail, review-gate, and reproducibility checks against quieter failure modes.

An item passes only if the system enforces it, not if a policy document promises it. "Engineers are asked not to share tokens" fails the credential items; "the snapshot pipeline aborts when the scrub fails" passes.

1. Attribution: every change traces to a human

Work "needs to be attributed back to an actual human and not just a bot," as Brex states the principle flat (Brex).

  • Every AI action runs under a distinct, synthetic AI identity, never a borrowed human token.
  • That AI identity is bound to the human who initiated the task, so "who did this?" always resolves to a real, accountable person.
  • Human-authored and AI-authored work are always distinguishable in the record: commits, PRs, approvals, deploys.

No shipping platform fully meets the per-initiating-human bar today. Hold it anyway; it is the standard.

2. Audit trail: the session log is external and queryable

The artifact an auditor reads is the same one that lets a failed agent resume: Anthropic's append-only session log stored outside the containers (Anthropic).

  • A durable, external, append-only log captures every step: prompt, agent actions, tool calls, review decision, test results, merge event.
  • The log survives the environment being destroyed and cannot be quietly rewritten.
  • The log is queryable by task, actor, environment, and time window (the four-axis audit query).
  • The actor on each entry is captured as an immutable value at the moment of the action, not resolved through a live reference (a join to a mutable users table) that a later rename, reassignment, or deletion would silently rewrite.
  • Retention spans the full audit period (12 months for a SOC 2 Type II sample), and it covers supporting per-step and execution logs, which often sit on a shorter operational default than the top-level session log.

3. Least privilege: credentials never meet model-generated code

  • Credentials never enter the environment where model-generated code runs; tokens are bundled for one-time initialization or fetched through a proxy the model never touches.
  • Each task environment gets only the access that task requires: scoped repo access, scoped secrets, nothing ambient.
  • Secrets are split-trust at rest, and plaintext exists only transiently at provision time, never frozen into a reusable image.
  • Per-identity credentials are scrubbed before any environment is snapshotted, as a hard gate: a scrub failure aborts the snapshot.

4. Isolation and residency: placement is a policy, not a re-architecture

  • Each task runs in its own isolated environment with no cross-environment communication.
  • Environments are regionally placeable, so data-residency requirements are satisfied by a placement decision per task.

5. Segregation of duties: the author is never the sole approver

Intercom's numbers set the bar for what an enforced gate yields: zero reverts in the 100-PR pilot that proved the gate safe (Intercom).

  • The entity that authors a change is never its sole approver; a separate gate, automated reviewer or required human, approves every change.
  • An automated reviewer's verdict is a structured, schema-validated field, approve or reject plus a reason, not free text a downstream system has to interpret.
  • Required human gates are enforced by the system and every gate action is recorded.
  • Large changes are refused at the gate, not rubber-stamped; the reviewer requires a break-down into small, reversible PRs.
  • Any engineer can pull any change into human review at any time.

6. Reproducibility: the change process is encoded

  • Environments are built from versioned, known-good images, so the conditions of any change are reproducible on demand.
  • The change process (write, review, approve, ship) is encoded and runs identically for every task, with each task's lifecycle recorded against it.
  • The rule that decides whether an inbound event starts or routes new work is a deterministic, inspectable filter or schedule fixed ahead of time (event routing), never a live model judgment made per event, so "why did this run" is answerable without re-invoking a model.

7. Dependency provenance: nothing installs on the model's say-so

These three items are this handbook's prescription, not observed practice; no agent platform ships them today. The gap is real: a USENIX Security 2025 study found 19.7% of packages recommended across 576,000 LLM code samples did not exist, and 43% of hallucinated names recurred on every run (Socket). The cooldown half of the fix is already mainstream in package managers (Nesbitt); the agent platforms haven't adopted it. Full argument: dependency provenance.

  • Agent installs resolve only through a gating proxy or curated registry; package identities not already trusted fail closed before any install script runs.
  • A minimum-release-age cooldown applies to every version the agent installs, so freshly published poison expires before it is eligible.
  • Any new dependency appears as an explicit diff at the review gate, with name, age, publisher, and advisory status, and is never merged solely because the model named it.

Ask for artifacts, not assurances

Three asks separate a vendor (or your own platform team) that produces artifacts from one that offers assurances:

CheckAsk for
Audit trailA live query: "everything actor X did between these two dates," returned from the log, not reconstructed
Credential scrubA scrub-failure log entry showing an aborted snapshot
Segregation of dutiesA recorded attempt at self-approval, blocked by the system

If the answer to any of these is "we could add that," the box is unchecked.

Your score depends on your deployment path

  • Laptops. You fail nearly every box, because the laptop model collapses identity, access, and audit onto one person and one device (why the laptop never had to answer this).
  • Building in-house. Each unchecked box is a project with an owner and a quarter.
  • Buying. This page is the procurement questionnaire; the longer form is the 22 auditor questions.

Everyone, including vendors, fails the last three boxes today. Ask anyway: a vendor that has heard the supply-chain question before is taking it seriously.