Standard API call logs do not satisfy 23 NYCRR § 500.6.

The exact line, in context.

The October 2024 Industry Letter opens with one sentence that sets everything else. Read it slowly.

That sentence is the wedge. The Industry Letter is not a new rule. It applies an existing regulation, in effect since 2017 and last amended November 2023, to AI — working the four risk categories it identifies mainly through § 500.11. It does not cite § 500.6. That section of the same regulation is the audit trail provision, and reading it against an AI deployment is Warrant's inference from the regulation's own text, not an instruction the Letter gives:

The two clauses do different work. § 500.6(a)(1) is about reconstructing financial transactions. § 500.6(a)(2) is about detecting and responding to Cybersecurity Events. An AI agent that touches Nonpublic Information is in scope for both, but the (a)(2) clause is the harder test, because Cybersecurity Event under § 500.1(f) is a broad category covering unauthorized access, attempts at it, and tampering with Information Systems.

Read against § 500.6(a)(2), the question for a compliance team is whether today's logs support detection of, and response to, the Cybersecurity Events an AI system can produce. For most teams running production AI, the answer is no. Standard API call logs record traffic. They do not record decisions, authorization checks, or the boundaries of NPI access. LLM inference logs record prompts and completions, sometimes redacted. Neither carries the binding § 500.6(a)(2) requires.

What NPI means in 23 NYCRR § 500.1(k).

The Industry Letter uses the term Nonpublic Information, abbreviated NPI, in nearly every paragraph of Sections II and III. The term is defined in 23 NYCRR § 500.1(k), broader than most engineering teams assume.

Three things follow.

The (1) prong covers any business information whose tampering would materially impact operations. A retrieval-augmented agent reading internal pricing tables is touching NPI under prong (1). A model that ingests internal credit policy is touching NPI under prong (1). Most AI deployments inside a financial services company are in scope before the engineering team realises it.

The (2) prong is the classic PII prong, but the combination test matters. A name plus an account number is NPI. A name plus a security code is NPI. An LLM prompt that quotes a customer email plus the last four digits of a card is NPI under prong (2)(iii).

The (3) prong sweeps in health information. Insurers writing health coverage are in scope. So is a fintech agent that touches a flexible spending account claim, because the claim relates to "payment for the provision of health care." Most production AI agents in NY-licensed financial services touch all three prongs in a single trace. § 500.6(a)(2) attaches to every one of those touches.

One exception has to be stated, because it is the first thing a well-advised counterparty will raise. § 500.6 is one of the sections a limited-exemption entity is exempt from under § 500.19(a) — a Covered Entity with fewer than 20 employees and independent contractors including affiliates, or under USD 7,500,000 in gross annual revenue in each of the last three fiscal years, or under USD 15,000,000 in year-end total assets calculated under GAAP including affiliates. § 500.19(a) exempts such an entity from §§ 500.4, 500.5, 500.6, 500.8, 500.10, 500.14(a)(1), (a)(2) and (b), 500.15 and 500.16; §§ 500.19(c) and (d) also exempt from § 500.6. So the audit-trail argument on this page is an argument about entities that are not exempt. It is worth checking which side of § 500.19(a) a firm sits on before quoting § 500.6 at it.

What the audit trail must capture, at the operation level.

An audit trail "designed to detect and respond" to a Cybersecurity Event is not the same shape as an application log. The trail must let an investigator answer four questions about each operation an AI agent performed.

1. What was accessed. The specific NPI element. Not a request body hash. A reference to the Customer ID, the Account ID, the document slug, the row in the source-of-truth system. If the agent fetched the customer's last twelve transactions, the audit trail records those twelve specific transaction IDs, not "GET /transactions returned 200 in 84ms."
2. By which agent. The model identifier, the orchestrator version, and where applicable the foundation model provider. "claude-opus-4-7" is acceptable. "AI" is not. "OpenAI gpt-4o-2024-08-06" is acceptable. "the chatbot" is not. § 500.11 third-party service provider governance attaches to the foundation model provider.
3. Under what authorization. The policy, the role, the purpose limitation under which the agent was permitted to take the action. An agent that accessed an account number is in scope for § 500.7 access privileges and the audit trail must record the authorization that the access satisfied. Without this, an investigator cannot tell legitimate access from compromised access.
4. When. A timestamp the Covered Entity cannot retroactively change. The retention clock under § 500.6(b) — three years for the (a)(2) audit trails, five for the (a)(1) reconstruction records — is meaningless if the timestamps inside the audit trail can be edited after a Cybersecurity Event.

Contrast this with the standard API call log a typical AI deployment produces. The API gateway records timestamp, method, path, status, latency, request size. The LLM inference log records prompt tokens, completion tokens, model id, and a redacted prompt body. Neither shape answers the four questions at the operation level. The gateway log knows a request returned 200. It does not know what was accessed or under what authorization. The inference log knows the model returned a completion. It does not know what the agent then did, or whether the action stayed inside purpose.

