First data breach attributed to an AI agent reported to Spain's AEPD: what it means for GDPR risk assessments

On 14 September, Spain's data protection authority, the AEPD, announced on its blog that it had received the first notification of a personal data breach caused by an attack carried out through an AI agent built on a well-known language model. The affected organisation has not been named, nor has its sector or the number of people involved.

According to the authority, the agent began by searching generic files for vulnerabilities and then logged in successfully. Once inside, it looked for flaws in the application on its own and, having found them, was able to modify personal data and access invoices.

Those details come from the affected organisation's notification and, the AEPD says, have yet to be analysed. The authority also stresses that the use of a particular model does not mean the model or its provider's infrastructure was compromised, or that the tool was designed for malicious purposes. What matters, it adds, is that a third party appears to have used the agent as an instrument to chain together the stages of the attack.

As described, the sequence follows the script of many web intrusions over the past two decades. What is new is the tool that carried it out, and the lesson the regulator draws for risk management: assessments of personal data processing must explicitly account for attacks assisted or executed by AI. Controllers, processors and their data protection officers will need to revisit existing assessments on that basis, and the reasoning applies under the GDPR well beyond Spain.

What is known about the first breach attributed to an AI agent?

Between the authority's post, the INCIBE-CERT news digest entry of 24 September, Infobae's EFE-based report and BleepingComputer's coverage, the published information comes down to six points:

1. Execution: an AI agent running on a language model that has not been named.
2. Reconnaissance: a search for vulnerabilities in generic files.
3. Access: a successful login, with no explanation of how the agent achieved it.
4. Exploitation: flaws found and used autonomously inside the application.
5. Impact: modification of personal data and access to invoices, which the Infobae report describes as belonging to third parties.
6. Status: the AEPD is still analysing the information and has published no conclusions.

The public account leaves out the organisation's identity, the number of people affected, the volume of data, whether access was contained and whether the altered data was restored. INCIBE-CERT, Spain's national CERT for businesses and citizens, lists those same points as undisclosed, and adds that there is no confirmation the model or its provider's infrastructure was compromised.

The case should not be read as the first attack of its kind in Spain. It is the first to reach the AEPD as a notification, which required the organisation to detect it and recognise an agent behind it. Others may have happened without anyone attributing them to AI.

Which kind of flaw does the sequence point to?

The authority does not describe the vulnerability, so what follows is a technical reading, not a confirmed fact. "Generic files" points to paths that exist in many applications: configuration files, backups, logs or documentation left on the server. If the login used credentials, they may have come from there, although nobody has said so. Other routes are possible, such as passwords leaked from another service or stolen by an infostealer, or a flaw in the login mechanism itself.

What happened next would be consistent with broken access control, the top risk in the OWASP Top 10 2025. If so, the application checked who had logged in, but not whether the record being read or changed belonged to that user. Walking through thousands of invoice identifiers could already be scripted; what an agent adds is reading each response and adjusting the next request with no one steering it. We explain why this type of flaw still heads the list in the OWASP Top 10 2025 from the pentest side.

The AEPD puts it this way (our translation): "AI does not create new threats. But it does increase the speed, scale and adaptability of known malicious techniques." We saw the same pattern in the DeepSeek-driven agent that attacked some 460 targets.

What does the AEPD expect from controllers and processors?

The blog post, signed by the AEPD's Deputy, Francisco Pérez Bes, sets out four implications for risk management. It is not formal guidance or a decision, but it shows how the supervisor reads the case:

1. Risk assessment: name AI-driven attacks specifically, because a generic reference to malware or unauthorised access falls short when automation "can substantially change the likelihood, speed and scope of the incident" (our translation).
2. Response times: review procedures designed for manual attacks, which may fail against an agent that analyses several assets at once and tries different ways in.
3. Identities: an agent that obtains an account, API credential or token with excessive permissions can operate at machine speed and reach different services before the organisation spots anything unusual.
4. Detection: human oversight remains essential, but it has to rest on detection, containment and response mechanisms that act fast enough.

