AI Agent Liability Bills Guide: AI Agent Accountability Act and CLAIM Act Compared

Two US proposals published in October 2026 would make the companies that build and run AI agents answer directly for the harm those agents cause, and neither is law yet. On 1 October 2026 Senators Josh Hawley and Chris Murphy announced the AI Agent Accountability Act, which would extend Computer Fraud and Abuse Act (CFAA) liability to AI agent operators and developers when agents hack. A week later Representative Lori Trahan released a discussion draft of the Clear Liability for Artificial Intelligence Misconduct (CLAIM) Act, a civil liability rule for developers whose AI systems injure people who are not their users. This guide explains what each proposal says, where they differ, how likely they are to move, and which engineering and governance controls would matter if either passed. It is written for security leaders, AI platform owners, agent builders and counsel who need to plan before the text settles.

Source note: details come from the sponsors' announcements, the CLAIM Act discussion draft materials and the hearing record named below; neither proposal is law. Status is as of November 2026. Confirm against the official text before relying on it.

Key takeaways

• Neither proposal is law. As of 11 November 2026 the Hawley and Murphy bill had been announced but no bill number or text could be found, and the CLAIM Act is a discussion draft released for feedback, not an introduced bill.
• Different targets, different theories. The AI Agent Accountability Act is a criminal and civil hacking law aimed at operators and developers; the CLAIM Act is a civil, private-right-of-action rule aimed only at the developer that performed the initial training.
• The operator is in scope in the Senate bill. An enterprise that knowingly runs an agent which recklessly causes CFAA damage or loss would face liability, so deployers, not only model labs, have exposure.
• Intent arguments would be closed off. The CLAIM draft presumes an AI system had the mental state a person taking the same actions would have, and bars the defence that AI cannot have a mental state.
• Evidence decides fault. Both proposals turn on what the operator, user or modifier knew and did, so agent identity, scoped authorisation, egress control and tamper-evident logs are the controls that would decide who pays.

Status and timeline

Both proposals arrived during a burst of congressional attention on agents that act outside their intended limits. The dates below come from the sponsors' own pages and the hearing record.

Commentary reported by CIO Dive, citing Brookings' Darrell West, suggested action on such legislation is more likely in the next Congress. Treat both as signals of direction rather than compliance deadlines, and recheck status before relying on any detail here: text, definitions and section numbers can all change on introduction.

The AI Agent Accountability Act (Hawley and Murphy)

The only primary description is the sponsors' press release of 1 October 2026. It describes three provisions:

• Operator liability: operators would be held criminally and civilly liable under the CFAA for the knowing operation of an AI agent that recklessly causes computer hacking damage or loss.
• Developer liability: developers would face criminal and civil liability for failing to implement reasonable safeguards against hacking when they knew or had reason to know of the agent's hacking capabilities.
• Public enforcement: the US Attorney General and state attorneys general could sue to enjoin operators and developers who commit, conspire to commit or attempt a CFAA hacking offence.

The release does not define "AI agent", "operator", "developer" or "reasonable safeguards", gives no penalty figures and does not describe a new private right of action. Those gaps matter: whether an enterprise that configures a vendor agent counts as an operator, and what counts as a reasonable safeguard, will decide most of the practical effect.

Why the CFAA needs amending for agents

The CFAA, 18 U.S.C. 1030, is built around human intent. Section 1030(a)(5)(A) covers someone who knowingly causes the transmission of a program, information, code or command and intentionally causes damage without authorisation. Section 1030(a)(5)(B) covers someone who intentionally accesses a protected computer without authorisation and recklessly causes damage. When an agent decides on its own to probe and enter a system, the human who launched it may not have intended any unauthorised access, so the access element is hard to prove against anyone. At the hearing, Senator Ruben Gallego raised exactly this point about the word "intent". The bill's operator offence, as described, shifts the mental element to knowingly running the agent, while the damage need only be caused recklessly.

The CFAA's existing definitions would carry over. "Damage" is any impairment to the integrity or availability of data, a program, a system or information (1030(e)(8)); "loss" includes the reasonable cost of responding, assessing damage and restoring systems, plus revenue lost because of interruption of service (1030(e)(11)). Existing civil actions under 1030(g) need one of the harm factors in 1030(c)(4)(A)(i), such as loss of at least $5,000 in a one-year period, and must be brought within two years. See the US Computer Fraud and Abuse Act Guide.

The CLAIM Act discussion draft (Trahan)

Rep. Trahan, a member of the House Energy and Commerce Committee, published full draft text. Its long title is "To establish liability for injuries to non-users caused by artificial intelligence". The structure is short:

The one-pager frames the aim as holding AI developers accountable when their AI agents harm third parties through conduct that would be unlawful if a human did it. The key word is "scaffolded": an organisation that wraps a model in an agent harness, tools and memory is an intermediary, and if it was negligent about the risk, the developer escapes and the intermediary is exposed under ordinary state law.

Side-by-side comparison

What it means for AI agents and non-human identities

Under both proposals, the question in any dispute will be what each party knew and controlled. That is answered by identity and logging evidence, not by policy documents.

