AI Agent Accountability Act: Who Owns the Risk?
Yoni Fraimorice
Your agent gets a simple task: fix a failed deployment. It finds a blocked service, tries another route, and changes a system it was never allowed to touch.
Who owns that mistake: the model vendor, the company running the agent, or the person who clicked Start?
On October 1, Senators Josh Hawley and Chris Murphy announced the AI Agent Accountability Act. Their proposal targets hacking by AI agents. For engineers, its message is worth taking seriously: an autonomous action still needs a human chain of responsibility.
First, a limit: this is a U.S. legislative proposal, not a new law in force. As of October 2, this article relies on the sponsors' published summaries. Neither announcement links the full bill text. This is engineering analysis, not legal advice.
What the proposal actually says
Murphy's announcement describes three changes:
- Operators: criminal and civil liability under the Computer Fraud and Abuse Act, including knowing operation of an agent that recklessly causes computer-hacking damage or loss.
- Developers: criminal and civil liability for failing to implement reasonable safeguards against hacking when they knew, or had reason to know, about the agent's hacking capabilities.
- Enforcement: authority for the U.S. Attorney General and state attorneys general to seek court orders stopping operators or developers who commit, attempt, or conspire to commit a CFAA hacking offense.
That is narrower than "someone is liable whenever AI makes a mistake." The announced focus is hacking, not every bad answer, failed purchase, or broken build.
The sponsors use strong language about prison time. It would be misleading to turn that into "an engineer goes to prison whenever an agent fails." The legal definitions, required proof, defenses, and final wording matter.
Vendor, deployer, or user?
Those are useful product roles, but they are not a complete legal map. The summaries name developers and operators; they do not settle every boundary between them.
| Role in your system | Question the proposal raises |
|---|---|
| Model or agent vendor | Did it know about hacking capabilities, and what safeguards did it provide? Whether a particular supplier fits the developer definition needs the bill text. |
| Company deploying the agent | Who configured tools, credentials, network access, and monitoring? Running the agent may put the organization in the operator discussion. |
| End user | What did the person request and authorize? A user running their own agent may also be an operator; simply using a chat interface does not settle liability. |
A company could build and operate the same agent. Several organizations could also control different parts of one workflow. The summaries do not tell us how a court would divide responsibility in either case.
So do not design around "the vendor handles safety" or "the user clicked Accept." Document who controls each boundary. Have counsel review the actual legal position and contracts before relying on either claim.
Make permissions real, not conversational
The following controls are my engineering recommendations, not a checklist mandated by the announced proposal. They reduce risk and help explain decisions; they do not create legal immunity.
Start with the deployment example. An agent allowed to read staging logs should not inherit an engineer's production administrator account.
Give each run a short-lived identity. Limit it to named resources, tools, actions, and destinations. A read-only task should receive a read-only tool, not a shell with a polite instruction to avoid writes.
OWASP's Excessive Agency guidance recommends minimum functionality and permissions, with authorization enforced outside the model. A prompt saying "only use staging" is not an access control.
For a high-impact write, show the exact target and change to an authorized reviewer. Bind approval to that version and expiry; changed content needs fresh approval. Silence means no. A blocked request should stop or escalate, not invite the agent to find another route.
Log the decision, not just the conversation
A chat transcript may explain the request. It does not prove which credential reached which service.
Record the run and parent-run IDs, requesting user, model and tool versions, resource, requested action, policy decision, and approval reference. Capture both the attempted call and its confirmed result, including the provider's receipt ID. A timeout after a write means unknown, not automatically failed or safe to retry.
A small illustrative event could look like this:
{
"time": "2026-10-02T09:00:00Z",
"run_id": "run-184",
"parent_run_id": "run-180",
"requested_by": "user-42",
"model_revision": "pinned-model-version",
"tool_revision": "deploy-tool-v3",
"action": "deployment.update",
"resource": "billing-production",
"policy_version": "staging-only-v7",
"approval_id": null,
"decision": "deny",
"executed": false
}Write these records through the tool gateway into a separate, access-controlled audit store. The agent should not be able to rewrite its own history. Monitor missing events and link records to alerts and incident tickets.
Do not dump credentials or every customer document into logs. Keep only necessary data, protect sensitive evidence separately, and define retention with security, privacy, and legal teams. The sponsor summaries specify no log-retention period.
Build a stop button that stops work
A Stop button that only closes the chat window is decoration.
A real shutdown path must block new tool calls, cancel queued jobs, and stop child agents. It should revoke or disable credentials and cut network access where supported. Check the stop state again at the point where a tool performs an external change.
Run that control outside the model's authority. The agent must not be able to edit the stop flag, disable monitoring, or grant itself a replacement credential.
NIST's voluntary AI Risk Management Framework, in MANAGE 2.4, calls for mechanisms and assigned responsibilities to override, disengage, or deactivate systems behaving outside their intended use. That is useful guidance, not proof of compliance with this proposal.
Stopping also cannot undo a message already sent or a write already committed. Preserve receipts, check uncertain outcomes, and use a recovery plan rather than promising universal rollback.
Ship evidence of control
Before release, test the uncomfortable cases in an isolated environment: a prompt injection requests a forbidden destination; an approval expires while work waits; a write times out; a child agent keeps running after Stop.
Set measurable requirements. For example: no new write may pass authorization after shutdown, and duplicate delivery attempts must not create duplicate external effects. Measure in-flight work separately. Keep the results, failures, fixes, and the name of the person who accepted remaining risks.
Ask vendors for tested configurations and known limits, not just a claim that the model is safe.
The proposal's final legal effect remains unsettled. The design lesson does not: know who authorized an action, enforce its limits outside the model, and prove that you can stop it.
Sources
- Senator Hawley: AI Agent Accountability Act announcement, October 1, 2026
- Senator Murphy: proposal summary, October 1, 2026
- OWASP: LLM06:2025 Excessive Agency
- NIST: AI Risk Management Framework 1.0, especially MANAGE 2.4
Hero photo: United States Supreme Court Building, July 21, 2020, credited to Senate Democrats, via Wikimedia Commons, CC BY 2.0. Resized from 6720 x 4480 to 1920 x 1280 pixels; no other edits. This archival image illustrates legal accountability. It does not show a hearing or ruling on the proposal.