The authority also points to CCN-CERT BP/36, the best-practice guide on the offensive AI model, published on 23 June by Spain's National Cryptologic Centre. The priorities in its ten-point list include reinforcing essential controls, speeding up vulnerability management, securing identities and access, governing the use of AI, protecting the supply chain and keeping human oversight over automation.

How do you build an AI-executed attack into a GDPR risk assessment?

An AI-executed attack is built into a risk assessment by revisiting four parameters for each internet-facing processing activity: likelihood, reaction window, credential reach and integrity. Adding a row labelled "AI attack" to the threat register achieves little.

Likelihood goes up for flaws that used to demand patience, such as enumerating identifiers or tampering with parameters one by one. When trying is almost free, the assumption that "nobody will bother" falls apart.

The reaction window narrows. A control that depends on reviewing logs once a week presumes a slow attacker; review and response times need to be measured in hours.

The reach of each credential comes to the fore. For every service account, token or API key, you need to know which data it can read and which it can change, because that is what an agent can work out quickly.

Integrity enters the calculation. This case involved altered data, and Article 4(12) of the GDPR defines a personal data breach as covering unlawful alteration as well as unauthorised access. Article 32 requires measures appropriate to the risk, taking account of the state of the art. Article 32(2) lists alteration among the risks to be weighed, and Article 32(1)(d) includes, as appropriate, a process for regularly testing the effectiveness of those measures. Where the processing has a data protection impact assessment (DPIA), Article 35(11) calls for a review when the risk changes.

Which controls can stop an attack of this kind?

Five controls map onto the stages described: server exposure, credentials, authorisation, detection and recovery.

What the server gives away comes first. A regular inventory of paths and files reachable from outside, with forgotten backups, configurations and logs removed, takes away the agent's starting point. It is routine work in an attack surface review.

Credentials come next: multi-factor authentication on user accounts that can reach personal data, secrets held in a vault and kept out of files the server exposes, and short-lived, least-privilege tokens for service accounts. Our guide to non-human identities covers API keys and service accounts, and the glossary explains how to handle compromised credentials.

Authorisation has to be checked object by object. A web application or API security audit that tests, with two different users, whether one can read or change the other's records can find the kind of flaw that, on our hypothesis, this agent used.

Detection needs to recognise automated activity, whether it comes from an agent or a conventional scanner: bursts of requests from a single session, identifiers walked through in sequence, long runs of 403 or 404 errors and changes made in series. Requests that adapt to each previous response point more towards an agent. A managed SOC with behavioural analytics can revoke the session automatically and leave the review to an analyst.

Last comes recovery. Logging every change to personal data along with its previous value makes it possible to know what was altered and put it back, and the incident response plan should cover integrity breaches, not just data theft.

Does notification change when the attacker is an agent?

No. The GDPR notification obligations stay the same. Article 33 requires notification to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the breach, unless it is unlikely to result in a risk to the rights and freedoms of individuals. A processor must notify the controller without undue delay. Where the risk is high, Article 34 generally also requires informing the people affected.

The breach record required by Article 33(5) should also capture signs of automation, the model if it could be identified, the data altered and how it was restored. That information helps the authority understand the case and helps the organisation show due diligence. The EDPB Guidelines 9/2022 on breach notification distinguish between confidentiality, integrity and availability breaches, and, on the notified facts, this case involves at least the first two.

If the logs point to the model provider, reporting the activity through its abuse channel can help shut down the account used, sharing only the personal data strictly needed. In our analysis of breach notices we saw that, in the US, fewer and fewer explain how the attacker got in; here, that explanation is the most useful part of the case file.

The six basics the AEPD returns to

The AEPD ends its post with a list that works as an index for this kind of review: know your processing activities, minimise data, restrict access, fix vulnerabilities, keep suppliers under control and be ready to respond. The first step is to open the risk assessment for each internet-facing processing activity and check whether any of its ratings assumes a patient human attacker.

This analysis draws on information published up to 27 September 2026 by the AEPD, INCIBE-CERT and the outlets cited. The affected organisation, the model used and the exact type of vulnerability have not been made public, and the technical reading of the flaw is the author's hypothesis. It is not legal advice and does not attribute the incident to flaws in any particular product or vendor.