AIIR as an in-toto policy input

A public implementation note for carrying AIIR in an in-toto Statement and using receipt verification inside lightweight policy engines such as AMPEL.

Status Proposed public contribution shape. Narrow goal: carry AIIR in a familiar in-toto envelope, then use receipt verification as one policy signal when AI involvement is declared or required by repository policy.

Narrow goal

The adapter does not need to understand all of AIIR. It only needs to answer a few narrow questions: is there a matching receipt, does it verify, and does local or CI policy require it for the change in front of the engine?

The simplest public starting point is to carry the AIIR receipt in a standard in-toto Statement v1, with the AIIR commit receipt as the predicate. That keeps the example inside familiar attestation tooling without claiming that AIIR is already a standardized in-toto predicate.

Public references: AIIR commit receipt predicate v2, SPEC.md, AMPEL, and carabiner-dev/policies.

Concrete contribution shape

The smallest useful upstream contribution is a tiny aiir/ policy family in carabiner-dev/policies, paired with example wrapped receipts under testdata/aiir/.

  • has-attestation checks that an AIIR commit receipt is present for the subject under evaluation.
  • receipt-binds-subject checks that subject.digest.gitCommit matches predicate.commit.sha.
  • authorship-class checks the declared AIIR authorship class such as human or ai_assisted.
  • Example attestations cover one passing wrapped receipt, one binding mismatch, and one non-AI human receipt.

That keeps the public example concrete enough to review without asking AMPEL to adopt a new trust model or to infer undeclared AI use.

Illustrative policy shape

# illustrative only — not current project syntax
rules:
  - when:
      protected_paths: ["src/", "policy/"]
      declared_ai: true
    require:
      - aiir_receipt_present
      - aiir_receipt_valid
      - aiir_receipt_matches_commit

The point is to keep AIIR's role explicit and narrow: AIIR answers receipt questions, while the policy engine answers allow-or-deny questions.

Why this works

  • The policy engine gets a crisp pass-or-fail input instead of a new provenance model.
  • The first example reuses an in-toto Statement envelope instead of inventing a new attestation shape.
  • AIIR receipts are already content-addressed and locally verifiable.
  • The resulting policy can stay small enough to understand and review publicly.

Boundaries

  • This does not claim AIIR detects undeclared AI use.
  • This does not ask the policy layer to parse every AIIR detail.
  • This is not a replacement for SLSA provenance or other build attestation formats.
  • This does not assert any SLSA level by itself.
  • This does not require a hosted AIIR service.

Next public step

If the shape is useful, the next public step is an upstream PR that contributes the aiir/ policy family and testdata/aiir/ examples, then tightens this note to point at the merged paths directly.

Open policies repo → See protected-path policy → Back to ecosystem →