AI Security and Governance
AI Liability in India: What Agentic AI Accountability Means for Businesses
What does AI liability mean in India as businesses adopt agentic AI? This practical guide explains accountability, oversight, vendor responsibility and cyber-risk controls.
Agentic AI can plan tasks, call tools, use data and take actions across several systems. That capability may improve productivity, but it also makes responsibility harder to trace. If an AI agent exposes data, sends an incorrect instruction or makes an unsafe decision, the answer cannot simply be “the model did it.” A new Data Security Council of India guidance resource published on 29 October 2026 offers an India-focused way to think about accountability and responsibility as enterprises adopt agentic AI. It discusses how responsibility can be allocated across the value chain rather than presenting itself as a new statute or a replacement for professional legal advice. **Short answer:** AI liability is a governance question about who designed, supplied, deployed, configured, supervised and benefited from an AI system—and whether each participant used reasonable controls. For agentic AI, organisations need clear ownership, approval boundaries, audit logs, human oversight, vendor accountability and tested failure handling.
Introduction
Agentic AI can plan tasks, call tools, use data and take actions across several systems. That capability may improve productivity, but it also makes responsibility harder to trace. If an AI agent exposes data, sends an incorrect instruction or makes an unsafe decision, the answer cannot simply be “the model did it.”
A new Data Security Council of India guidance resource published on 29 October 2026 offers an India-focused way to think about accountability and responsibility as enterprises adopt agentic AI. It discusses how responsibility can be allocated across the value chain rather than presenting itself as a new statute or a replacement for professional legal advice.
**Short answer:** AI liability is a governance question about who designed, supplied, deployed, configured, supervised and benefited from an AI system—and whether each participant used reasonable controls. For agentic AI, organisations need clear ownership, approval boundaries, audit logs, human oversight, vendor accountability and tested failure handling.
Why agentic AI changes the accountability question
A traditional software feature usually follows a defined path. An agent may select tools, interpret instructions, retrieve information and create a sequence of actions. The final outcome can depend on the model, prompts, permissions, connected services, data quality, monitoring and human approvals.
That does not make an agent impossible to govern. It means responsibility must be designed before deployment. An organisation should be able to explain what the agent was allowed to do, which identity it used, which data it accessed, what policy applied, which human approved a high-impact action and how the organisation can stop or recover the workflow.
What the DSCI guidance adds for India-focused teams
The DSCI resource provides a practical India-focused perspective on accountability for autonomous and multi-vendor AI systems. It maps responsibility across the value chain and discusses the risks and impacts that can arise when agentic AI is introduced into enterprise processes.
The guidance should be read as an industry resource. It does not automatically create a new legal duty for every business, and it should not be used to make a definitive legal conclusion about a specific incident. Its value is in helping boards, security teams, product owners, procurement teams and vendors ask better questions before an agent receives meaningful permissions.
Who may have responsibility for an AI agent?
The answer depends on the system and the facts. Relevant participants can include the organisation that decides to deploy the agent, the team that configures it, the model or platform provider, the developer of a connected tool, the data owner and the human who approves or supervises an action.
A useful responsibility map should record:
Shared responsibility does not mean no one is responsible. It means that each participant needs a documented boundary and evidence that the boundary was managed.
- who selected the use case and defined the business purpose
- who approved the data sources and retention period
- who configured prompts, tools, policies and permissions
- who tested the agent against unsafe or misleading instructions
- who monitors the agent in production
- who can pause, revoke or roll back its access
- who investigates incidents and communicates with affected people
The security controls that support accountability
Accountability becomes difficult when the organisation cannot reconstruct what happened. The minimum control set should therefore include strong identity, least privilege, tool allow-lists, approval gates for sensitive actions, immutable audit logs, alerting and a tested kill switch.
Agents should use separate service identities rather than personal administrator accounts. Tokens should be short-lived where possible, scoped to the task and rotated when a workflow changes. Sensitive actions—such as changing payment instructions, exporting regulated data, deleting records or sending external notices—should require explicit human approval unless a documented risk assessment supports another design.
How businesses can prepare an agentic AI risk register
Start with the use case, not the model brand. For each agent, record the business process, data classification, connected tools, permissions, expected outputs, failure modes, human checkpoints and recovery owner.
Then test realistic misuse scenarios. Can an untrusted document cause the agent to reveal data? Can a prompt injection change the destination of a tool call? Can a compromised connector use the agent’s identity? Can the organisation prove which instruction led to a destructive action? These are security and operational questions, not only model-quality questions.
A useful risk register should also record residual risk and the reason a business accepted it. Revisit the assessment after a model, tool, prompt, data source or permission change.
What to ask AI vendors and connected-tool providers
Procurement teams should ask where prompts, outputs, logs and uploaded data are processed and retained; how incidents are reported; how access is revoked; what audit evidence is available; what subcontractors are used; and how a customer can export or delete its records.
Contracts should not be treated as a substitute for technical controls. A vendor may promise secure handling, but the deploying organisation still needs local logging, access governance, testing and a clear incident-response path.
India-specific governance questions
Indian organisations should map agentic AI use against the organisation’s data-protection, sectoral, contractual and information-security obligations. The precise answer depends on the sector, data, processing purpose and deployment model. Teams should avoid assuming that a general AI policy covers a system that can independently access enterprise tools.
Include security, privacy, legal, procurement, internal audit and business owners in the review. For high-impact uses, document why the agent is appropriate, what human oversight exists and how affected people can raise a concern or obtain a review.
Frequently asked questions
### Is AI liability already a single, settled rule in India?
No. Accountability can depend on the facts, the parties, the contract, the sector and applicable law. This article explains a governance approach and is not personalised legal advice.
### Can a company blame the AI vendor for an agent’s mistake?
Not automatically. Vendor responsibility may be relevant, but the deploying organisation also controls use-case selection, permissions, configuration and supervision. A documented responsibility map is stronger than an assumption about blame.
### Should every AI agent have a human in the loop?
High-impact or irreversible actions generally deserve meaningful human review. The right design depends on the use case, but “human oversight” should be a real control with authority to stop or correct the action, not a nominal approval step.
Conclusion
Agentic AI can be useful without becoming unaccountable. Start with a clear use case, limit permissions, log every meaningful action, test for prompt injection and unsafe tool use, and assign named owners across the AI value chain. DSCI’s 29 October guidance gives Indian organisations a timely framework for discussing those responsibilities as adoption grows. For practical technical foundations, see Cyberoinfo’s [cybersecurity terminology guide](/articles/cybersecurity-terminology-for-beginners) and [cybersecurity practices for beginners](/articles/cybersecurity-practices-for-beginners).
Decision checklist
- who selected the use case and defined the business purpose
- who approved the data sources and retention period
- who configured prompts, tools, policies and permissions
- who tested the agent against unsafe or misleading instructions
- who monitors the agent in production
- who can pause, revoke or roll back its access
- who investigates incidents and communicates with affected people
Limitations
- Reporting channels, procedures and security guidance can change; verify current instructions before acting.
Evidence sources
- dsci.in — DSCI AI Liability: Industry Guidance for Agentic AI
- dsci.in — DSCI AI Security and Governance Resources
- dsci.in — Cybersecurity governance reference
- cyberoinfo.com — Cyberoinfo editorial methodology