Skip to content

Latest commit

 

History

History
160 lines (133 loc) · 7.21 KB

File metadata and controls

160 lines (133 loc) · 7.21 KB

AERF × SR 11-7

← Compliance Overview · ← README

Scope. AERF is an open wire format for cryptographic receipts of AI-agent actions. This page maps AERF v0.1.0-draft.1 to the audit-trail and decision-traceability portions of Federal Reserve SR 11-7 supervisory guidance on Model Risk Management as applied to AI-agent-driven decisions. The page is written for a model risk management (MRM) team at a regulated financial institution, an internal validator, or a federal banking-agency examiner.

AERF is in scope for the audit-trail and decision-traceability portion of SR 11-7 as applied to AI-agent-driven decisions. AERF is out of scope for model development, validation, governance, and policy controls.

Note on supersedure. SR 26-2 (April 17, 2026) supersedes SR 11-7 for in-scope quantitative models at large banking organizations. SR 26-2 explicitly carves generative AI and agentic AI out of its scope. SR 11-7's principles continue to inform agentic-AI MRM practices precisely because SR 26-2 does not cover them. This page uses the SR 11-7 framing because that is the framing applicable to agentic AI today.

Item Value
AERF version v0.1.0-draft.1 (May 2026)
Source guidance SR 11-7 (April 4, 2011); SR 26-2 (April 17, 2026, excludes agentic AI)
Last verified 2026-05-08

Primary mappings

Audit trail of model usage

Source: SR 11-7 — Federal Reserve

  • Requirement (paraphrased from SR 11-7). Banks should maintain documentation of model usage sufficient to support effective challenge and ongoing monitoring, including a record of when models were used, for what purpose, with what inputs, and producing what outputs.
  • AERF provides. Where the "model" is an AI agent or an LLM-based decision component, each invocation can produce an AERF receipt binding agent (model identity), action (the use-case), an evidence_hash_sha512 digest over the input payload, and an optional output_hash. observed_at (with optional RFC 3161 anchoring per SPEC §11) captures timing.
  • Coverage. Partial. AERF is the per-decision evidence artifact.
  • Gap. AERF does not maintain the model inventory, lineage, or validation history.

Model inventory linkage

Source: SR 11-7 — Federal Reserve

  • Requirement (paraphrased). "Banks should maintain a comprehensive set of information for models implemented for use, under development for implementation, or recently retired" — including ownership, purpose, and risk tier.
  • AERF provides. The agent field is the runtime identifier of the model in production; combined with key_id (issuer key) it uniquely binds a receipt to an entry in a model inventory. The policy_hash ties the action to the documented policy under which the model was sanctioned for use.
  • Coverage. Partial. AERF references the inventory.
  • Gap. Inventory tooling (purpose, owner, validation status, risk tier) remains in the bank's MRM system; AERF does not implement it.

Effective challenge and ongoing monitoring

Source: SR 11-7 — Federal Reserve

  • Requirement (paraphrased). Validation includes ongoing monitoring (process verification and benchmarking) and outcomes analysis, with documentation sufficient for an independent reviewer to reproduce findings.
  • AERF provides. The independently verifiable receipt stream is documentation that an independent reviewer can replay without trusting the bank's logging chain. A reviewer with the issuer's public key can confirm that a sample of model outputs in scope of the validation period was unmodified.
  • Coverage. Partial. AERF preserves the evidence record.
  • Gap. AERF does not perform benchmarking, challenger-model comparison, or outcomes analysis — those are MRM activities.

Why AERF specifically applies to SR 11-7 contexts

SR 11-7 places weight on documentation that "an independent reviewer" can use without privileged access to the model owner's tooling. The AERF property that verification requires only the issuer's public key — no AERF software, account, or service — aligns with that posture. This is the same pattern as cosign for container images and slsa-verifier for build provenance, applied to model decisions.

Gaps — SR 11-7 expectations AERF does not address

  • Model development standards. Out of scope: development process is upstream of the receipt.
  • Conceptual soundness review. Out of scope: review of the model's theoretical basis is an MRM activity.
  • Independent validation. Out of scope: AERF supplies evidence; it is not a validator.
  • Policies and procedures, roles and responsibilities, internal audit. Out of scope: programmatic.
  • Model documentation (theory, methodology, assumptions, limitations). Out of scope: AERF binds outputs to a runtime policy; it does not document the model's mathematics.
  • Vendor model risk. Out of scope: AERF can be used by vendors to provide externally verifiable evidence to bank customers, but the vendor-management process itself is organizational.

Security model

The verifier trusts the issuer's public key, distributed out of band per SPEC §9.2. The issuer's private key is held by the regulated institution or its model vendor; a key compromise breaks the signature trust assumption (see SPEC §12.3). RFC 3161 trusted timestamps SHOULD be used in the production profile so that an examiner can confirm the receipt existed in its present form before any compromise window.

Auditor verification guide

The verifier workflow is identical across frameworks; see the AIUC-1 auditor verification guide for exact commands and expected output. The verifier source is at verifiers/go/verify.go; the canonical example receipt is at verifiers/go/example/receipt.json. The independent-verifier property is the reason AERF maps to SR 11-7 at all: a model risk management team or examiner can audit a sample of agent decisions without engaging the model-owning business unit's tooling.

Sources:


← Compliance Overview · ← README