Share This Article
A data breach caused by an AI agent has now been notified for the first time to a European data protection authority, with the Spanish AEPD receiving the first notification of a personal data breach allegedly carried out using an AI agent.
The Spanish Data Protection Agency (AEPD) has reported that it has received what it describes as the first notification in Spain of a personal data breach in which an attack was executed using an AI agent. According to the information provided by the affected organisation, the system accessed an application, autonomously searched for vulnerabilities, modified personal data and accessed invoices.
The AEPD has been careful to qualify the information available at this stage. The incident is still being analysed, the affected organisation has not been identified and the Agency has not confirmed that the AI model itself or the infrastructure of its provider was compromised.
This is therefore not a case from which broad conclusions about the frequency of AI-driven attacks can yet be drawn. The AEPD itself says that a single notification does not establish a statistical trend.
It is nevertheless a development that companies should pay attention to because it brings together two issues that are becoming increasingly difficult to separate: AI-enabled cyberattacks and regulatory incident response.
What makes an AI agent different in a cyberattack?
The use of AI in cyberattacks is not new. Generative AI can already be used to create phishing communications, translate fraudulent messages, analyse source code, impersonate individuals and assist with vulnerability research. The development of AI agents introduces a different operational dimension.
An AI agent can receive an objective, identify intermediate steps, use tools, execute code, analyse the results and modify its subsequent actions based on what it discovers. The AEPD describes this ability to perform tasks with a degree of autonomy as one of the characteristics that distinguishes agentic AI from more conventional uses of generative AI.
In the incident notified to the AEPD, the agent allegedly began by searching for vulnerabilities in generic files and successfully obtained access to the system. Once inside, it continued autonomously looking for vulnerabilities in the application and eventually exploited them, allowing it to modify personal data and access invoices.
The significance of the case is therefore less about the particular vulnerability that was exploited and more about the ability of the attacker to chain different stages of the attack with limited human intervention. That can materially reduce the time available to detect what is happening.
The real issue for companies is incident response
When I work on cyber incidents, one of the most difficult aspects is often not identifying that something has gone wrong, but establishing quickly enough what actually happened. The initial information is normally incomplete. The forensic investigation is developing, systems may still be compromised and the company may have to make decisions before it has a complete picture of the incident. An AI agent can make this problem more difficult.
If the system can autonomously identify vulnerabilities, test different access points and adapt its behaviour, the organisation may have less time between the initial compromise and the point at which significant damage occurs. The AEPD expressly highlights this issue, observing that an AI agent may analyse different assets, test several entry points and rapidly modify its behaviour. The Agency also identifies the risk created where an agent obtains an account, API key or token with excessive permissions and can move between different services before anomalous activity is detected. This has a direct consequence for legal teams. The incident-response process may have to reach the legal assessment much earlier than it does today.
GDPR does not wait for the forensic report
Where personal data is involved, the first question will often be whether the incident qualifies as a personal data breach under the GDPR and whether the conditions for notification to the competent supervisory authority are met.
Article 33 GDPR requires notification without undue delay and, where feasible, within 72 hours after the controller becomes aware of a personal data breach, unless the breach is unlikely to result in a risk to the rights and freedoms of individuals.
The problem is that “becoming aware” of a breach does not necessarily coincide with understanding the full extent of the attack. A company may know that an attacker has accessed an application while still investigating whether personal data was accessed, which records were affected and whether information was extracted or modified. This is already a familiar problem in cyber incidents. An AI agent could make the gap between detection and understanding even more significant.
For example, if an agent has moved between different systems using legitimate credentials, the company may initially have difficulty determining which actions were authorised and which were performed by the attacker. If the agent has also modified information, the investigation may need to establish not only what data was accessed but whether its integrity has been compromised. The legal team therefore cannot simply wait for the final forensic report before becoming involved.
The regulatory exposure can extend beyond GDPR
The AEPD case is particularly interesting because the incident may need to be considered through more than one regulatory lens.
GDPR may apply because personal data has been compromised. However, depending on the organisation involved, cybersecurity obligations under NIS2 may also be relevant. For financial entities and their ICT arrangements, DORA may need to be considered. Where a product with digital elements is involved, the Cyber Resilience Act can create another layer of reporting and regulatory analysis.
These regimes do not necessarily apply to every organisation or to every incident, and their respective thresholds and reporting requirements differ. What they have in common is that the organisation needs to make legal decisions while the technical investigation is still developing. That is why I increasingly see cyber incident response as a regulatory exercise as much as a technical one.
The question is not simply how the attacker entered the system. The company also needs to establish what obligations were triggered, when they were triggered and whether the decisions taken during the incident can subsequently be demonstrated to have been reasonable and properly documented.
AI agents also change the importance of access controls
The AEPD’s reference to credentials, API keys and tokens deserves particular attention. An organisation may have invested heavily in cybersecurity while still allowing an AI agent, an application or a service account to access a broader set of systems than is actually necessary. This can become particularly problematic when the same credentials provide access to multiple environments. The principle of least privilege is therefore becoming increasingly relevant to AI deployments. The question should be what an agent is allowed to do when it operates normally, and what could happen if that agent, its credentials or the environment in which it operates were compromised. This is not limited to companies developing AI products. It can affect any organisation that deploys agents capable of interacting with internal applications, customer databases, CRM systems, payment systems, cloud environments or other services containing personal or commercially sensitive information.
What happens when the regulator starts asking questions?
There is another reason why this first notification is relevant. A data breach notification is rarely the end of the regulatory process, especially in countries like Italy where the Garante receives a very limited number of data breach notifications, if compared to other EU data protection authorities.
A supervisory authority may subsequently ask how the attack occurred, what security measures were in place, when the organisation became aware of the breach, what it did after becoming aware and why it reached the conclusions reflected in its notification. That means the quality of the incident-response process can become relevant to a later regulatory investigation. And a data breach notification shall not be deemed to be a mere disclosure exercise, companies need to build their defence against potential regulatory challenges from the first notification.
This is an area where I have seen the distinction between “cybersecurity” and “privacy” become increasingly artificial. A technical vulnerability may result in unauthorised access. That access may involve personal data. The organisation’s response may then become the subject of regulatory scrutiny. The legal exposure therefore does not necessarily arise only from the vulnerability itself. It can also arise from what the organisation did, or failed to do, after the vulnerability was exploited.
This is consistent with a broader trend in privacy enforcement, where regulators increasingly examine the operational processes behind individual events. I recently discussed this in GDPR Data Subject Rights: One Complaint, €5.5 Million Fine, examining how an individual complaint can reveal wider weaknesses in the way an organisation manages GDPR rights and related processes.
Should companies change their incident-response plans?
The AEPD believes that organisations should reconsider their risk analyses in light of attacks assisted or executed through AI. It also stresses the importance of rapid detection, containment and response capabilities. I think the practical exercise should start with the existing incident-response plan, with the following checklist that might help:
- Would the incident response plan still work if an attacker can operate autonomously and at machine speed?
- Can the security team identify unusual behaviour generated by an AI agent?
- Can compromised credentials, API keys and tokens be revoked immediately?
- Can the forensic team reconstruct the actions performed by an autonomous system?
- Can the legal team obtain enough reliable information to make a GDPR notification assessment within the applicable timeframe?
- Is there a clearly documented process for revisiting the legal assessment as the investigation develops?
These questions are particularly relevant because the AEPD’s case demonstrates that AI agents may already be moving from an experimental technology into the real-world threat environment.
The first notification is a signal, not yet a trend
The AEPD has expressly cautioned against treating this single incident as evidence of a broader statistical trend. At the same time, it considers the case a relevant signal that AI-supported attacks are beginning to materialise in incidents involving real personal data. There is no need to assume that AI agents will suddenly transform every cyberattack. There is already enough evidence to recognise that they can increase the speed and autonomy of certain attack techniques. For companies, this creates a practical question that is much more immediate than the broader debate about the future of AI. If an AI agent were attacking your organisation today, would your incident-response process move quickly enough?
The answer will depend on the company’s technology environment, regulatory perimeter and existing security controls. But the first data breach notification linked to an AI agent gives GCs, CISOs and privacy teams a good reason to test that answer now.