In Spain, a data breach has been reported for the first time in which an attack is said to have been carried out with an AI agent. This article explains how the notification obligation for an AI agent data breach can be classified, when the 72 hours start to run, and which preparations should already be in place so that you do not have to improvise under stress.
On 14 September 2026 it became public in Spain that an attack carried out with an AI agent had been reported to a data protection authority for the first time. This raises a practical question: who has to do what when an AI agent is involved, whether as an attack tool of outside perpetrators or as the company's own tool? It comes down to the notification obligation, deadlines, logs and procedures for an emergency.
The AEPD case in brief
In Spain, a personal data breach has been reported for the first time in which an attack is said to have been carried out with an AI agent based on a well-known language model. According to the report, the attacker first searched publicly accessible files for vulnerabilities and then logged in to the target system. The agent found further vulnerabilities in the application, altered personal data and accessed invoices.
The distribution of roles matters. The reporting company was the victim, and the agent was the attackers' tool. It was therefore not a failure of an agent that the organisation itself operated. Neither the organisation nor the model is named. The use of a well-known model does not mean that its provider or infrastructure was compromised, and it is not stated that the tool was built for harmful purposes. A single case also says nothing about a trend.
AI does not create fundamentally new threats, but it can increase the speed, scale and adaptability of attacks. Practical consequences follow: attacks using AI belong in the risk analysis, response times designed for manual attacks need to be reviewed, credentials with excessive permissions need better protection, and human oversight needs support from fast detection and containment.
When an AI agent triggers a reportable data breach
The notification obligation for data breaches caused by AI agents does not depend on the technology but on the outcome. Under Art. 4(12) GDPR, a personal data breach exists where a security breach leads to the destruction, loss, alteration, unauthorised disclosure of, or unauthorised access to personal data, whether accidental or unlawful. Whether a person, a script or an agent is behind it plays no role in this definition. Two scenarios can nevertheless be clearly distinguished.
In scenario A, an external agent attacks, as in the Spanish case. The unauthorised access and the alteration of data are the breach, and the notification obligation arises with it. What is new here is mainly the speed, not the legal classification. In scenario B, the company's own agent causes the breach. This can be a customer-service agent that sends data to the wrong person, a coding agent with excessive permissions, or a mail agent that forwards content after an injected instruction.
In scenario B, the classification is not always obvious. If the agent did exactly what it was set up to do and no unauthorised person gained access, there is often no security breach. If, on the other hand, data flows to recipients who were not supposed to receive it, or the agent accesses data stores that should have been closed to it, a breach is quite likely. There are still hardly any dedicated guidelines for agents. The assessment therefore remains a case-by-case question and follows the general standards of the authorities.
| Scenario | Breach? | Protection goal affected |
|---|---|---|
| External agent logs in without authorisation | Yes | Confidentiality |
| External agent alters records in the application | Yes | Integrity |
| Own agent sends invoices to the wrong recipients | Yes | Confidentiality |
| Own agent forwards mailbox contents to outsiders after a prompt injection | Yes | Confidentiality |
| Own agent deletes records without a backup | Yes | Availability |
| Own agent gives a wrong answer without any data leaving | Usually no | None, rather a quality problem |
The key question can thus be answered briefly.
Must a data breach involving an AI agent be reported under Art. 33 GDPR?
Risk threshold and exemption from notification
Not every breach has to be reported. Art. 33 GDPR provides for an exemption where the breach is unlikely to result in a risk to the rights and freedoms of natural persons. The bar is therefore low. As a rule, a report is made as soon as a risk cannot be ruled out. Anyone who omits the notification must be able to justify convincingly why there was no risk.
In attacks and incidents involving agents, much speaks against this exemption. Agents often access many records at once, they work quickly, and they have access to areas such as invoices, customer accounts or mailboxes. If an attacker alters data, a follow-on problem arises alongside the loss of confidentiality: at first nobody knows which records are still correct. That increases the risk for the data subjects.
The European data protection authorities have published guidelines for the assessment. The EDPB guidelines on personal data breach notification name as criteria, among others, the type of breach, the sensitivity and volume of the data, how easily the data subjects can be identified, the severity of the possible consequences and the number of data subjects. Where the risk is high, notifying the data subjects under Art. 34 GDPR is required in addition. This step is separate from the notification to the authority and has its own requirements.
Responsibility stays with the operator
An agent is a tool, not a legal subject. The party that decides on the purposes and means of the processing remains responsible, that is, the company that deploys the agent. It is not enough to point to the model, the platform or the business department. Even if an agent acts autonomously, the processing remains attributed to the operator.
The agent is a tool, the responsibility stays with the operator.
If a platform or a model provider operates the agent on behalf of the company, it usually acts as a processor. Art. 33(2) GDPR then applies: the processor must notify the controller of a breach without undue delay after becoming aware of it. The controller's own deadline, however, only starts with its own awareness. Contracts should therefore specify the time frame and the channel for reporting incidents. A notice that only lands in a general mailbox after several days helps nobody.
| Party | Role in an agent incident |
|---|---|
| Operator of the agent | Controller, notifies the supervisory authority and documents |
| Agent platform | Often a processor, informs the operator without undue delay |
| Model provider | Depending on the set-up a processor or sub-processor, also obliged to inform if it is compromised itself |
| Business department | Detects and reports internally without deciding itself |
| Other service providers | Provide logs and information for the assessment |
If an attacker gets in through a service provider, the same principles apply as for any incident in the supply chain.
Counting the 72 hours correctly
Under Art. 33(1) GDPR, the deadline runs from the moment the controller becomes aware of the breach. The report is to be made without undue delay and, where feasible, within 72 hours. According to the EDPB guidelines, awareness exists when the controller has a reasonable degree of certainty that a security incident has led to a personal data breach. A short period for examination in order to clarify a suspicion is permitted. Inaction is not.
With agents, the bottleneck shifts. An agent can retrieve or alter thousands of records in minutes. Whether the incident is detected on the same day or only after a week then depends on monitoring and alerting. Agents running at night or at weekends make this worse. Anyone who notices anomalies only the next time they glance at a dashboard loses time that the deadline does not provide for. What matters most here is the time to detect and the question of who is allowed to respond outside office hours.
With agents, the 72 hours are above all a question of detection time.
The law allows reporting in phases. If not all information is available yet, it is provided later without undue further delay under Art. 33(4) GDPR. If the deadline is exceeded, the delay must be justified. The following sequence can serve as a guide.
The timings are guide values. What matters is that every stage has someone who triggers it, and that the decision on the notification does not depend on the availability of a single person.
Logging agent actions
Without logs, the scope of a breach can hardly be quantified. With agents this is especially tricky, because they carry out many individual actions that look harmless on their own. A useful log answers four questions: who acted, what was done, which data was accessed and where did it go? On top of that comes the documentation obligation under Art. 33(5) GDPR, which applies to every breach, including those that are not reported.
| Log field | Benefit for the notification | Note on data minimisation |
|---|---|---|
| Identity and version of the agent | Links the incident to a system and configuration | A technical identifier is enough |
| Task and trigger | Clarifies whether a person, a schedule or external input started the action | Short description instead of the full wording |
| Tool and data accesses | Shows the type and scope of the data affected | Categories and volumes instead of contents |
| Timestamps | Basis for awareness and calculating the deadline | Uncritical |
| Target systems and recipients | Shows where data ended up | Addresses only if necessary |
| Errors and aborts | Indications of attack attempts and malfunctions | Uncritical |
| Approvals by humans | Evidences oversight and decision paths | Only the identifier of the approving unit |
For agent logging, the following applies: the logs themselves contain personal data and must be protected. Access should be limited to a few people, and the entries should be stored in a tamper-proof way, for example on a separate system. The retention period is a balancing exercise: long enough to be able to reconstruct an incident, short enough not to create a data collection. These measures are part of the security of processing under Art. 32 GDPR. The same logs also help with access requests. How to design the monitoring of AI agents sensibly, without agents undermining their own oversight, is a topic of its own.
Limiting access rights and credentials
The Spanish case shows how an attacker with an agent proceeds: they look for known files, default accesses and everyday vulnerabilities. This is exactly what an agent can do at machine speed and without fatigue. Anyone who closes such gaps takes much of the pace out of the attack. The authority expressly names accounts, API keys and tokens with excessive permissions as a weak point.
A handful of principles has proven itself in practice:
- Each agent gets its own account with the least privileges necessary.
- Keys and tokens are short-lived and can be revoked individually.
- Accesses to many records within a short time are limited and reported.
- A kill switch stops agents and blocks their access without first requiring consultation.
- Published files, test accounts and default passwords are searched for and removed regularly.
These measures protect against external agents and against mistakes by your own. How great the damage is depends heavily on the permissions an agent has been given. For the attack surface of a web application, automated checks that find visible vulnerabilities before others do can help.
Check your attack surface
Exposed files, missing safeguards and data leaks on your own website can be found automatically.
Response plan for automated attacks
Many emergency plans assume an attacker who needs hours or days. The authority suggests reviewing response times that are designed for manual attacks. Human oversight remains important but needs support from mechanisms that detect, contain and respond fast enough. An automated attack does not stop at closing time.
A robust plan fixes a few things. There are alerts for unusual access patterns, such as many retrievals from the same account or logins at untypical times. Accounts can be blocked automatically when thresholds are exceeded. Someone is reachable outside office hours. It is clear who decides on the notification and who sends it. The supervisory authority's reporting form is prepared and the data protection officer's contact details are at hand. For the first hours of an incident, the action plan for the first 60 minutes is worth a look. It was created for ransomware but can be applied to other attacks.
It helps if the plan has been practised. An exercise with a fictitious agent incident in which an account retrieves data in large volumes quickly shows where things go wrong: missing on-call duty, unclear responsibilities, logs that cannot be analysed. Such gaps can be closed in calm times, not in an emergency.
Preparing the notification to the supervisory authority
Art. 33(3) GDPR sets the minimum content. It describes the nature of the breach including the approximate number of data subjects and records concerned, the name and contact details of the data protection officer or another contact point, the likely consequences and the measures taken or proposed. As a rule, the competent authority is the supervisory authority of the state in which the company is established. Most authorities offer an online form, and the Data Protection Conference provides an overview.
With agents there are typical gaps. The scope of the access cannot be quantified without logs, and where data was altered it is unclear which records were actually affected. It helps to clarify in advance how a reliable figure can be derived from logs, database backups and version histories. Anyone who can only estimate states the range and marks it as provisional. The follow-up notification fills the gaps later.
A short checklist for the notification:
- Time of awareness and period of the incident
- Type of breach: unauthorised access, alteration, disclosure, loss
- Data categories concerned and approximate number of persons and records
- Role of the agent: external attack tool or own agent
- Accounts, keys and systems contained
- Likely consequences for the data subjects
- Decision on informing the data subjects
- Contact of the data protection officer
Whether notification obligations from other regimes also apply, for example for operators of critical facilities or under the AI Act, depends on the individual case and should be named in the emergency plan so that responsibility does not have to be clarified during the incident.
Conclusion
The first case reported in Spain shows no new legal concept but a new pace. Whether an external agent attacks or your own agent makes a mistake, what matters is whether there is a personal data breach and whether there is a risk to the data subjects. If so, act without undue delay and, where feasible, report within 72 hours.
Short checklist:
- External agents as attackers and your own agents as the cause are different scenarios with the same assessment.
- Responsibility stays with the operator, even when platforms and model providers are involved.
- Detection time decides whether the deadline can be met.
- Good logs turn a suspicion into a reliable notification.
- Minimal permissions, short-lived keys and a kill switch take pace and damage out of the attack.
My name is Klaus Meffert. I have a doctorate in computer science and have been working professionally and practically with information technology for over 30 years. I also work as an expert in IT & data protection. I achieve my results by looking at technology and law. This seems absolutely essential to me when it comes to digital data protection. My company, IT Logic GmbH, also offers consulting and development of optimized and secure AI solutions.
