AI Agents Place Orders Autonomously — Who Bears the Contractual Liability?

A Real Scenario That's Already Happening

Imagine this: you give an AI Agent a task — compare prices, select suppliers, and complete a purchase within your budget. The Agent autonomously searches for products, communicates with vendors, and submits an order. But you had no advance knowledge of which specific item was chosen or at what price. When the goods arrive, you realize it's not what you actually wanted.

So here's the question: can you argue that "I didn't personally place this order, it's not what I really wanted to buy, so I shouldn't be bound by the contract"?

Public cases of AI Agents autonomously completing purchases in production environments are still rare, making it difficult to give a one-size-fits-all answer. But based on existing legal frameworks, we can still conduct a systematic analysis of this scenario.

One fundamental premise must be established first: AI itself is not a civil legal entity and has no independent capacity to express intent. The contracting party is typically the individual or organization using the Agent — not the Agent itself. Electronic commerce rules have already recognized that when a party uses an automated information system to enter into or perform a contract, the resulting actions can be legally attributed to the party operating that system. This rule at least provides a starting point for analyzing AI Agent transactions.

Three Layers of Analysis: Contract Formation, Attribution, and Rescission

Disputes over AI Agent-placed orders can't be treated as a single question. The problem needs to be broken down into layers.

Layer One: Was a Contract Actually Formed?

Did the order sent by the system constitute a clear expression of intent to transact, and did the other party accept it? If an account completed the ordering and confirmation process on a trading platform, a contract may have formally been established.

Layer Two: Can the Transaction Be Attributed to the User?

Even if a contract was formed, the next question is whether it can be attributed to a specific individual or organization. This requires examining whose interests and authority the account that placed the order actually represented.

Layer Three: Can the Transaction Be Rescinded After Formation, and Who Bears the Loss?

This layer is the most critical — and the most commonly conflated. An Agent selecting the wrong product, making a poor price judgment, or an account being compromised are entirely different causes. Just because they all manifest as "the AI placed a wrong order" doesn't mean the same conclusion applies across the board.

Past instances of automatic order confirmation, auto-replenishment, or algorithmic trading typically operated on pre-written conditions. Today's AI Agents introduce an additional layer of autonomy: the user only needs to specify goals and boundaries, while the specific product, price, and timing are all chosen by the Agent during execution. But "not knowing the final outcome in advance" does not mean "the final outcome has nothing to do with you."

The Core of Attribution: Did the User Hand Over the Transaction Process?

If someone deliberately activated an AI Agent, granted it account access, payment authorization, and system permissions, and allowed it to make choices within a defined scope — then the key question is not "did the Agent want to buy this?" but rather whether the user already delegated the process of forming a transaction outcome to this system.

This judgment can be examined from four angles.

Who Initiated the Task?

Did the user proactively request a purchase, or did the system run automatically without any instruction? Was it a procurement Agent officially deployed by the company, or a tool an employee quietly integrated for personal convenience? The origin of the task directly affects whether the resulting action can be attributed to the individual or the organization.

What Permissions Did the Agent Actually Have?

If the Agent only had the ability to search and recommend — with a human still required to confirm — then the recommendation itself typically does not constitute placing an order. But if it had access to corporate accounts, digital certificates, or payment interfaces and could directly send orders externally, the legal weight of its external transactions is entirely different.

Did the Transaction Exceed the Predefined Scope?

Were the product categories, approved vendor lists, terms, and risk limits all within the authorized parameters? If a user simply dislikes the outcome and tries to deny the entire transaction by claiming "I didn't do it myself," that argument is unlikely to hold up.

Was the Transaction Outcome Subsequently Accepted?

This point is often overlooked but critically important. If the buyer received notification and raised no objection — or even accepted the goods, used the products, or continued demanding performance from the supplier — these actions often indicate that they effectively accepted the transaction. Conversely, if the system had just sent the order and the company immediately halted payment and stopped delivery, that behavior would also influence how courts assess the contract's status and the scope of any losses.

System Errors and External Attacks: Two Distinct Levels of Liability

If an AI Agent takes actions that clearly deviate from its task due to a system error, external attack, or abnormal permission configuration, the analysis shifts back to dimensions such as authorization scope, business-level cancellation, platform liability, and security management. Even so, it's not enough to look only at the final data.

Consider this example: a user asks the Agent to purchase office computers, but the Agent instead buys high-priced items due to hidden instructions embedded in a webpage. In this case, further distinctions must be made — did the counterparty know the order was clearly abnormal? Did the platform detect or block the anomalous request? Did the company grant overly broad payment permissions? Did the supplier violate agreed security standards?

Here is a critical distinction: whether an external transaction is binding on the company, and who ultimately bears the loss internally, are two separate questions. Even if a company must honor its contractual obligations to a supplier, that doesn't mean it must absorb the loss entirely. The company may still pursue indemnification from the platform, technology vendor, or relevant responsible parties under procurement system contracts, technical service agreements, internal management policies, or cybersecurity incident liability frameworks.

In practice, conflating these two levels leads companies to mistakenly use "the system malfunctioned" as a direct defense against suppliers, while simultaneously neglecting breach-of-contract claims against their technology service providers.

Fundamental Mistake and Evidence Preservation

These scenarios may also invoke the doctrine of "fundamental mistake" (重大误解), but this cannot be simplified to mean "the AI made a bad choice." If the product price and quantity were both within the authorized range and the model simply didn't select the optimal option, that typically resembles a business judgment call and does not affect the contract's validity. Only when the transaction content significantly deviates from the deployer's originally expressed intent — and the counterparty could reasonably have foreseen this — does rescission become a viable discussion. Whether rescission is possible still depends on the source of the error, the counterparty's state of knowledge, and case-specific evidence.

Finally, these scenarios impose very high demands on evidence preservation. Instructions, permission settings, authorization records, tools invoked, the complete communication trail between the account and the supplier, the order and payment process, and final notification or disposition records — all of these must be fully preserved. Without a clear record of the actual execution process, it becomes extremely difficult to explain why the system made a particular decision, where things went wrong, and how liability should be allocated.

From Outcome Back to Process

The liability challenges posed by autonomous AI Agent orders fundamentally require us to move from "the final result" back to the complete chain of "task, permissions, and control scope" when assigning responsibility. Who initiated the task, how much access was granted, whether the Agent exceeded its authorization, and whether the outcome was subsequently accepted — these facts collectively determine where liability falls.

A question worth exploring further: if an AI Agent exceeds its internal authorization, but the counterparty claims they had "reasonable grounds to believe it had authority," can the doctrine of apparent authority (表见代理) directly apply? This will be one of the deeper legal challenges in the evolving discussion around liability for automated transactions.