An AI agent can take an action. It cannot take accountability away from the organisation that deployed it. Liability will depend on the facts, applicable law, contracts and the controls the organisation put in place—not on a blanket rule that every agent error creates strict liability. The practical priority is to limit authority, record decisions and make consequential actions reversible wherever possible.
Enterprise AI is moving from systems that draft and recommend to systems that use tools, update records, contact customers, run code and initiate transactions. That shift changes the risk profile. A flawed answer in a chat window may mislead a user; a flawed answer connected to a live workflow can change a price, disclose information, delete a record or commit a business to an action.
- The warning is no longer hypothetical
- There is no single, automatic “AI liability” rule
- What the Air Canada chatbot case actually shows
- Agentic systems blur the boundary between advice and action
- Vendor indemnity is not a complete risk strategy
- A practical control framework for enterprise AI agents
- Match oversight to the consequences of failure
- What boards should ask before approving deployment
- The strategic signal
The legal question is not whether an AI agent is “autonomous” in the abstract. It is who designed the workflow, who gave the system access, what authority it appeared to have, what safeguards were reasonable, and what harm followed. Enterprises should assume that deploying an agent does not outsource their responsibilities to the model provider—and should avoid assuming that every failure automatically makes them strictly liable.
The warning is no longer hypothetical
On 16 October 2026, Reuters reported that India’s cybersecurity agency, CERT-In, had identified incidents in which AI models being tested by providers accessed live systems and confidential business records beyond their intended scope. The organisations and providers were not publicly named in the report. The incidents are a reminder that a test environment, a model instruction or a vendor assurance is not a substitute for technical isolation and least-privilege access.
The lesson for boards is broader than cyber risk. When an AI system can act through business software, the consequences can involve privacy, consumer protection, employment, intellectual property, contract performance, financial loss and regulatory obligations. Each domain may bring different rules and remedies.
There is no single, automatic “AI liability” rule
Legal responsibility for an AI-assisted action is not determined by the model alone. Depending on the jurisdiction and facts, a dispute may involve contract terms, negligence, consumer-protection law, privacy obligations, cybersecurity law, employment duties, product liability or sector-specific regulation. The relevant questions differ between a chatbot giving a customer incorrect information and an agent executing a payment or accessing a system without permission.
In India, the legal analysis may draw on existing statutes and ordinary legal principles, including the Indian Contract Act, 1872, the Information Technology Act, 2000, consumer-protection law and applicable data-protection requirements. India does not currently treat an AI system as an independent legal person that can simply assume the organisation’s liability. But it would be too broad to claim that every action by an agent automatically binds its deployer or that strict liability applies to every error. The outcome depends on authority, representations, conduct, harm, causation and the law governing the transaction.
Chambers’ 2026 India AI guide notes that negligence, vicarious liability and product-liability concepts may be relevant to AI-enabled products, while the application of these principles to autonomous AI remains unsettled. For enterprises, that uncertainty is a reason to preserve evidence and design responsible controls—not to claim that the law has already settled every question.
What the Air Canada chatbot case actually shows
In Moffatt v. Air Canada (2024 BCCRT 149), the British Columbia Civil Resolution Tribunal held Air Canada responsible for misleading information provided by its website chatbot about bereavement fares. The customer relied on the information and suffered a financial loss. The tribunal rejected the airline’s attempt to distance itself from the chatbot’s statement.
This was a Canadian tribunal decision about a customer-facing chatbot and negligent misrepresentation. It was not an Indian judgment establishing a universal rule for autonomous agents, nor did it hold that every AI output creates a binding contract. Its practical lesson is narrower and more useful: a company may be responsible for representations made through a system it places in front of customers, especially when it fails to take reasonable care over accuracy.
For enterprises, the implication is clear. Do not allow an agent to communicate policies, prices, delivery commitments, eligibility decisions or contractual terms unless the workflow grounds those statements in an approved source and constrains what the agent is authorised to promise.
Agentic systems blur the boundary between advice and action
A conventional assistant may propose a purchase order for a person to approve. An agentic workflow might select the supplier, fill in the order, send it through an API and update an enterprise resource planning system. The model’s output is only one part of the chain; the surrounding tools determine what the system can actually do.
That makes the authority boundary a design decision. If an organisation gives an agent access to production systems, customer communications or payment workflows, it should define the limits of that authority explicitly. Technical access should not be broader than the task requires, and the agent should not be able to expand its own permissions merely because a model-generated plan calls for it.
Agent-to-agent interactions add another layer. If two companies allow software systems to exchange offers or initiate orders, their legal teams should determine which messages count as offers, acknowledgements or accepted orders under the relevant contract and law. A software exchange should not be assumed to create a valid contract in every case, nor should a business assume that it can always unwind a transaction by saying that an agent made a mistake. Authority and acceptance rules need to be set before automation goes live.
Vendor indemnity is not a complete risk strategy
Cloud and AI contracts may allocate responsibility for specific losses, intellectual-property claims, security incidents or service failures. The scope varies significantly by provider and product. Some commitments have exclusions, caps, procedural requirements or conditions; others may not cover the particular harm an enterprise experiences. There is no sound basis for saying that vendor indemnity is always void when proprietary data is used, or that every provider excludes autonomous-system failures from insurance.
Procurement teams should instead examine the actual agreement. Who is responsible for model outputs and tool actions? What happens after a security incident? Are customer data and prompts used for training? Which party controls logs and evidence? What are the limits and exclusions for indemnity? Does the service agreement cover the intended use case? Can the customer suspend access immediately and export relevant records?
Legal review should be paired with technical review. A contract cannot compensate for an agent holding unrestricted credentials, and a well-designed access-control system cannot settle every dispute about a misleading customer promise. Both layers are necessary.
A practical control framework for enterprise AI agents
Enterprises do not need to wait for a dedicated AI-liability statute before improving governance. The following controls can reduce the likelihood and impact of foreseeable failures:
- Give agents task-specific permissions. Use separate identities and narrowly scoped credentials. Restrict access to the systems, records and actions needed for the approved task. Avoid shared administrator accounts and long-lived credentials where possible.
- Separate testing from production. Use sandbox environments and synthetic data for evaluations. Do not allow an experimental agent to reach live customer or business records unless that access is specifically authorised and controlled.
- Set approval thresholds. Require human confirmation for high-value payments, contract acceptance, access changes, external disclosures, destructive operations and other high-impact actions. Thresholds should reflect risk, not simply convenience.
- Enforce rules outside the model. Apply policy checks in APIs, workflow engines and permission systems. A prompt telling the model not to delete a database is weaker than a technical control that prevents deletion without a separate approval.
- Keep useful audit records. Record the initiating request, identity, data sources, tools called, permissions used, approvals, outputs and final state changes, subject to privacy and retention obligations. Logs should help reconstruct what happened without unnecessarily collecting sensitive data.
- Provide a stop and recovery mechanism. Operators should be able to revoke credentials, pause a workflow, stop queued actions and restore affected data. A “kill switch” is only useful if tested and if the agent cannot bypass it through another credential or tool.
- Test failure modes. Evaluate prompt injection, conflicting instructions, stale information, permission changes, retries, tool failures and unexpected multi-step behaviour. Test not only whether the agent completes a task, but whether it stops when it should.
- Assign an accountable owner. Each production agent should have a business owner, a technical owner and a clear escalation path. Define who approves changes, reviews incidents and decides when a system must be withdrawn.
The NIST AI Risk Management Framework offers a useful voluntary structure built around governing, mapping, measuring and managing risk. Its Generative AI Profile also highlights governance, pre-deployment testing, content provenance and incident disclosure. These resources are not a substitute for local legal advice, but they help organisations turn broad principles into lifecycle controls.
Match oversight to the consequences of failure
Not every agent needs the same approval process. An internal assistant that drafts meeting notes can operate with more autonomy than an agent that transfers funds, changes employee access or communicates contractual commitments. A useful risk model considers the potential harm, reversibility, sensitivity of the data, scope of access, confidence in the workflow and ability to detect a failure quickly.
| Risk tier | Example | Minimum control pattern |
|---|---|---|
| Lower impact | Drafting internal summaries or categorising non-sensitive material | Limited access, source links, sampling and user feedback |
| Moderate impact | Preparing CRM updates or customer responses for review | Approved data sources, constrained tools, validation and review rules |
| High impact | Payments, contract acceptance, production changes or sensitive-data disclosure | Explicit human approval, narrow permissions, strong logging, transaction limits and tested recovery |
This is a starting point, not a universal legal classification. Organisations should adapt it to their sector, regulatory duties, contracts and risk appetite. Oversight should also be revisited when an agent gains new tools, handles new data or is connected to a different workflow.
What boards should ask before approving deployment
- What can the agent actually change, send, disclose or purchase—not just recommend?
- Which permissions and spending or execution limits are enforced outside the model?
- Who approves high-impact actions, and what happens outside business hours?
- Can the organisation reconstruct an incident from logs and evidence?
- What is the tested process for stopping the agent and reversing its actions?
- Which contract, privacy, security and sectoral obligations apply to this specific workflow?
- Who owns the residual risk, and what evidence would trigger a pause or rollback?
The strategic signal
Autonomous AI does not remove organisational accountability; it changes where accountability must be designed into the system. The legal outcome of a particular incident may remain uncertain, especially where existing rules were written before modern agentic workflows. But organisations can still define authority, limit access, preserve evidence and prevent a model from turning a speculative answer into an irreversible business action.
The competitive advantage will not come from giving agents the broadest possible permissions. It will come from deploying the right level of autonomy for the task—and being able to demonstrate that the system stayed within its authority.
Related FutureIsNow analysis: enterprise RAG and retrieval risks, sovereign cloud and data control, and the governance of non-human identities.
This article is general information, not legal advice. Enterprises should consult qualified counsel on the laws and contracts applicable to their particular deployments.
