AI Incident Reporting Act Guide: H.R. 9477 Seven-Day Reporting Duties Explained

The United States has no federal duty for frontier AI developers to tell the government when a model resists shutdown, has its weights stolen or shows dangerous cyber capability, and H.R. 9477 would create one. Representative Nathaniel Moran (R-Texas) introduced the AI Incident Reporting Act on 25 June 2026. It would require developers of models designated by the Secretary of Commerce to report seven categories of "reportable activity" within seven days, with civil penalties of up to $2,000,000 per violation and each day counted separately. It is a bill, not law: as of November 2026 it had been referred to the House Energy and Commerce Committee with no further action recorded. This guide walks through the text, compares it with the state laws already in force, and sets out the detection and reporting capability a frontier developer, or an enterprise that fine-tunes covered models, would need. It is for AI security leads, incident responders and compliance owners.

Source note: provisions are taken from the introduced text of H.R. 9477 on govinfo.gov; cosponsors and status come from a legislative tracker (Quiver Quantitative). This is a bill, not law, as of November 2026. Confirm against the official text before relying on it. Compliance steps, decision guidance and checklists on this page are NHI Mgmt Group recommendations, not requirements of the text.

Key takeaways

• A bill, not law. H.R. 9477 was introduced on 25 June 2026 and referred to Energy and Commerce; a tracker lists three cosponsors and no action beyond referral.
• Commerce decides who is covered. There is no compute threshold in the text; the Secretary of Commerce would set capability or other thresholds and designate covered models within 180 days of enactment.
• Seven days, with expedited reporting for live harm. Developers report within seven days of knowing or reasonably believing reportable activity occurred, faster where harm is imminent or ongoing, and Commerce tells Congress within 48 hours.
• Security events are reportable, not only safety ones. Theft or attempted theft of model weights, unauthorised access by a model and offensive cyber capability are all on the list.
• Strong protections for reporters. Reports would be exempt from FOIA, could not be used as evidence against the developer and could not be used to regulate it, which is designed to encourage early, incomplete reporting.

Status and timeline

The bill sets no separate effective date; its clocks run from enactment. Recheck the status before relying on any detail.

Who would be covered

• Covered models: models designated by the Secretary of Commerce under capability or other thresholds that identify models which could pose significant risks to national security or public safety. The Secretary must give particular weight to whether a model can engage in, or presents a significant risk of, reportable activity.
• Covered model developers: any person or entity that develops or trains a covered model, or substantially modifies one, including through fine-tuning or other modification of the weights, in a manner meeting a threshold the Secretary sets. Enterprises that heavily fine-tune frontier weights could therefore become reporting entities.
• Model weights: parameters or internal artifacts sufficient to reproduce, substantially reproduce or enable operational use of the model, which captures partial copies and quantised variants, not only the original files.
• Who is not covered: deployers that only use a model through an API, unless designated. Their incidents would surface through the developer.

What counts as reportable activity

Category (F) is the most demanding for security teams: an attempted weight theft stopped by luck, for example a misconfigured attacker tool rather than your own controls, is reportable. That requires honest post-incident analysis of why something did not happen.

Reporting timing, content and protections

Clocks

• Initial report: within the period the Secretary sets and not later than seven days after the developer knows or reasonably believes reportable activity occurred.
• Expedited report: where activity presents imminent or ongoing serious harm; the bill sets no hour figure, leaving it to rulemaking.
• Supplemental reports: as additional material information becomes available.
• Congressional notice: the Secretary notifies House and Senate leaders and named committee chairs within 48 hours of receiving a report presenting imminent or ongoing serious harm.

Contents (to the extent known)

A description of the incident, behaviour or capability; the date or period of discovery; threat actors, attack vectors, vulnerabilities, safeguard failures and causal context; implications for national security or public safety; and anything else the Secretary requires. Section 2(e) tells the Secretary to allow reporting when facts are incomplete, which is the right model: report what you know at day seven, then supplement.

Protections

• Disclosure: exempt from FOIA under 5 U.S.C. 552(b)(3)(B) and from state or local disclosure laws.
• Privilege: submission does not waive trade secret, attorney-client or work product protection.
• Use bar: a report may not be received in evidence, subjected to discovery or otherwise used in civil, criminal or administrative actions against the submitter, and may not be used by any government to regulate the developer.
• Carve-outs: government may still use reports to respond to or prevent risks and to enforce the Act, and liability for the underlying conduct stays if established independently.

Enforcement and penalties

The Secretary of Commerce could issue orders, regulations and guidance, require records, carry out inspections, issue subpoenas and administer oaths, investigate, require corrective action and refer matters to the Attorney General. After notice and a hearing, civil penalties may not exceed $2,000,000, each day of a continuing violation is a separate offence, and penalty decisions weigh nature, gravity, duration, culpability, prior violations, good faith and mitigation. A late report on a weight theft would therefore accrue exposure daily.

How it compares with state frontier AI laws

