DSCI proposes that liability for AI agent harm should follow control
India's DSCI floated a discussion paper on 4 November 2026 saying liability for AI agent harm should follow who controlled key decisions.
The Data Security Council of India (DSCI) has published a discussion paper, "AI Liability: Industry Guidance for Agentic AI", proposing that responsibility for harm caused by AI agents should follow whoever controlled the key decisions, Inc42 reported on 4 November 2026. The paper is open for industry feedback and applies existing law, contracts and sector rules rather than creating a new regulatory framework. For banks, fintechs and any firm letting software act on its behalf, it is an early sign of how Indian industry bodies want blame to be shared when an agent gets something wrong.
What the paper proposes
Inc42 described the paper as a proposal that invites comment from AI developers, industry members, policy think tanks and other stakeholders. It is a discussion paper from an industry body, not a law or a regulator's rule, and it does not bind anyone. DSCI's approach, as reported, is to apply existing legal ideas to agentic AI: duty of care, product liability, causation and comparative negligence. Duty of care is the obligation to take reasonable steps to avoid harming others. Causation asks whether a party's act actually led to the harm. Comparative negligence splits the blame when more than one party was at fault.
The central idea is that liability should "follow control". DSCI argues liability should not rest only with the company deploying an AI agent or only with the technology supplier. It should lie with whoever controlled the key decisions: model selection, system configuration, tool access, permissions and human oversight. To work that out, the paper proposes an "authority map", a record of who controlled a particular decision and whether they could have prevented or limited the harm.
Why agents change the question
Inc42's summary of the paper draws a line between ordinary generative AI and agentic AI. Generative AI mostly produces outputs, such as text, for a human to review. An AI agent can plan tasks, use tools, call software interfaces (APIs) and carry out instructions with limited human intervention. That raises the risk of unauthorised transactions, incorrect payments and data breaches. The risk grows when several agents interact or hand tasks to each other across organisations, because one error can cascade.
The paper identifies 12 areas of potential harm, including privacy breaches, security threats, discrimination, safety risks, inaccurate outputs, intellectual property violations, deepfakes, loss of control and AI-enabled cybercrime. It also lists operational reasons why liability is hard to assign: models change behaviour over time, agents make autonomous decisions, human approvers get tired of approving, tasks are delegated between agents, and it can be difficult to reproduce how a system reached a given action.
Who is responsible for what
The paper splits the supply chain into groups. End-user organisations choose the use cases, set permissions, assess operational risks and decide when a human must approve. Service providers and integrators are responsible for system design, approval mechanisms and handling failures. Product companies and startups answer for product claims, default settings and model versions. Tool and framework providers are accountable for the orchestration, memory and safety features they supply. Cloud and infrastructure providers are responsible for isolation, identity management, data retention and platform logs.
Model providers are treated separately. They are responsible for the capabilities they develop, safety measures, disclosure of known limitations and notice of significant changes in model behaviour. Their liability could shrink when other parties control how the model is deployed and used.
The type of model matters too, in Inc42's account. A company that runs an open-source or open-weight model on its own infrastructure takes on more responsibility for auditing, modifying and monitoring it. A company that uses a closed model through a managed API may seek recourse against the model provider through its contract, subject to the contract's terms and any liability cap.
On safeguards, the paper recommends six safeguards: remove unnecessary capabilities; restrict system permissions; require human approval for significant or irreversible actions; monitor AI behaviour; let systems scale back operations safely; and deploy kill switches with clearly defined ownership. It also recommends that organisations assess risks before deploying agents, put liability provisions in procurement contracts, and review their safeguards regularly.
A simple analogy helps. Give a new employee access to the company bank account and a rulebook. If they wire money to the wrong place, you would ask who gave them access, whether a second signature was required, and who was watching the account. The paper turns those questions into a checklist for software.
What it means for firms and customers
For a bank, lender or fintech starting to use agents, the paper reads as a to-do list that regulators and courts may later use as a yardstick, even though it is not binding. Contracts with AI vendors are the first place where it bites: the paper's advice to include liability clauses means buyers should ask who pays when an agent makes an unauthorised payment, and whether a liability cap would cover it. Smaller vendors may find that buyers push more risk onto them in contracts.
For startups that build agents, "liability follows control" cuts both ways. Offering generous default permissions and weak oversight puts more of the responsibility on the product company. Offering narrow permissions and clear approval steps shifts some of it to the customer who chose to widen them.
For ordinary customers, nothing changes yet. But the paper is part of a conversation about what happens when an AI assistant that can pay or place orders makes a mistake: the customer wants a clear answer on who refunds them. A rule of thumb from the paper is that the party who could have prevented the harm and had the authority to do so is the one first looked to.
Human approval is one safeguard with a real cost. The simulator below estimates the reviewer time that approval requirements create. The inputs are examples chosen by this desk, not figures from the paper.
What is not known
The paper's text was not opened by this desk; everything here comes from one Inc42 article, so exact wording, the comment deadline and the full list of harms are unconfirmed. Inc42 itself mixes "six groups" and "six-stage approach" in its summary while listing five groups plus model providers and six safeguards. The paper does not, as described, set penalties, and nothing says whether the government will adopt it. DSCI said it plans further guidance on authority mapping, on AI in physical and biological systems, and on agents operated by customers and business partners.
Inc42 placed the paper alongside two other moves. Last month, the Ministry of Electronics and Information Technology proposed the Data Empowerment and Protection Architecture for AI training, a consent-based framework for sharing data to train models that aims to comply with the Digital Personal Data Protection Act. And the Telecom Regulatory Authority of India released draft guidelines on responsible use of AI in telecom networks and services, with comments due by 27 November.
TRAI's deadline is 23 days after the day of the report.
What to watch next
Watch for DSCI's comment window and any follow-up guidance on authority mapping. TRAI's comments close on 27 November. The MeitY data framework is the other open item. Watch also for whether financial regulators such as the RBI reference similar ideas when they write rules for AI in lending or payments.
Key takeaways
- DSCI's discussion paper proposes that liability for harm from AI agents follows control over model choice, configuration, tool access, permissions and human oversight.
- It applies existing law rather than proposing a new regulatory framework, and it is a proposal open to industry feedback.
- It names 12 areas of harm and recommends six safeguards, including human approval for significant actions and kill switches with clear owners.
- Companies running open-weight models themselves take on more responsibility, while those using closed models through APIs may seek recourse by contract.
- The summary rests on one outlet, and the paper's own text was not opened.
Sources
- [Inc42: DSCI floats framework to determine liability for harm caused by AI agents](https://inc42.com/buzz/dsci-floats-framework-to-determine-liability-for-harm-caused-by-ai-agents/)
Tags: Agentic AI AI governance AI agents DSCI Regulation