When an AI Agent Causes a Data Breach: Who Bears the Legal and Contractual Risk?

In September 2026, Spain's data protection authority, the AEPD, announced something regulators had not formally recorded before. It had received a breach notification in which the attack was allegedly carried out through an AI agent.

For SaaS providers, enterprise buyers and their lawyers, the incident raises a practical question. If an autonomous tool causes a breach, who answers for it?

This guide explains how liability is likely to be traced. It covers GDPR, India's DPDP framework, the gaps in ordinary contracts, and the clauses and controls that close them.

This article stays on data breaches, cybersecurity, GDPR and DPDP responsibilities, incident response and how contracts allocate breach-related risk. If your question is about contract formation, authority, or whether an AI agent's actions can bind a company, read our separate article: If an AI Agent Signs a Contract, Who Is Legally Responsible?

What happened in Spain's first AI agent data breach?

According to the affected organisation's notification, the agent began by searching generic files for weaknesses. It then gained access to the system, kept looking for flaws in the application and exploited them. That let it modify personal data and access invoices.

The status of the case needs care.

This is a notified incident under continuing investigation. The details come from the organisation's own notification, and the AEPD still has to analyse them. It is not a final enforcement decision.

It also says nothing about fault on the part of the model provider. The AEPD has made clear that using a particular AI model does not mean the model or its provider's infrastructure was compromised, or that the tool was designed for malicious purposes. A single notification does not establish a trend either.

So why does it matter? Because existing cyber threats can now move faster and at greater scale. The AEPD's advice is that risk assessments should name AI-assisted and AI-executed attacks explicitly. The case is a warning, not a verdict.

Can an AI agent be legally liable for a data breach?

Under the legal frameworks discussed in this article, an AI agent is not itself treated as the legal person bearing regulatory or contractual responsibility. Responsibility must instead be analysed by reference to the organisations and persons that develop, supply, configure, deploy or use the system.

Four points frame the analysis:

1. Liability turns on control, foreseeability, security measures, contractual allocation and each party's role.
2. An agent should be treated as a privileged machine identity. It performs actions. It is not passive software.
3. Contracts can move financial risk between parties. They cannot move regulatory responsibility that the law places directly on a controller, processor, provider or deployer.
4. Being the victim of a criminal attacker does not automatically remove your regulatory duties.

What makes an AI agent incident different from a normal breach?

Three kinds of tools are often lumped together. They carry different risks.

An agent may connect to databases, email, cloud environments, payment systems, customer records, APIs and third-party services. The risk is no longer a wrong answer on a screen. The agent may act on personal data, move money, change a security setting or alter a contractual position.

That is why the legal analysis shifts from what a tool said to what a tool did.

Who could be responsible when an AI agent causes a breach?

No single party is responsible by default. Each may carry a share, depending on facts and contracts.

A dispute after an incident usually comes down to evidence. Who set the permissions? Who approved the connection? Who changed the configuration last? Logs and records answer those questions. Memory does not.

What does GDPR require when an AI agent is involved?

GDPR applies to a breach whatever tool caused it. Several articles matter most.

Article 5 sets the core principles. These include integrity and confidentiality, and the accountability principle. A controller must be able to show compliance, not just claim it.

Article 25 requires data protection by design and by default. For agents, this points to narrow permissions, limited data access and built-in approval steps.

Article 28 governs processors. It requires a written contract with defined terms. A processor must act on documented instructions and support the controller during incidents.

Article 32 requires security appropriate to the risk. An agent that can write or delete data raises that risk. The controls should match.

Article 33 requires a controller to notify the supervisory authority within 72 hours of becoming aware of a breach, unless the breach is unlikely to risk individuals' rights. A processor must notify the controller without undue delay. Where facts are still unclear, information can be provided in phases.

Article 34 requires notice to affected individuals when the breach is likely to result in a high risk to them.

Article 35 requires a data protection impact assessment where processing is likely to result in a high risk to the rights and freedoms of natural persons. Whether an agent deployment meets that threshold depends on the facts. Broad, autonomous access to personal data may be an important factor in that assessment. It does not, on its own, establish the threshold.

Can a controller blame the AI vendor?

No. A controller cannot escape statutory responsibility by saying the vendor is at fault. Processors also carry direct duties of their own, so responsibility is not a single chain.

