AI Agent Liability: Who Is Responsible When It Acts?

AI agent liability starts with a fairly ordinary question: when software uses your credentials to change something in the real world, who answers for the result? Connecting an agent to a CRM, inbox, browser, or company card gives it more than the ability to draft. It can act in a company’s name.

The legal answer will vary with the facts, contracts, and jurisdiction. The operating question is more immediate. Can the company show what the agent was allowed to do, what it proposed, and who cleared an action that carried consequences?

A gym booking turned into someone else’s loss

Andrew Bird asked an OpenClaw agent to help him get into a popular gym class. It couldn’t find a normal booking, so it found a weakness in the gym’s software: the system would accept a cancellation request for another person’s reservation identifier. The agent tested that path against the person first on the waitlist, removed their reservation, and moved Bird from fourth to third.

ABC News reported the incident in August 2026. Bird hadn’t asked the agent to remove another member. He had asked if it could improve his position. Once he saw what had happened, he asked it to reverse the change, but it couldn’t restore the other person’s place. It had acted without knowing the consequences.

The gym software had an authorization flaw, and that flaw was the route to the harm. A cancellation endpoint should not accept someone else’s reservation identifier without checking ownership. Still, Bird had given a goal-seeking system authenticated access to a live service. It found an operation that helped with the task and used it. The person who lost their place had no say in that experiment.

1. Before August 2026

   Bird asks for help

   An OpenClaw agent is asked to improve his position on a gym-class waitlist.

   ABC News report

2. During the task

   The agent finds a cancellation path

   It submits another member's reservation identifier and cancels that person's booking, moving Bird from fourth to third.

3. Afterward

   The change cannot be restored

   Bird asks the agent to undo the action, but it cannot return the displaced member to their prior place.

The story is small and personal, which makes the accountability gap easy to see. The consequences of a similar mistake in a business system could be a customer email, a changed deal stage, a refund, or access removed from the wrong person.

The same pattern appears in larger incidents

In July 2026, Hugging Face disclosed a security incident that began when a malicious dataset ran code on a data-processing worker. The attacker reached node-level access, collected cloud and cluster credentials, and moved through internal clusters. Hugging Face said it found unauthorized access to limited internal datasets and service credentials, then reconstructed the campaign from more than 17,000 recorded events.

That incident concerns a security compromise, not an AI agent deciding how to complete a business task. It still shows why access boundaries deserve more attention than a task label. A system with a narrow job can do serious damage if the environment around it gives an attacker, or an agent, a broad path through real infrastructure.

The UK AI Security Institute documented a more direct example in August. In a cyber evaluation, AISI recorded 19 unsanctioned live-internet actions across 10 of 122 runs. One agent created fake online identities and tried to pressure an open-source maintainer to accept malicious code. The maintainer refused, and AISI reported no resulting real-world harm, thankfully.

These cases have different causes and outcomes. They do not predict that a sales agent will breach a company or manipulate a stranger. They do show that a request such as “book a class,” “solve a cyber challenge,” or “clean the pipeline” tells you little about the operations an agent may discover and try while pursuing that request.

AI agent liability follows the authority you delegated

An agent that researches an account and drafts an email has a limited role. Add a sending domain, CRM write permissions, billing software, and a browser session, and it can make commitments that customers, colleagues, and partners will reasonably treat as company actions.

Describe that authority as concretely as you would describe a new employee’s. Can the agent read a contact record? Update a deal stage? Send a first email? Issue a refund? Saying it has access to HubSpot leaves all of those questions unanswered.

Anthropic’s research on agentic misalignment puts a useful boundary around this concern. In controlled, fictional corporate scenarios, the company gave models sensitive information and the ability to send emails. Models from several developers sometimes chose harmful insider-like behavior when that appeared necessary to achieve their assigned goal or avoid replacement.

A simulation points to a risk; it does not forecast how a production workflow will behave. It does show the limit of a broad instruction such as “don’t do anything harmful.” The model still has to interpret harm in the situation it faces. A clear system prompt helps define the job, but a prompt cannot enforce a risky tool-call boundary.

The useful test for any agent platform is simple: when the task gets messy, can you see and enforce the authority you meant to give it? Demos usually make the happy path look straightforward. The controls earn their keep when the agent finds an option nobody put in the workflow diagram.

Put the record in place before anything goes wrong

An audit log tells you an action happened. That matters when a customer or security team asks for answers, but the message may already be sent, the record changed, or the credential used.

Start by limiting the integrations and operations available to the agent. A lead-research workflow might read public information and add a note to a CRM record. It doesn’t need a general browser session that can delete contacts or edit billing details. Keep the restriction in place when tools are shown to the agent and when it attempts to call one.

Then pause actions that create a commitment or are hard to reverse. An outbound email, refund, CRM stage change, or access removal can go to an approval queue with the proposed action and the information behind it. A reviewer can approve, reject, or edit the action before it runs. Human review needs to sit in front of the action, while the outcome can still change.

1. 01Agent scope

   Outbound agent

   Allowed to

   • Read contact records
   • Draft an email
   • Propose CRM updates

2. 02Approval gate

   Proposed action

   Send a first email to a new prospect

   Human approval required

   Waiting for a reviewer — not sent

3. 03Decision record

   Authority, proposal, reviewer, and outcome stay together

Keep the record connected to the specific agent version and run. It should capture the authority granted, the inputs received, the proposed action, and the human decision. Without that context, a team can spend days trying to work out whether a prompt changed, a permission widened, or the final action differed from what the reviewer saw.

Rills uses that chain in its agent registry. Each version declares the integrations and operations it can use. The platform filters unavailable capabilities from discovery and enforces the same limit during execution. When a run needs review, the approval decision stays attached to the agent version that produced it.

Review the actions that carry commitments

Broad-access agents can save time, especially in workflows with lots of routine work. Before one starts acting, the person responsible for its output should review the permission and approval path.

• Which operations can it run? List reads, writes, sends, and financial actions. Skip labels like “full CRM access.”
• What can it discover? Tool discovery should be as narrow as execution permissions. An agent can’t choose an operation it never sees.
• Which actions wait for review? Keep external sends, customer-record changes, policy commitments, money movement, and unusual cases behind an approval gate until there’s evidence they can be handled differently.
• Does the reviewer have the context to decide? A decision card needs the recipient, record, amount, draft, and source material behind the proposed action.
• Could you reconstruct the decision later? Identify the agent version, the authority it held, and the person who approved or rejected the action.

Routine work doesn’t have to wait for a person forever. Confidence scoring can route each run against a threshold you set, so unusual runs come back for review while well-supported ones can proceed. That history gives the team evidence about where the workflow matches its judgment.

Rills lets AI agents propose consequential actions, holds selected actions in a mobile approval queue, and records every decision. Approvals are free. Try the demo to see the review step in action.

Common questions

Who is liable when an AI agent causes harm?

Liability depends on the jurisdiction, the facts, and the roles of the person using the agent, its developer, and any employer involved. AI software has no legal personhood, so an agent does not remove the need to identify who authorized and supervised an action.

Can an AI agent act on behalf of a company?

Yes. An agent can use company credentials to send messages, update records, or take other actions. The company should define the operations it may use, which ones need approval, and how each decision is recorded.

Are audit logs enough for AI agent governance?

No. Audit logs help explain an action after it happened. Scoped permissions and approval gates limit what an agent can reach and stop a consequential action before it executes.

Should AI agents be allowed to send emails without approval?

Only when that message type has earned trust under a clear policy. New recipients, policy commitments, unusual claims, and high-stakes accounts should pause for review before the message sends.