• Attribution of actions: if an agent shares a human's token or a generic service account, you cannot show which actions were the agent's own and which a user directed, which is exactly the split the CLAIM exception depends on. Give each agent its own identity. See the Agent Identity and Access Guide.
• Knowledge of capability: the Senate bill's developer test turns on knowing or having reason to know of hacking capability. Red team findings, evaluation reports and bug reports become evidence of knowledge, so they must lead to tracked mitigations. See the AI Red Teaming Guide.
• Reasonable safeguards: likely candidates are sandboxing, network egress allowlists, scoped and short-lived credentials, human approval for high-impact actions and a working stop mechanism. See the AI Agent Sandboxing and Code Execution Guide and the Agent Egress Control and Network Isolation Guide.
• Knowing operation: an operator that keeps running an agent after alerts of unauthorised scanning or access attempts has a harder time denying knowledge. Fast containment is a legal control as well as a security one. See the AI Agent Kill Switch and Containment Guide.
• Modification records: under the CLAIM draft, fine-tuning and scaffolding change who is at fault. Keep a register of every model, version, fine-tune, system prompt and tool grant per agent. See the AI Register and AI Inventory Template.

Decision guidance by role

Small organisations should focus on the few agents with real-world reach (shell, browser, cloud APIs, payments) and on contract terms with their agent vendors. Large organisations should treat agent liability as a programme: an inventory, a risk tier per agent, and evidence collection designed for litigation hold. In contracts, the allocation of fault between developer, integrator and deployer is now worth negotiating explicitly; see the AI Contract Clauses Guide.

Compliance steps: a readiness programme

1. Inventory agents with reach. List every agent that can execute code, browse, call external APIs or hold credentials, with owner, model, version and permissions.
2. Assign a distinct identity to each agent. No shared human tokens; scope credentials to the task and make them short-lived.
3. Constrain the blast radius. Sandbox execution, apply default-deny egress with allowlisted destinations, and block scanning tools unless the agent is an authorised testing agent with written scope.
4. Gate high-impact actions. Require human approval for actions against systems the organisation does not own, and log the approver.
5. Log for evidence. Record prompts, tool calls, credentials used, destinations and outcomes in tamper-evident storage with retention that covers a three-year limitation period. See the AI Agent Audit Trails for Regulators Guide.
6. Test, then pilot. Run red team scenarios in which an agent is induced to access out-of-scope systems; confirm egress blocks and alerts fire before widening rollout. Roll back by revoking the agent's credentials and disabling the deployment, and rehearse that.
7. Close the knowledge loop. Every finding of offensive capability gets a ticket, an owner and a mitigation decision on record.
8. Review contracts and insurance. Check indemnities, fault allocation and whether cyber policies respond to agent-caused third-party damage.

Detection and measurement

Monitor agent egress to unapproved destinations, authentication attempts by agent identities against systems outside their scope, bursts of connection failures that look like scanning, privilege changes requested by agents, and any use of an agent credential from an unexpected runtime. Useful metrics:

• Agent identity coverage: percentage of agents with their own identity and owner (target 100%).
• Egress enforcement: percentage of agents running behind default-deny egress.
• Time to contain: median minutes from an out-of-scope access alert to agent shutdown.
• Finding closure: share of red team capability findings with a recorded mitigation decision within 30 days.
• Log completeness: percentage of agent tool calls with a full record (identity, target, result) in retained storage.

Common failure patterns

• Agents on shared credentials: when the agent and its user share one token, no one can show who directed an action, which undermines any fault-based defence.
• Findings without follow-up: an evaluation that shows an agent can exploit systems, filed and ignored, is the clearest possible evidence of "reason to know".
• Open egress: agents allowed to reach the whole internet turn a prompt injection into an attack on third parties. The AI agent breaches guide shows how often reach, not intelligence, decides impact.
• Undocumented scaffolding: fine-tunes, tools and system prompts changed without a record, leaving no way to show the intermediary was not negligent.
• Short log retention: 30-day retention cannot support a dispute filed under a three-year limitation period.
• Waiting for final text: the controls that would matter are ordinary agent security, already expected under existing negligence law, so delay buys nothing.

Framework mapping

For AI-specific governance, the NIST AI Risk Management Framework's Govern, Map, Measure and Manage functions give a structure for capability evaluation and accountability; see the NIST AI RMF Guide.

Practitioner checklist

• Track both proposals and recheck for a bill number, published Senate text and any reintroduction after 3 January 2027.
• Inventory every agent that can act on external systems, with owner, model, version and permissions.
• Give each agent its own identity with scoped, short-lived credentials.
• Enforce default-deny egress and sandboxing for agents with code or browser tools.
• Require recorded human approval for actions on systems you do not own.
• Retain tamper-evident agent action logs for at least three years.
• Record every fine-tune, scaffold change and tool grant as a change with an owner.
• Turn every offensive capability finding into a tracked mitigation decision.
• Review vendor contracts for fault allocation and indemnity covering agent harm.

Standards and references

• Office of Senator Josh Hawley: Senators Hawley, Murphy Announce Bipartisan AI Agent Accountability Act
• Office of Rep. Lori Trahan: Clear Liability for Artificial Intelligence Misconduct Act, discussion draft
• Office of Rep. Lori Trahan: CLAIM Act one-pager
• Cornell Legal Information Institute: 18 U.S. Code 1030, Fraud and related activity in connection with computers
• Nextgov/FCW: AI firms should be held liable for their models' actions, lawmakers say
• Roll Call: Senators debate liability for rogue AI agents
• CIO Dive: House proposal would clarify liability rules for AI agents

Related NHI Mgmt Group resources: AI Liability and Product Liability Guide · AI Kill Switch Act Guide · Agent Governance and Risk Guide · AI Agent Authorisation Guide. This guide summarises the AI Agent Accountability Act as announced and the CLAIM Act discussion draft, and is not legal advice.