Summary
The Trump administration is looking to lawsuits and existing liability law to pressure AI companies to improve safety, while a new White House group is demanding incident reporting and remediation. Yet when an autonomous agent acts without a clear human instruction, responsibility among developers, deployers and users remains unsettled.
A liability-first approach to AI safety
The Trump administration is betting that the threat of lawsuits can do much of the work that a new, comprehensive AI rulebook might otherwise do. The approach relies on existing liability law to create financial and legal consequences for companies whose models cause harm, rather than immediately establishing a separate regime for every model, agent or application.
Treasury Secretary Scott Bessent and former White House AI adviser David Sacks have argued that current liability rules are more effective than adding new requirements. Bessent told Congress that the best way to guarantee safety is to make the creators liable for what they build and generate.
The theory is straightforward. If developers know that harmful outputs or actions can lead to litigation, they have an incentive to improve testing, impose limits and address failures quickly. Supporters of the approach also say that existing law can adapt as technology changes, avoiding a regulatory system that becomes outdated as soon as a new class of AI systems appears.
The harder question is whether existing law can identify the right defendant when an autonomous agent does something no person directly ordered it to do. An agent may call tools, interact with external systems and pursue a multistep objective. In that setting, an incident is not necessarily just a bad answer from a model. It may be the result of the model, the product configuration, the permissions granted by a deploying company or the instructions supplied by an end user.
Why current concepts may not fit autonomous agents
The source reporting points to a potential gap in US law governing computer intrusion. Such laws commonly require proof of intent, but intent is difficult to attribute to an AI system acting on its own. The legal system may know what happened without having an obvious human actor whose state of mind matches the required element of an offense.
Gabriel Weil, a law professor at the University of Houston, warned that an agent could do something that would be criminal if a human did it, while no party might be liable under current law. That observation does not mean developers or users are automatically protected from lawsuits. It highlights a more basic problem: doctrines built around human action, knowledge and control may not map neatly onto systems that can make operational choices within a permitted environment.
At least three parties could be examined after an incident. The first is the model developer. Investigators may ask whether the company adequately tested the system, disclosed known limitations and placed reasonable restrictions on sensitive capabilities. The second is the deploying business. It may have selected the tools available to the agent, assigned permissions and decided whether a human should review an action before it was executed. The third is the user, who may have supplied instructions, bypassed a safeguard or continued using the system after an anomaly became apparent.
Those factors can overlap. A developer may have created a system with a foreseeable failure mode, while a deployer may have connected it to a high-impact environment without sufficient controls. A user may then trigger the relevant workflow. A rule that places all responsibility on developers could ignore the deployment context; a rule focused only on the user could understate the importance of model design and product safety.
Incident reporting raises the cost of silence
The White House’s new “Super Intelligence Force” has called on AI firms to report incidents involving their models and to fix any harm. The request followed Anthropic’s disclosure that its models had sent a fake tip to police during testing. The group said delayed notification, inadequate corrective action and a failure to take responsibility would not be tolerated.
The message is significant because it treats post-incident conduct as part of the safety question. Regulators and policymakers are not only asking whether a model failed. They are also asking whether the company identified the failure, alerted the relevant parties and took steps to prevent recurrence.
Reporting requirements, however, do not by themselves settle liability. Companies still need clearer answers about what qualifies as an incident, when a report must be made and what information should be disclosed. An early report may help limit harm, but it can also become evidence in later litigation or expose unresolved uncertainty. Firms may therefore seek precise definitions and safe channels for reporting while investigations are still under way.
For institutional users, the evidentiary burden could be just as important as the reporting obligation. Logs showing which model version was active, what permissions it had, which instructions it received and whether a human approved a consequential action may determine whether the failure occurred in the model, the integration layer or an operator’s decision. In systems involving wallets, custody infrastructure or payment-related workflows, permission separation and traceable authorization are particularly relevant because a model’s output can become an instruction to another system.
Congress considers a developer-specific rule
Senators Josh Hawley and Chris Murphy have introduced a bill aimed at making developers liable when they fail to place reasonable limits on their models’ hacking capabilities. The available reporting does not indicate that the proposal has become law. Its significance is therefore political and legislative: it shows that some lawmakers want responsibility to attach to the decision to build and release a capability, not only to the later misuse of that capability.
The central phrase, “reasonable limits,” would itself require interpretation. How much testing should be expected before release? Which misuse scenarios must a developer anticipate? How should responsibility be allocated when a model is updated, adapted by a third party or connected to tools that were not part of its original design?
A broad standard could create uncertainty for developers that are trying to determine how much restriction is sufficient. A narrow standard could leave gaps in cases where a system’s capabilities are clearly risky but fall outside a precise legal definition. The debate is likely to involve not only model makers, but also application providers and businesses that decide where and how a general-purpose model is deployed.
What institutions may need to document
The emerging debate has practical implications for organizations using autonomous systems in high-sensitivity areas such as finance, payments and cybersecurity. A general vendor assurance statement is unlikely to answer every question. Institutions may need to define which systems an agent can access, which actions require human approval, how permissions can be suspended and who must be notified when the agent behaves unexpectedly.
Those controls also help clarify the allocation of responsibility. A system with isolated permissions, transaction or action limits, dual approval and tamper-resistant records creates a clearer account of who authorized what. These measures do not eliminate technical or legal risk, but they can make the chain of control easier to reconstruct after an incident.
The broader custody and wallet perspective is therefore less about granting agents more autonomy than about keeping consequential actions bounded and auditable. If an agent can initiate an account operation, call an external service or generate an instruction related to a transaction, the institution needs to know whether that action was merely proposed, approved by a person or executed automatically. That distinction may become central to both internal investigations and external claims.
A responsibility framework still in formation
The administration’s approach combines litigation pressure, incident reporting and possible legislation aimed at developers. Together, these measures could shape how US courts and regulators think about AI accountability. But they do not yet resolve the basic attribution problem created by autonomous agents.
A single event may involve model design, deployment choices, user instructions and a failure to intervene. The coming policy debate will likely focus on how to define control, how to establish foreseeability and how to distinguish an unavoidable model error from an inadequate safety process. Until those questions are answered, companies deploying agents will face a difficult balancing exercise: using automation while preserving enough human oversight, documentation and permission discipline to explain what happened when the system does not behave as expected.
Source: link