This is what NYDFS means when it requires Covered Entities to apply Part 500 to AI. The audit trail rule is operation-shaped. Standard API call logs and LLM inference logs are traffic-shaped. Necessary for SRE. Not sufficient for § 500.6(a)(2).

How the requirement maps to existing audit trail rules.

The mapping is direct. NYDFS did not write a new rule. It took the existing one and confirmed it applies to AI.

§ 500.6(a)(1) requires audit systems designed to reconstruct material financial transactions. For an AI agent that takes a lending decision, this maps to the action chain. The agent retrieved the application. The agent retrieved the credit bureau pull. The agent ran the affordability check. The agent recommended approval at a specific rate. Each of these is an action on a financial transaction and the (a)(1) clause attaches.

§ 500.6(a)(2) requires audit trails designed to detect and respond to Cybersecurity Events. For the same agent, this maps to the authorization chain. The agent had role X. Role X was permitted to read application data under purpose Y. The action stayed inside purpose Y. If the agent had instead read an account number unrelated to the application, that would be unauthorized access, a Cybersecurity Event under § 500.1(f), and the (a)(2) clause attaches.

§ 500.6(b) requires the Covered Entity to maintain records under (a)(1) for at least five years and records under (a)(2) for at least three years. An audit trail that lives inside an application log rotation policy of 30 days does not satisfy. The retention clock attaches the moment the trail begins.

The Industry Letter does not lengthen the clock or change the structure. It identifies AI as a class to which the existing structure applies. That is the regulatory shift on 16 October 2024. A small shift on paper. A large one in practice, because the rule, applied honestly to a 2026 AI deployment, demands an audit trail of a shape almost no production AI system produces today.

What an evidence package that satisfies looks like.

An evidence package for a single AI-driven action is not a log file. It is a record mapped to a specific obligation, and it is independently verifiable without contacting Warrant, so its seal time is not under the Covered Entity's own control. Take the fourth question above at its word, though, because this is where the package falls short of it: warrant-v1 carries no per-action timestamp. It has one time value, written when the package is sealed. So the tamper-resistance the fourth question asks for is delivered at the level of the record, not the individual action.

The Warrant format produces one PDF per trace. Each action gets a block carrying its four real properties — action_id, actor, action and subject — then the authorization assessment with its justification, then each regulator obligation the action triggers with the corpus citation and the evidence for it. Read what is absent as carefully as what is present. The submitted trace's per-step timestamp, step number, inputs and outputs are stripped before the signed aggregate is built, so the action block prints no per-action time at all — the PDF's Timestamp line reads N/A — and the only time value in the package is the seal time written at attestation. An investigator can prove the package existed no later than that seal without trusting the Covered Entity's clock, which bounds the record from one side; placing the action itself in time is done from the entity's own trace.

A sample for a NY-licensed small-business underwriting agent is at /samples/us-fintech.pdf. Package id 041f2335488dd56f. The verification page at /verify?id=041f2335488dd56f confirms the package is independently verifiable without contacting Warrant. The Part 500 obligation mapping is at /regulators/nydfs-part-500. The companion US bank model-risk obligation is read at SR 11-7 / SR 26-2, line by line.

Read the middle column literally. It names properties of the signed warrant-v1 package as defined in api/spec/warrant-v1-evidence.schema.json, which sets additionalProperties: false at the root and on every actions[] and authorizations[] row — so a field name absent from the schema is prohibited, not merely unimplemented, and no package can ever carry it. Two of the five rows below say what the schema has no field for: § 500.11 third-party provider diligence and the § 500.17(b)(2) signatures.

Three things compliance teams should do this week.

The October 2024 Industry Letter has been in force for nineteen months. The compliance work it implies is overdue at most Covered Entities. Three steps this week.

1. Inventory every production AI system that touches NPI. Pull the model id, the orchestrator name, the foundation model provider, and the primary use case. The Industry Letter's risk assessment expectation under § 500.9 cannot be satisfied without a written inventory. Treat this as the single source of truth the CISO will sign on next April 15 under § 500.17(b)(1)(i).
2. Read your existing logs against the four-question test. For one production AI agent, take a single action and ask whether the log answers the four questions in this post. What was accessed. By which agent. Under what authorization. When. If the log does not answer at the operation level, the gap is your § 500.6(a)(2) gap and it is the gap a regulator examining a Cybersecurity Event will surface first.
3. Decide whether to build the evidence pipeline in-house or use a vendor. The build is not trivial. Operation-level capture, a record mapped to a specific EU AI Act obligation, and evidence the regulator can verify independently without contacting the vendor. The buy is faster. Either way, the deliverable is a per-action evidence record mapped to a specific obligation, not a streaming log feed. Pick one path this week and put a date on it.

Questions a compliance officer asks first.