The federal bill's list is broader than the state definitions in one respect: it reports capabilities and near misses, not only incidents that cause or risk harm. A developer covered by all three would need one internal classification that can feed different clocks. For state detail see the California AI Laws Guide and the New York RAISE Act Guide. Trade press placed the bill as a narrower alternative to the broader Great American AI Act discussion draft, which also routes critical safety incidents to Commerce.

What it means for AI agents and non-human identities

• Unauthorised access by a model is an identity event: category (A) covers a model obtaining unauthorised access. In practice that is an agent using a credential outside its scope or obtaining one it should not have. You cannot detect it unless every agent has its own identity and its access is logged. See the Agent Identity and Access Guide.
• Weight theft usually rides on a machine credential: service accounts, CI/CD tokens and storage keys with read access to weight buckets are the likely path. Scope them tightly, rotate them and alert on unusual reads. See Securing AI Model Weights.
• Resisting shutdown is tested at the identity layer: revoking an agent's tokens and network access is the reliable stop. See the AI Agent Kill Switch and Containment Guide.

Compliance steps: building the reporting capability

1. Map the seven categories to your detections. For each of (A) to (F), name the log sources, evaluation suites and alerts that would reveal it, and close the gaps.
2. Define "knows or reasonably believes". Write down who can make that call, and start the seven-day clock from the first credible signal, not from the end of the investigation.
3. Create one AI incident classification. Add categories for model behaviour, weight compromise and dangerous capability to the incident response plan, mapped to federal, California, New York and EU clocks. See AI Incident Management and Escalation.
4. Template the report. Pre-build the five content fields so a draft can be produced in hours. Adapt the AI System Incident Report Template.
5. Exercise it. Run a tabletop with a simulated weight exfiltration attempt and a simulated shutdown-resistance finding; measure time to decision and to draft.
6. Review near misses. Add a step to every post-incident review asking whether the outcome depended on your safeguards or on luck, since the latter is reportable under (F).
7. Prepare legal handling. Agree with counsel how privilege is preserved and how the report will be marked, while noting that statutory protections would only apply once enacted.

Decision guidance

Small developers should not assume they are out of scope: the bill uses capability as well as scale, so a small team with a highly capable fine-tune could be designated. Large organisations with several AI teams should centralise determination in one function so that the same event is not judged differently by different groups.

Open questions in the text

• Thresholds are undefined: everything turns on Commerce rulemaking within 180 days of enactment, so coverage cannot be known yet.
• The evaluation exclusion: behaviour elicited solely by an evaluation is excluded only under specified conditions, so red team results need careful handling to show they qualify.
• "Materially enable": categories (C) and (E) rely on a materiality judgement that guidance would need to make concrete.
• Expedited timing: the bill requires faster reporting for imminent or ongoing serious harm but leaves the hours to the Secretary.

Detection and measurement

Log and monitor reads of model weight storage by identity, egress from training and inference clusters, agent credential use outside declared scope, attempts by agents to alter their own configuration or guardrails, and evaluation results that cross internal capability thresholds. Metrics:

• Time to determination: hours from first signal to a "reasonably believes" decision.
• Time to draft: hours from determination to a complete initial report draft (target well under seven days).
• Weight access coverage: percentage of weight storage locations with per-identity access logging.
• Category coverage: number of the seven categories with at least one tested detection or evaluation.
• Near-miss reviews: percentage of security incidents in AI infrastructure with a documented safeguards-versus-luck assessment.

Common failure patterns

• Clock starts too late: teams wait for root cause before deciding, when the bill runs from knowing or reasonably believing.
• Weight copies outside inventory: fine-tuned or quantised copies on research buckets are still "model weights" under the definition and are often unmonitored.
• Shared agent credentials: when agents use human or shared tokens, a model's unauthorised access cannot be told apart from a user's.
• Evaluation results stuck in research: a dangerous capability finding that never reaches the incident process cannot be reported on time.
• Ignoring near misses: an attack that failed for reasons outside your controls is closed as "no impact" rather than reviewed.
• Separate processes per jurisdiction: parallel workflows for each law produce inconsistent facts across reports.

Framework mapping

Practitioner checklist

• Track H.R. 9477 and any Commerce threshold rulemaking if it is enacted.
• Decide whether any model you train or fine-tune could be designated as covered.
• Map each of the seven reportable categories to a detection or evaluation.
• Name who determines "knows or reasonably believes" and log the time.
• Inventory every copy of model weights and log access per identity.
• Give every agent its own scoped identity and alert on out-of-scope access.
• Keep a report template covering the five content fields.
• Add a near-miss question to every post-incident review.
• Align federal, California, New York and EU clocks in one classification.

Standards and references

• GovInfo: H.R. 9477, AI Incident Reporting Act, introduced text
• Benton Institute (Rep. Moran release): Rep. Moran introduces AI Incident Reporting Act
• Quiver Quantitative: H.R. 9477 bill status and cosponsors
• CSO Online: Proposed US law would make AI risk reporting a legal obligation
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls

Related NHI Mgmt Group resources: AI Incident Reporting Guide · Securing AI Model Weights · CIRCIA Incident Reporting Guide · AI Agent Liability Bills Guide. This guide summarises H.R. 9477 as introduced and is not legal advice.