The contract decides who pays the other party. The statute decides who answers to the regulator. Keep the two separate.

What makes an agent breach hard to investigate?

Agent incidents leave gaps that ordinary breaches often do not. You may not know:

1. whether data was only viewed or was also copied;
2. which records were altered;
3. whether information persists in prompts or agent memory;
4. which tools or third parties received data;
5. when the organisation became aware of the breach;
6. whether reliable evidence still exists.

Each gap affects your 72-hour clock and your notification content. Detailed logging is the best answer.

How does India's DPDP framework treat AI agent breaches?

India's Digital Personal Data Protection Act, 2023 uses different terms from GDPR. It speaks of a Data Fiduciary, a Data Processor and a Data Principal. Do not read these as exact copies of controller, processor and data subject. The duties, thresholds and reporting mechanics differ.

The core idea is similar. The Data Fiduciary stays answerable for personal data processed for it, including through a processor. Breach reporting details sit largely in the rules made under the Act. Check the current commencement status of those rules before relying on any timeline.

Indian businesses serving UK or EU customers may face both regimes. Map each dataset to the law that governs it. Do this before an incident, not during one.

Why do ordinary SaaS agreements and DPAs fall short?

Traditional terms were written for a world of human users and hosted software. They usually cover hosting security, unauthorised human access, confidentiality, availability and standard breach notice.

They often stay silent on the things agents introduce:

1. autonomous tool selection;
2. machine credentials;
3. agent-to-agent interaction;
4. persistent memory;
5. action logs;
6. emergency suspension;
7. responsibility for safeguards a customer has changed.

If your contract does not mention these, a dispute will turn on general wording. That is an uncomfortable place to argue from.

The EU AI Act does not fill the gap. It does not replace GDPR. The two regimes can apply at the same time, and your role under each may differ.

Which clauses should an AI agent contract include?

Good drafting is specific. Here are the provisions to address.

1)   Purpose, autonomy and oversight

Define the approved use case, the connected systems, the permitted data and the prohibited activities. State which actions the agent may take alone and which need prior human approval. Payments, deletion, disclosure and security changes are the usual candidates for approval gates.

2)   Access, configuration and testing

Require least privilege access, scoped credentials, time-limited tokens and limits on credential sharing. Allocate responsibility for permissions, connectors, datasets, instructions and any safeguard the customer controls. Require sandbox testing before launch. Require fresh testing before any new tool is switched on.

3)   Logging, incidents and containment

Require records of prompts, instructions, tool calls, system changes, administrator actions and material outputs. Set a notification period short enough to support GDPR's 72-hour deadline, and any shorter sector rule. Say who can suspend the agent, revoke credentials, disconnect tools and preserve evidence, and how fast.

4)   Data use, subprocessors and cooperation

State whether prompts, outputs, customer data and logs may be used for training or service improvement. Require disclosure or control of third-party services that protected information may pass through. Provide access to logs, technical staff, timelines and root-cause analysis. Include help with regulator responses.

5)   Liability, insurance and change

Do not default to unlimited liability. It is not a universal answer and vendors rarely accept it. Instead, separate the causes: provider defects, integrator failure, customer misconfiguration, prohibited use and removal of safeguards. Each may deserve a different remedy.

Review insurance too. Check cyber cover and technology errors-and-omissions cover for AI-related exclusions. Then add a mechanism to update controls and documents as AI regulation develops.

Which technical controls make the contract credible?

A warranty with no technical proof behind it has limited value. Regulators and courts look at what was actually in place.

Useful controls include:

1)    least-privilege permissions and tool allow lists;

2)    separate development and production systems;

3)    human approval for payments, deletion, disclosure and security changes;

4)    rate limits, transaction limits and network segmentation;

5)    credential rotation and immediate revocation;

6)    immutable action logs and anomaly detection;

7)    an emergency shutdown capability;

8)    red-team testing and monitoring of behaviour after updates;

9)    data retention and deletion controls;

10)  incident simulations that involve autonomous actions.

Tie each contract promise to one of these. If a clause says the agent uses least privilege, you should be able to produce the permission records.

What should you ask before deploying an AI agent?

Put these questions to your team and your vendor before go live:

