the AI agent audit trail: NYDFS Part 500 + SR 26-2 evidence.

Why an inference log is not an audit trail.

The 16 October 2024 NYDFS Industry Letter does not impose a new rule — it says so itself: "This Guidance does not impose any new requirements beyond obligations that are in DFS's cybersecurity regulation codified at 23 NYCRR Part 500". It applies the Part 500 framework to AI. Be precise about how far it goes, though: the Letter works its four AI risk categories mainly through § 500.11, third-party service provider and vendor management, and it does not cite § 500.6 or § 500.17 anywhere. Reading § 500.6(a)(2) onto an AI deployment is an inference from the regulation's own text, which applies to Covered Entities regardless of the technology — it is not an instruction the Letter gives, and this page marks it as ours. Note also that § 500.6 does not attach at all to an entity exempt under § 500.19(a), (c) or (d). Read against the clause, a standard AI deployment's logs come up short. The API gateway records timestamp, method, path, status, latency. The LLM inference log records prompt tokens, completion tokens, the model id, and a redacted prompt body. Both are traffic-shaped. A § 500.6(a)(2) audit trail is operation-shaped. The full statutory read of why standard logs fall short is in standard API call logs do not satisfy 23 NYCRR § 500.6.

US bank model risk guidance does not set the same bar, and the reason matters. SR 26-2, issued 17 April 2026 (OCC Bulletin 2026-13) by the Federal Reserve / OCC / FDIC, supersedes and replaces SR 11-7 (2011) and SR 21-8 and carries the same model risk discipline into a principles-based, risk-tailored restatement. (The "four pillars" is Warrant's taxonomy for reading that discipline, not a structure either letter names.) Footnote 3 to its § II then states that generative AI and agentic AI models are not within the scope of the guidance, and hands them to the bank's own risk management and governance practices instead. The letter never uses the words artificial intelligence, machine learning, or runtime. So the documentation expectation still reaches every conventional model the agent calls, and stops at the agent, while footnote 1 keeps supervisory action available for unsafe or unsound practices. NYDFS is the clause that binds the trail; SR 26-2 is the framework that walked away from it. The pillar-by-pillar reading is in SR 26-2 / SR 11-7, line by line.

Put the two regimes side by side and they converge on one shape: a record per consequential action that an examiner can read end-to-end. The question is what that record has to contain.

The five questions a regulator asks.

An examiner reconstructing an AI agent's decision does not start from the architecture. It starts from a single consequential action and asks five questions. Each question is anchored to a clause. Two of the five are answered by a field in the signed warrant-v1 record; three are not, and this page names the field that is absent rather than describing one that does not exist.

What did the agent access.

The first question is the simplest to ask and the hardest for a standard log to answer. § 500.6(a)(1) requires systems designed to reconstruct material financial transactions. The reconstruction has to name the specific data element the agent touched, because Nonpublic Information under § 500.1(k) is defined broadly: business information whose tampering would materially impact operations, the classic combination-PII prong, and health information.

An agent that fetched a customer's last twelve transactions records those twelve specific transaction IDs, not "GET /transactions returned 200 in 84ms." The signed record names the subject of each action. It does not carry the inputs and outputs that flowed through it. In warrant-v1 the row is actions[*] with exactly action_id, actor, action and subject; the submitted trace's inputs, outputs and per-step fields are stripped before the aggregate is built and are not re-emitted. SR 11-7's documentation pillar reads a wider requirement than that — a knowledgeable third party must be able to reconstruct what the model consumed and produced — and the input and output leg of it is met from the entity's own trace, not from the package.

This is also where the agentic shape diverges sharply from a 2011-era model. A credit-score regression issued one decision and the trail was a single database row. An AI agent issues a sequence of tool calls and retrievals before the customer-facing decision, and an audit trail that answers the examiner has to reconstruct each one. Anything coarser leaves the question unanswered. For a conventional in-scope model the bar is SR 11-7's third-party replicability standard; for an agentic system it is the bank's own, since that sentence did not carry into SR 26-2 and footnote 3 puts the agent outside the guidance in any event.

When did it happen.

The second question is about time, and time is where most logs quietly fail. § 500.6(b) sets a retention floor of five years for (a)(1) records and three years for (a)(2) records. An audit trail that lives inside a 30-day application-log rotation does not satisfy. More to the point, the retention clock is meaningless if the timestamps inside the trail can be edited after a Cybersecurity Event.

The § 500.17(a)(1) 72-hour notice clock starts at determination that a cybersecurity incident — the narrower § 500.1(g) term, not the § 500.1(f) Cybersecurity Event — has occurred at the covered entity, an affiliate, or a third-party service provider, and not at occurrence. To meet that clock, an investigator has to place the agent's actions at fixed points relative to the determination. A record whose timestamp is under the Covered Entity's own control cannot do that against an adversarial reading. Warrant does not close that gap per action. warrant-v1 carries no per-action timestamp — the submitted trace's timestamps are stripped before the aggregate is built — and the one time value in the package, trace_metadata.timestamp, is set when the package is sealed, not when the action ran. What is independently checkable without contacting Warrant is that the sealed record existed no later than the seal, which bounds the record from one side only. Placing the action itself in time is done from the entity's own trace.

Under what authorization.

The third question separates legitimate access from compromised access, and it is the one a § 500.6(a)(2) audit trail is built around. An agent that accessed an account number is in scope for § 500.7 access privileges, and the trail must record the authorization the access satisfied. Without it, an investigator cannot tell a permitted read from a breach.

In warrant-v1 this is the authorizations[*] row for the action: within_purpose, preconditions_met, human_oversight_appropriate, reversible, justification and confidence. That is the purpose limitation and the reasoning, and it is the part of the third question the package answers. The policy and the role are not in it — there is no policy identifier and no role or officer field in the schema — so the authority under which the access was permitted is bound to the evidence in the entity's own governance record, not inside the package. Standard logs record that a request succeeded. They do not record whether the agent was allowed to make it.

SR 11-7 reads the same field from the governance pillar, which requires a named human officer accountable for the model's outputs; the agent does not displace that accountability, it inherits it. Warrant's record does not carry that officer: there is no policy_version_id and no approver or role field in warrant-v1, so the named-officer leg of the governance pillar is evidenced from the entity's own governance record and bound to the package by the entity, not by the schema. The deployer-side accountability question, read against the EU regime, is in the Article 26 deployer obligations, line by line.

Under what constraints.

The fourth question is the one most logs never even attempt. SR 11-7 defines effective challenge as critical analysis by objective, qualified individuals who can identify model limitations and assumptions. SR 26-2 § III keeps that definition and runs it across the model lifecycle, from development to ongoing monitoring — for models it covers, which an agentic system is not. No letter requires per-decision alternatives logging. Which is the problem, not the relief: the agent that emits one path through one tool, with no record of what it weighed and discarded, has nothing to offer the examiner who asks on what basis the choice was sound.

In warrant-v1 the constraints leg is authorizations[*].preconditions_met together with .human_oversight_appropriate — Warrant's per-action assessment that oversight was appropriate, not evidence that a human was present — and .reversible. Alternatives considered is not a field. No letter requires it and the package does not carry it, so the examiner who asks what the agent weighed and discarded is answered from the entity's own trace or not at all. What the package carries sits adjacent to what § 500.6(a)(2) reads from the cybersecurity direction, and the distance matters. A preconditions_met of no — the value is a three-state string, yes, no or uncertain, not a boolean — records that Warrant assessed the action as falling outside the conditions its authorization required. It does not establish an act or attempt to gain unauthorized access to, disrupt or misuse an information system, which is what § 500.1(f) defines a Cybersecurity Event to be. Whether an event occurred is the Covered Entity's determination, made against its own risk assessment and its own systems, and warrant-v1 defines no event-classification property, so the package never carries that answer. The constraint record is a signal that can open the inquiry. It is no part of the conclusion.

SR 11-7 also fixes when the constraints have to be re-established. A foundation-model swap, a prompt-template rewrite that broadens the use case, or a retrieval-corpus change that introduces new domains each read as triggers for re-validation. Warrant's record cannot show that. warrant-v1 has no model_version and no policy-version field, so whether the action ran under the constraints that were actually validated is a question the package leaves to the bank's own model inventory and change record.

With what result.

The fifth question closes the loop: what decision did the action influence, and which model produced it. Keep the two limbs of § 500.6(a) apart here, because they are easy to merge and the merge is wrong: (a)(1) is about systems "designed to reconstruct material financial transactions", while (a)(2) is about audit trails "designed to detect and respond to cybersecurity events". Reconstruction attaches to financial transactions; detection and response attach to events. The claim that § 500.6(a)(2) requires an event to be reconstructed end-to-end is not in the text, and NYDFS has not said it — what follows is Warrant's argument about what a trail has to hold to support detection and response at all. SR 11-7 required every material model in production to carry an inventory row with version, owner, last validation date, and residual risk. SR 26-2 keeps a model inventory expectation, and its footnote 3 means an agentic system no longer has to be on that inventory at all. A bank that leaves it off is compliant with the letter and unable to say who owns the agent, what version is live, or when it was last tested. That is the answer an examiner is left holding under the general safety-and-soundness expectation.

The fifth question is the one Warrant's record answers least. There is no outputs field in warrant-v1 and no model inventory identifier, so the package does not bind an action to the version that produced it. What it carries per action is the obligation determination — obligations.<action_id>[] rows with a compliance status, an evidence string quoting or paraphrasing the clause text, and a confidence — plus the authorizations[*] row. That is a record of how the action was assessed against a named clause, not a record of the decision content or the model lineage behind it. An examiner who wants to walk from the action to an inventory row to a model card walks that path in the bank's own inventory; a firm that does not maintain one is left without the walk entirely, which is itself the gap finding.

§ 500.11 third-party service provider governance attaches here too. A foundation-model provider that processes NPI on the Covered Entity's behalf is a third-party service provider, and the audit trail has to be able to say which model acted. actions[*].actor is where that lands — in Warrant's US underwriting sample the actor on each action is the model id — but it is a single free-text identifier. There is no separate provider field, no model version field and no vendor tenant field, so the third-party chain is named only as far as the actor string names it.

Where the EU AI Act crosses over.

The five questions are not unique to the US. An AI agent that evaluates the creditworthiness of natural persons or establishes their credit score is high-risk under Annex III point 5(b) of Regulation (EU) 2024/1689, which brings the Article 12 record-keeping obligation. Application of Article 12 to Annex III standalone high-risk systems is deferred from 2 August 2026 to 2 December 2027 by the Digital Omnibus, which replaces the earlier conditional trigger with a fixed date (Regulation (EU) 2026/1744, OJ L 2026/1744, 24 July 2026). Non-compliance is reachable under Article 99(4) at up to EUR 15 million or 3 percent of global annual turnover.

So one credit-decisioning agent serving EU and US customers stands under three record demands at once: NYDFS § 500.6(a)(2), SR 11-7 ongoing monitoring, and EU AI Act Article 12. The supervisors differ; the questions do not. Each asks what the agent accessed, when, under what authority, under what constraints, and with what result. That convergence is the point: one per-action record answers all three sets of questions. What the package cites is narrower than what the questions cover. The obligation corpus carries a § 500.6 table for neither (a) nor (b), so a package reports NYDFS Part 500 as classified and in scope, not evaluated; the § 500.6 reading on this page is Warrant's, drawn from the regulation, and no package asserts it. The classification reading for creditworthiness is in the high-risk classification Guidelines, read in full.

Questions a compliance officer asks first.

Read the source directly.

• 23 NYCRR Part 500, Second Amendment (1 November 2023, PDF) · § 500.6 audit trail
• NYDFS Industry Letter, Cybersecurity Risks Arising from Artificial Intelligence (16 October 2024)
• Federal Reserve / OCC / FDIC SR 26-2, Revised Guidance on Model Risk Management (17 April 2026) · current; supersedes SR 11-7 and SR 21-8
• Federal Reserve SR 11-7, Supervisory Guidance on Model Risk Management (4 April 2011) · superseded predecessor
• Regulation (EU) 2024/1689 · EUR-Lex CELEX:32024R1689 · Annex III point 5(b) + Article 12
• Standard API call logs do not satisfy 23 NYCRR § 500.6 · the statutory read
• SR 26-2 / SR 11-7, line by line · Warrant's four-pillar reading, checked for evidence
• NYDFS Part 500 · per-obligation Warrant evidence field mapping
• SR 26-2 / SR 11-7 · per-obligation Warrant evidence field mapping

Authored by Warrant Compliance, the regulatory-analysis function at Warrant. [email protected]. Editorial commentary on regulatory text. Not legal advice. SR 26-2 (17 April 2026, OCC Bulletin 2026-13) is the current interagency model risk guidance and supersedes SR 11-7 (2011) and SR 21-8. Footnote 3 to SR 26-2 § II places generative AI and agentic AI models outside the scope of that guidance; quoted from the attachment at federalreserve.gov/supervisionreg/srletters/SR2602a1.pdf, re-verified against that attachment on 6 August 2026 (a probe for a non-existent SR2699a1.pdf on the same host returns 404, so the 200 discriminates). The five-question framing is Warrant's reading of 23 NYCRR § 500.6(a)(2) applied to AI per the 16 October 2024 Industry Letter; the regulators did not write it as a numbered list. The verbatim quotations of § 500.6 and the SR 11-7 § V lineage are from the official texts cited above.