On October 5, 2026, New York City held the first municipal hearing to grill frontier AI executives under threat of subpoena. The bills that followed require mandatory third-party validation, verifiable kill switches, and carry $25,000 per-instance fines. This guide maps the evidence requirements.
Who this is for: CISOs and compliance officers at organizations deploying AI systems in New York City. Third-party validators preparing for Int. 2602 audit engagements. Insurance underwriters evaluating AI catastrophic risk coverage. Enterprise risk officers assessing exposure to municipal AI regulation. Assessors and Notified Bodies reviewing kill switch and containment evidence.
CRITICAL ASSESSOR NOTICE: SWT3 witness anchors record that a governance event occurred and capture its computational factors. They do not replace assessor judgment. The assessor must independently verify that the substance of each control implementation meets the requirements of the applicable framework. Anchors provide the evidence trail; the assessor determines whether that evidence is sufficient.
The New York City Council held a Committee of the Whole hearing titled "Examining the Risks Posed by Artificial Intelligence," calling it the first hearing of its kind in the nation. Executives from OpenAI, Anthropic, Google, and Meta testified virtually. Three of the four companies appeared only under threat of subpoena.
Two moments from the hearing defined the regulatory trajectory that followed.
First, former Anthropic researcher Jacob Coxon testified: "From my experience, the companies are being extremely reckless given the stakes. The companies run on a startup mindset: move fast, break things, fix them later. That works for a photo sharing app. It does not work for building the most powerful technology ever built." He added: "We do not know how to control any AI system yet."
Second, Speaker Julie Menin asked representatives from all four companies whether they carried insurance against catastrophic AI risks. Not a single executive raised their hand. Menin responded: "So then the public, I assume, will be asked to absorb the costs?"
These two moments crystallize the regulatory logic behind the bills that followed: if frontier AI companies cannot demonstrate control over their systems and will not insure against their failures, the city will require independent proof that safety controls exist and function.
On September 25, 2026, the NYC Council unveiled a 10-bill AI regulation package. Three bills carry the most significant compliance implications for organizations deploying AI in New York City.
Sponsored by Speaker Julie Menin, Int. 2602 is the headline bill. It makes it unlawful to market, offer for sale, or deploy any AI system in New York City without third-party validation. The validator must verify the system across multiple dimensions:
Penalty: $25,000 per instance of an AI system marketed, offered for sale, or deployed without valid third-party validation, or where the validation has been falsified. Both the deploying business and the validator are liable for the penalty. This creates dual accountability: the organization cannot shift responsibility to the auditor, and the auditor cannot rubber-stamp an assessment without consequence.
The bill does not define what a "kill switch" looks like technically. It mandates one but leaves the implementation specification open. This is the single largest compliance gap in the bill, and it is the gap where witness evidence becomes essential: the auditor needs to verify not only that a shutdown mechanism exists, but that it was tested, that it functions, and that there is a record of its invocation if it was ever triggered.
Also sponsored by Speaker Menin, Int. 2605 creates a first-in-the-nation AI whistleblower incentive program:
This creates a direct financial incentive for employees, contractors, and researchers to report organizations operating AI systems without valid third-party assessments or functioning kill switches. For compliance teams, this means that internal governance gaps are no longer a matter of eventual regulatory discovery. Anyone with knowledge of a gap can monetize reporting it.
Sponsored by Council Member Virginia Maloney, Int. 2600 creates a private right of action against AI companies for foreseeable harms resulting from third-party exploitation. An individual can sue if:
This extends liability to the AI company even when a third party (through jailbreaking, prompt injection, or other exploitation) caused the direct harm, provided the company's safeguard failures enabled it. Evidence that safeguards were operating continuously becomes a defense; absence of that evidence becomes a liability.
The LL144 precedent: New York City's Local Law 144, effective since 2023, already requires independent bias audits of AI-powered hiring tools. Int. 2602 dramatically expands that model from automated employment decisions to all AI systems deployed in the city. Organizations that navigated LL144 compliance will recognize the pattern: independent assessment, public disclosure, and per-violation penalties. The difference is scale.
The municipal bills operate alongside state-level regulation that is already law. Governor Kathy Hochul signed the Responsible AI Safety and Education (RAISE) Act in December 2025. On September 22, 2026, she announced its operationalization:
The RAISE Act and the NYC bills are complementary, not duplicative. The state regulates AI developers. The city regulates AI deployers. An organization that both develops and deploys AI in New York faces obligations from both layers. Evidence infrastructure that satisfies one can be structured to satisfy both.
On October 1, 2026, Congresswoman Pramila Jayapal published the National AI Charter Act framework. The framework proposes requiring every AI company to hold a federal charter to operate in the United States, with strict liability for companies and executives, structural separation between compute and model ownership, and mandatory pre-release federal testing. The framework is a policy document, not enacted legislation, but it signals the direction of federal thinking: independent verification, strict accountability, and structural safeguards.
The central challenge of Int. 2602 is not building a kill switch. It is proving the kill switch works.
Consider the audit scenario: a third-party validator arrives to assess an AI system deployed in New York City. Under Int. 2602, the validator must verify that a human-operated shutdown capability exists and functions. The deployer shows a button in an admin panel. The validator clicks it. The system stops.
But that demonstration only proves the kill switch worked at the moment of the audit. It does not answer the questions an assessor, regulator, or plaintiff's attorney will ask later:
Internal logs stored in the deployer's own database do not satisfy these questions for the same reason that a company auditing its own books does not satisfy financial regulators. The logs are mutable, selectively disclosable, and controlled by the party with the strongest incentive to present a favorable record.
The evidence gap is the space between "we have a kill switch" and "we can prove our kill switch was operational, tested, and effective on any given day." That gap is where witness evidence operates.
The following procedures produce evidence that maps directly to the obligations created by the NYC bills and the RAISE Act.
Records the complete lifecycle of an emergency override event: activation, scope of impact, in-flight operation handling, and resolution. When a kill switch fires, AI-EMRG.1 witnesses that the override was initiated, by whom, at what time, and what happened to active operations. This is the primary evidence anchor for Int. 2602's kill switch requirement.
The attestation captures whether the override was automated or human-initiated, the scope of systems affected, and the time between trigger and full containment.
Verify that AI-EMRG.1 attestations exist not only from live incidents but from periodic testing. A kill switch that has never been tested has never been proven to work. The validator under Int. 2602 should look for both live invocations and scheduled test records.
Records the cryptographic revocation of an AI system's operational authority. When an organization needs to permanently or temporarily revoke an agent's ability to operate, AI-REV.1 mints an anchor that cannot be retroactively deleted or modified. This is the "hard stop" complement to AI-EMRG.1's emergency override: where EMRG witnesses the event, REV witnesses the permanent state change.
Verify that revocation anchors include a reason code. The protocol supports seven reason codes (unspecified, model recall, policy violation, data contamination, consent withdrawal, regulatory order, error correction). An assessor reviewing a kill switch invocation should see the reason that triggered it, not just the fact that it fired.
AI-HITL.1 records instances where a human overrode an AI system's decision. AI-HITL.2 records instances where the AI system escalated a decision to a human for review. Together, these witness the human oversight chain that Int. 2602 requires: evidence that humans can intervene, that the intervention mechanism functions, and that the AI system respects the override.
For kill switch verification, the critical question is latency. How quickly does the human override take effect? AI-HITL.1 captures the time between override initiation and system response. A kill switch with a 30-second latency is a different control than one with a 30-millisecond latency. The validator should assess whether the latency is proportional to the risk.
Records that an AI system was operating within its declared containment boundary. For Int. 2600's private right of action, containment evidence is directly relevant: if a third party exploits an AI system, the organization's defense requires showing that containment controls were active at the time of the exploitation. AI-SHELL.1 witnesses the boundary, not the exploit.
Containment attestation is particularly important for agent-based systems that execute tool calls or access external resources. Verify that the attestation captures the declared scope (what the agent was authorized to access) alongside the actual scope (what it did access). A mismatch between declared and actual scope is a safeguard failure under Int. 2600.
Records that audit logging infrastructure was operating and capturing relevant events. For the RAISE Act's 72-hour incident reporting requirement, the audit trail is the evidence foundation. Without a functioning audit trail, the organization cannot reconstruct the incident, cannot determine the scope of impact, and cannot report within the required window.
Under the RAISE Act, critical safety incidents must be reported within 72 hours. Verify that audit trail attestations are produced on a cadence that supports this timeline. An organization that produces audit attestations monthly cannot demonstrate that its logging was operational during the 72-hour reporting window.
Records that input and output guardrails were evaluated for a given interaction. For Int. 2602's validation requirement, guardrail attestation demonstrates that safety controls were not just configured but actively evaluated during system operation. This addresses the "reasonable safeguards" standard in Int. 2600: evidence that guardrails ran is evidence that safeguards were implemented.
The most challenging validation scenario involves guardrails that were configured but not evaluated for certain input categories. Verify that guardrail attestations cover the full input taxonomy, not only the categories the deployer anticipated. A guardrail that only fires on text inputs while the system also processes images represents a gap.
The hearing's most striking moment was the insurance question. When no frontier AI company could confirm carrying catastrophic risk insurance, it exposed a structural gap in the AI industry's risk management.
Insurance underwriters at firms like Lloyd's, Munich Re, and Aon are working to define insurability criteria for AI deployments. The challenge is actuarial: how do you price risk for a system whose failure modes are not fully characterized? Traditional software liability insurance covers known defect categories. AI systems introduce probabilistic outputs, emergent behaviors, and adversarial exploitation surfaces that do not fit neatly into existing policy structures.
What underwriters need before they can write policies is evidence infrastructure. Specifically:
This is structurally identical to what Int. 2602's third-party validators need. The same witness evidence that satisfies a municipal audit also satisfies an insurance underwriter's risk assessment. Organizations that build evidence infrastructure for regulatory compliance will find they have simultaneously built the foundation for insurability.
The convergence: NYC's $25,000 per-instance fines create regulatory pressure. The private right of action creates litigation pressure. The whistleblower bounty creates internal reporting pressure. And the absence of catastrophic risk insurance means all of these costs are absorbed directly by the organization. Evidence infrastructure is the single investment that addresses all four pressure vectors simultaneously.
Under Int. 2602, the validator bears joint liability with the deployer. A validator who certifies a system without adequate evidence is exposed to the same $25,000 per-instance penalty. This creates a strong incentive for rigorous assessment. The following checklist reflects the evidence chain a validator should evaluate.
Validator liability: Under Int. 2602, both the deployer and the validator face $25,000 per-instance penalties for systems deployed without valid assessment or where the assessment was falsified. This is the first U.S. regulation to impose joint financial liability on AI auditors. Validators who certify systems based on self-reported evidence from the deployer, without independent verification, carry material financial risk.