1)    What systems and data can the agent access?

2)    Can it write, delete, transfer or disclose data?

3)    Which actions need human approval?

4)    Can it select or call third-party tools on its own?

5)    Are its actions fully logged and attributable?

6)    Can its credentials be revoked at once?

7)    Does its memory persist across sessions?

8)    Can customer data be used for training?

9)    Who investigates and reports an incident?

10)  Who controls messages to customers and regulators?

11)  Does insurance cover autonomous AI actions?

Unclear answers point to clauses that need work.

Which documents should you review?

Read these together, not one by one. Conflicts between them cause real disputes.

Start with the AI services agreement, the SaaS or cloud agreement and the data processing agreement. Then check the information-security schedule, acceptable use policy and subprocessor schedule. Finally, review the incident-response plan, the DPIA or AI risk assessment, the cyber insurance policy and your internal AI governance policy.

The bottom line on AI agent data breach liability

Agentic AI does not remove human or corporate responsibility. It makes responsibility depend more heavily on evidence. That means evidence of control, configuration, supervision and contractual allocation.

Govern an AI agent as a privileged digital actor that can change systems and data. Do not treat it as a chatbot that produces content. Give it only the access it needs, log what it does, and be ready to switch it off.

FAQs

1.    Can an AI agent itself be legally liable for a data breach?

Under the legal frameworks discussed in this article, an AI agent is not itself treated as the legal person bearing regulatory or contractual responsibility. Responsibility is analysed by reference to the organisations and persons that develop, supply, configure, deploy or use the system.

2.    Is the model provider automatically responsible if its model is used in an attack?

No. Liability depends on facts such as defective safeguards, misleading claims or inadequate incident help. Use of a model alone does not show fault

3.    Who must report an AI-related personal-data breach under GDPR?

The controller notifies the supervisory authority, generally within 72 hours of becoming aware. A processor must tell the controller without undue delay.

4.    Does an ordinary SaaS agreement cover autonomous AI actions?

Rarely in any clear way. Most were drafted around human users and hosting risk.

5.    What clauses should an agentic-AI agreement include?

Defined purpose, approval gates, least-privilege access, logging, fast notification, kill-switch authority, training limits, subprocessor control and a tailored liability split.

6.    Should businesses complete a DPIA before deployment?

It depends on whether the processing is likely to result in a high risk to individuals' rights and freedoms. That is the Article 35 test. Broad autonomous access to personal data may be an important factor, but it does not settle the question on its own. Where the risk is likely to be high, complete the DPIA before deployment.

7.    Can a company transfer all AI-related liability to its vendor?

No. Contracts can shift cost between parties. They cannot shift statutory duties owed to regulators.

8.    What records should be retained to investigate an incident?

Prompts, instructions, tool calls, system changes, administrator actions, credential records and material outputs.

9.    How should Indian companies serving EU customers manage this risk?

Map which law applies to each dataset, then align contracts and controls to the stricter standard. Review DPDP and GDPR duties side by side.

Related Articles

Have EU Customers? Why GDPR Applies to Your Business and How to Comply Without Overcomplicating It (2026 Guide)

Liability in AI Systems: Who Is Responsible When AI Fails?

AI Contract Automation in India: Benefits, Legal Risks, and the Road Ahead for SMEs

ABOUT AUTHOR

Prakhar Rai is a corporate and litigation lawyer with hands-on experience in arbitration, contract structuring, and dispute resolution for businesses across India and international jurisdictions. He regularly advises startups, founders, and companies on drafting enforceable arbitration clauses, managing disputes, and protecting commercial interests before they escalate into costly litigation. With a strong focus on practical risk mitigation and legally sound drafting, his work bridges the gap between legal theory and real-world business challenges.

Disclaimer

This article is intended solely for general informational and educational purposes. It does not constitute legal advice, advertising, or solicitation. The Spanish incident discussed is a notified matter under continuing investigation, and the facts and regulatory position may change. Legal requirements may vary depending on the specific contract, the parties' roles under applicable data-protection law, the jurisdictions involved, sector-specific obligations, the state of AI and data-protection regulation at the time, and individual circumstances. Independent professional advice should be obtained before deploying an AI agent or drafting or relying on any technology, data-processing or liability clause.