Spain's regulator receives the first breach notification attributing the attack to an AI agent

What happened

On 14 September 2026 the Agencia Española de Protección de Datos published a post on its blog, bylined Francisco Pérez Bes, who has been the agency's deputy since February 2025. It opens by recording that the agency "ha recibido la primera notificación de una brecha de datos personales en la que el incidente habría sido ejecutado mediante un agente de inteligencia artificial que utilizó un conocido modelo de lenguaje" (has received the first notification of a personal data breach in which the incident is said to have been executed by an artificial intelligence agent that used a well-known language model). Quotations here are in Spanish, with this register's translations.

The AEPD gives the whole attack in two sentences. "El agente atacante inició una búsqueda de vulnerabilidades en archivos genéricos, y realizó un login correcto. Una vez accedió al sistema, comenzó a buscar, de forma autónoma, vulnerabilidades en la aplicación, lo que, una vez conseguido, le permitió modificar datos personales y acceder a facturas." (The attacking agent began a search for vulnerabilities in generic files, and performed a successful login. Once it had accessed the system, it began to search, autonomously, for vulnerabilities in the application, which once achieved allowed it to modify personal data and access invoices.)

The agency sets out three caveats before it draws anything from the facts. The available information comes from the notification filed by the affected organisation, and is still to be analysed. The use of a particular model "tampoco implica que el modelo o la infraestructura de su proveedor hayan sido comprometidos ni que la herramienta haya sido diseñada para desarrollar actividades maliciosas" (does not imply either that the model or its provider's infrastructure was compromised, or that the tool was designed to carry out malicious activities). One notification supports no statistical trend.

The sentence most relevant to this entry comes between the second and third caveats. "Ahora bien, lo relevante desde la perspectiva de la protección de datos es que un tercero habría utilizado un agente de IA como instrumento para encadenar exitosamente distintas fases del ataque." (What is relevant from the data protection perspective is that a third party is said to have used an AI agent as an instrument to successfully chain together different phases of the attack.)

The post identifies chaining as what sets an agent apart. An agent "puede recibir un objetivo, planificar tareas intermedias, utilizar herramientas, ejecutar código, consultar fuentes, interpretar resultados y modificar su actuación, de forma autónoma, en función de lo que encuentra" (can receive an objective, plan intermediate tasks, use tools, execute code, consult sources, interpret results and change what it does, autonomously, according to what it finds). On the underlying threat, the agency says: "Cabe recordar que la IA no crea nuevas amenazas." (It is worth recalling that AI does not create new threats.) What changes is speed, scale and adaptability, and the time an organisation has to detect and contain.

The post cites one other document, the Centro Criptológico Nacional's guide CCN-CERT BP/36, Buenas prácticas frente al modelo de IA ofensiva, published on 23 June 2026. The CCN's own announcement of it says offensive AI "ha dejado de ser una amenaza emergente para convertirse en una capacidad operativa integrada en campañas reales de actores criminales y estatales" (has stopped being an emerging threat and become an operational capability integrated into real campaigns by criminal and state actors).

The post leaves out a good deal, as is usual when an authority reports a notification it has not yet analysed. The AEPD does not name the organisation, the sector, the model or the provider. It does not give the date of the attack, the number of people affected, the categories of data, or whether the organisation had to communicate with data subjects under Article 34. It does not say whether the notification met the 72-hour deadline, and it announces no investigation. The incident date recorded in this register's frontmatter is therefore the date of the AEPD's post, which is the only date on the public record.

Several English-language write-ups of this post add material the post does not contain. The most repeated is that "the AEPD's Rule of 2" was violated in this breach. The agency does discuss a Regla de 2, in separate guidance addressed below, and the 14 September post neither names it, links it, nor makes any finding that anything was violated. Others describe the agent modifying invoices, where the text says it modified personal data and accessed invoices. This entry works from the AEPD's own documents.

The duty engaged

This is a personal data breach on the face of the definition. Article 4(12) GDPR defines one as "a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed". The agent modified personal data and reached invoices. On the EDPB's three categories in Guidelines 9/2022, that is an integrity breach and a confidentiality breach at once, which the guidelines expressly allow: "a breach can concern confidentiality, integrity and availability of personal data at the same time, as well as any combination of these."

The 72-hour clock runs from awareness. Article 33(1) requires the controller to notify "without undue delay and, where feasible, not later than 72 hours after having become aware of it", unless the breach is unlikely to result in a risk. The EDPB reads awareness as the point at which the controller "has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised". An agent that runs vulnerability discovery, login and exploitation in one sequence shortens the attack, and the 72 hours still start only when the controller detects it. This register's reading is that the Article 32 question is the one this incident leaves open, and that all four of the consequences the AEPD draws are addressed to it.

Article 32 is measured against the state of the art. The provision requires the controller and processor to "implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk", "taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons". Article 32(2) directs that in assessing the appropriate level of security, "account shall be taken in particular of the risks that are presented by processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data". The state of the art changes over time, for attackers as well as defenders. The AEPD's first and second consequences apply this standard to agents. A risk analysis that names malware, phishing and unauthorised access in generic terms, and a response procedure written for attacks carried out by hand, are both measured against what attackers using agents can now do.

The agency had already published guidance on agentic AI. In February 2026, seven months before this notification, the AEPD published Inteligencia artificial agéntica desde la perspectiva de protección de datos, 76 pages at version 1.2. Its stated scope is the questions that arise "cuando responsables y encargados de tratamiento decidan utilizar sistemas de IA agéntica para implementar tratamientos de datos personales" (when controllers and processors decide to use agentic AI systems to implement processing of personal data). Reading Article 24 onto agents, it says that including an agentic system in a processing operation "indudablemente cambia, al menos, la naturaleza del tratamiento" (undoubtedly changes, at least, the nature of the processing) and may reduce or increase existing risks or create new ones, so the controller "debe realizar un nuevo ciclo de gestión del riesgo en el tratamiento" (must carry out a new cycle of risk management in the processing). Immediately after that comes the Regla de 2, a minimum threshold the guidance describes as first stated in 2021 for browser applications "desde la perspectiva únicamente de ciberseguridad" (from a cybersecurity perspective only) and since "reformulado para el caso de los agentes de IA por distintos autores" (reformulated for the case of AI agents by various authors), footnoting Chromium's rule of 2 and Meta's agent security guidance. It bars an agent from combining three things: processing content with no assurance it is free of attack, unrestricted access to sensitive information, and initiating automatic action. The AEPD calls it "una regla general de mínimos enfocada a ciberseguridad" (a general minimum rule focused on cybersecurity) and a starting point for the analysis. Every one of those conditions is addressed to an agent the controller chose to deploy, and the guidance's worked example is a user's own email auto-reply agent.

That guidance addresses agents the controller deploys. Its threat model is built around them throughout. The nine passages that name an attacker all describe attacks on the controller's own agent: zero-click prompt injection through an incoming email, exfiltration of data disguised as a parameter in the URL of an image the agent fetches, session hijacking and lateral movement across services on the legitimate user's tokens, social engineering aimed at the model, context confusion, delayed triggers, privilege escalation through unnecessary tool calls, and compromise of the agent's memory and activity logs. This register found no passage in the 76 pages about an attacker's own agent turned on an organisation that deployed none. So the first agentic incident the agency received in September falls outside the frame of the agentic guidance it published in February, and the duties that apply to it are the ordinary ones in Articles 32, 33 and 34.

Notification and security are separate duties. The EDPB puts the point plainly when it discusses sanctions: a supervisory authority can act "for failure to notify or communicate the breach (Articles 33 and 34 GDPR) on the one hand, and absence of (adequate) security measures (Article 32 GDPR) on the other hand, as they are two separate infringements." A prompt, complete notification does not answer the security question it discloses.

The post does not say whether data subjects were told. Communication to the data subject is required where the breach "is likely to result in a high risk to the rights and freedoms of natural persons". Personal data modified without authorisation, and invoices reached, will usually clear that bar. The post does not say what the organisation did.

Does the AI Act reach the attacker? Article 3(4) defines a deployer as "a natural or legal person, public authority, agency or other body using an AI system under its authority except where the AI system is used in the course of a personal non-professional activity", and Article 2(10) disapplies the Regulation to deployer obligations of natural persons acting in a purely personal non-professional activity. This register's reading is that a criminal running an agent against a business is using it in the course of a professional activity, so the exclusion does not obviously cover them, and on the face of Article 3(4) they are a deployer. The obligations that attach to an ordinary deployer are light, and enforcement against an unidentified attacker is theoretical. The reading is recorded here in case an attacker is identified.

The model provider's AI Act duties are owed to regulators. Where the model is a general-purpose AI model with systemic risk, Article 55(1) requires the provider to conduct and document adversarial testing "with a view to identifying and mitigating systemic risks", and to "assess and mitigate possible systemic risks at Union level, including their sources, that may stem from the development, the placing on the market, or the use of general-purpose AI models with systemic risk". That obligation reaches use, and a criminal's use of the model is a use. Recital 110 names what kind of use is in view, listing among systemic risks "offensive cyber capabilities, such as the ways in vulnerability discovery, exploitation, or operational use can be enabled". The incident the AEPD describes falls within that description. The duty is owed to the AI Office and to national competent authorities under Article 55(1)(c), and it gives the organisation that was attacked nothing. Article 55(1)(d), which requires an adequate level of cybersecurity protection for the model and its infrastructure, is about protecting the model. The AEPD made the same distinction in its second caveat.

The new Product Liability Directive does not yet apply, and its defectiveness test fits misuse poorly. Directive (EU) 2024/2853 brings software inside the definition of a product, and Article 6(1)(c) allows compensation for "destruction or corruption of data that are not used for professional purposes". It applies to products placed on the market or put into service after 9 December 2026, so no model in service today is inside it. A model is defective under Article 7(1) where it "does not provide the safety that a person is entitled to expect or that is required under Union or national law", assessed on circumstances that include "relevant product safety requirements, including safety-relevant cybersecurity requirements". A general-purpose model that answers a criminal's prompts competently is doing what it was built to do, and this register's reading is that the defectiveness test is a poor fit for misuse by a third party.

The attacker's conduct is criminal in Spain. Article 197 bis(1) of the Código Penal punishes anyone who, by any means, breaching the security measures established to prevent it and without due authorisation, accesses all or part of an information system, with six months to two years in prison. Article 264(1) punishes the unauthorised and serious alteration of another's computer data with six months to three years, where the result is serious.

The liability chain

The register tags this target-carried, a fourth value added for this entry. The three existing labels describe incidents where the organisation, its vendor, or both, put the agent into service. Here a third party ran the agent against an organisation that deployed no agent at all. Calling that deployer-carried would name the attacker as the deployer, which most readers would take to mean the victim. Calling it shared would suggest that the AI supply chain shares a liability which, on the public record, it does not carry.

The organisation attacked carries it. It is the controller. Article 5(1)(f) makes integrity and confidentiality a principle, Article 24(1) makes the controller responsible for implementing appropriate measures and for demonstrating that it has, and Article 32 sets the security standard. The attacker's sophistication is not by itself an answer to Article 32, because the measure is what was appropriate to the risk given the state of the art. The agent found the vulnerabilities it exploited inside the application, after it had logged in, so the application's own security is part of the Article 32 question.

Data subjects sue the controller. Article 82(1) gives anyone who suffers material or non-material damage from an infringement a right to compensation from the controller or processor. Article 82(2) makes any controller involved in the processing liable for damage caused by processing that infringes the Regulation. Article 82(3) offers an exemption where the controller "proves that it is not in any way responsible for the event giving rise to the damage", which is a high bar for an organisation whose own application held the vulnerabilities the agent found.

No GDPR route runs from the victim to the model's provider. It is neither controller nor processor for the attacker's processing, which is the attacker's own, so Article 82 gives the organisation and its data subjects no claim against it. Its AI Act duties are owed to the AI Office and national authorities. The AEPD's second caveat forecloses the easier argument, that the provider's infrastructure was compromised, because nothing on the record says it was.

The attacker is a controller in its own right. Whoever set the objective determined the purposes and means of processing the personal data the agent modified and read. That makes them a controller under Article 4(7), owing the full set of duties, including Article 32 and Article 33. Those duties cannot be enforced while the attacker is unidentified. They are recorded here because they identify who deployed the agent: the same person who faces criminal liability.

The organisation's own suppliers. If the vulnerable application was bought rather than built, the organisation's route to recovery runs through its contract with the supplier, and through Article 28 where the supplier processes on its behalf. The AEPD post says nothing about how the application was sourced.

What would have prevented it

The AEPD draws four consequences, and each maps to a control. A fifth follows from the attack sequence itself, and the agency's later post adds its own list of measures.

Name AI-assisted and AI-executed attacks in the risk analysis. The post is specific that a generic reference will not do: "no basta con incluir una referencia genérica a malware, phishing o acceso no autorizado, pues esta automatización puede modificar sustancialmente la probabilidad, velocidad y alcance del incidente" (it is not enough to include a generic reference to malware, phishing or unauthorised access, since this automation can substantially change the probability, speed and scope of the incident). For a controller that means the Article 32 assessment, and any DPIA, records the agentic case as its own scenario with its own likelihood.

Rewrite response times for machine speed. The agency's second consequence is that procedures designed for manually executed attacks may be insufficient against an agent that analyses several assets at once, tries different access routes, and adapts quickly. Detection and containment that depend on an analyst working through an alert queue are unlikely to act in time.

Protect credentials and limit what an account can do. The agent "realizó un login correcto". The post does not say how it got in, and two readings are open: it used credentials the attacker already held, or the login itself was weakly protected. Either way the AEPD's third consequence is the control. An agent that obtains an account, an API key or a token with excessive permissions "puede operar a la velocidad de una máquina y acceder a diferentes servicios antes de que la organización detecte un comportamiento anómalo" (can operate at machine speed and reach different services before the organisation detects anomalous behaviour). The controls are phishing-resistant multi-factor authentication on the authenticated surface, least privilege on the account that logs in, short-lived tokens, and rate limits that take effect at machine speed.

Support human supervision with automated detection and response. Human supervision stays necessary in the agency's words, and it "debe apoyarse en mecanismos de detección, contención y respuesta capaces de operar con la rapidez suficiente" (must be supported by detection, containment and response mechanisms capable of operating fast enough). Article 32 asks what is appropriate to the risk, and a control that cannot act at the attacker's speed is unlikely to meet that standard.

Fix the application. The agent found vulnerabilities in the application after a successful login, and those vulnerabilities let it modify personal data and reach invoices. The CCN-CERT guide's decálogo of recommendations puts accelerating vulnerability management second in the CCN's own summary of it, behind strengthening essential controls and ahead of securing identities and access.

The AEPD's own list of short-term measures. On 28 September 2026 the agency published a further post, IA ofensiva: cuando la inteligencia artificial acelera el riesgo para la protección de datos, which links back to the 14 September post and reports no further notification of this kind. In a passage on the likelihood of mass personal data breaches it records that "las notificaciones a la AEPD han aumentado un 150 % en 2026 respecto a 2025" (notifications to the AEPD have increased by 150% in 2026 compared with 2025). The post does not say how many of those notifications involved AI. Its short-term measures include "MFA a prueba de phishing, mínimo privilegio, establecer cuentas administrativas separadas" (phishing-resistant MFA, least privilege, establishing separate administrative accounts), managing secrets and tokens and reducing persistent credentials, "puntos de control con supervisión humana en los procesos automatizados" (checkpoints with human supervision in automated processes), and incident procedures that "han de ensayarse en simulacros de incidentes graves de seguridad" (must be rehearsed in drills of serious security incidents). Most of these correspond to the controls above.

Without the organisation's identity, the public record does not show which of these was absent. The 14 September post does not allocate fault, and neither does this entry.

Mapped controls

• GDPR: Article 4(12) (the definition this incident satisfies on both the integrity and confidentiality limbs), Article 5(1)(f), Article 24(1), Article 32(1) and 32(2) (security of processing, measured against the state of the art and the risk), Article 33(1) (notification within 72 hours of awareness), Article 34(1) (communication where a high risk is likely), Article 82 (the route by which affected people reach the controller and nobody else).
• EDPB Guidelines 9/2022 on personal data breach notification, version 2.0: the awareness standard, the three breach categories, and the statement that a failure to notify and an absence of adequate security measures are separate infringements.
• AEPD, Inteligencia artificial agéntica desde la perspectiva de protección de datos, version 1.2, February 2026: the agency's own framework for agents a controller deploys, including the Regla de 2 at section G. No mapping to this incident, and the reason it does not map is the finding above.
• CCN-CERT BP/36, Buenas prácticas frente al modelo de IA ofensiva: its decálogo of recommendations, which the CCN summarises as six priorities, and the treatment of offensive AI as an operational capability in live campaigns rather than a forecast. The AEPD's own Innovation and Technology Lab published a note on the guide on 25 June 2026, so the agency was pointing controllers at it almost three months before this notification arrived.
• EU AI Act: Article 3(4) and Article 2(10) on whether an attacker is a deployer, Article 55(1)(a) and (b) on the provider's duty to assess and mitigate systemic risks stemming from use, Article 55(1)(c) on reporting serious incidents to the AI Office, and Recital 110, which names offensive cyber capabilities among the systemic risks in view. Article 2(8) does not arise, since a model the AEPD describes as well known was in service, and no research or testing exclusion is engaged.
• Directive (EU) 2024/2853 on liability for defective products: Article 4(1) (software is a product), Article 6(1)(c) (corruption of non-professional data is compensable damage), Article 7(1) and 7(2)(f) (the defectiveness test and its cybersecurity limb), Article 2(1) (products placed on the market after 9 December 2026).
• Código Penal: Article 197 bis(1) (unauthorised access to an information system in breach of its security measures) and Article 264(1) (serious unauthorised alteration of another's computer data).
• OWASP Top 10 for Agentic Applications: no mapping. That taxonomy describes ways an agent an organisation deploys can be made to fail. The organisation here deployed no agent, and the taxonomy does not cover attacks carried out with another party's agent.

Sources

• AEPD, "Primera notificación de una brecha de datos personales causada por un ataque ejecutado mediante un agente de IA" - the agency's blog, bylined Francisco Pérez Bes, timestamped 14 September 2026 at 12:54 UTC in the page's own markup. Read in full in Spanish and the source of every quotation attributed to the AEPD here. Re-fetched on 3 October 2026 and unchanged - checked 20 and 21 September and 3 October 2026 [primary]
• AEPD, "IA ofensiva: cuando la inteligencia artificial acelera el riesgo para la protección de datos" - the agency's blog, 28 September 2026, which links back to the 14 September post. Source of the 150% figure and the short-term measures quoted above. It reports no further notification of an attack executed by an AI agent - checked 3 October 2026 [primary]
• AEPD, Inteligencia artificial agéntica desde la perspectiva de protección de datos - version 1.2, February 2026, 76 pages, read in full. Primary for the guidance's stated scope and for the Regla de 2 at section G, including the agency's attribution of the rule to a 2021 browser-security formulation and to later reformulations by various authors - checked 21 September 2026 [primary]
• AEPD, "Lorenzo Cotino Hueso and Francisco Pérez Bes, appointed president and deputy, respectively, of the Spanish Agency for Data Protection" - the agency's own release, 26 February 2025, cited only for the author's role - checked 21 September 2026 [primary]
• Centro Criptológico Nacional, "El Centro Criptológico Nacional alerta del cambio de paradigma que supone la IA ofensiva para la ciberseguridad" - the CCN's announcement of guide BP/36, dated 23 June 2026, and the source of the guide's summary and its ten priorities. The guide's own download page on ccn-cert.cni.es is behind a browser challenge and returns 403 to automated fetchers, so the guide is cited here through the CCN's own announcement of it rather than from the PDF - checked 21 September 2026 [primary]
• AEPD Innovation and Technology Lab, "Guía práctica del CCN-CERT para hacer frente a la IA ofensiva" - dated 25 June 2026, cited for the fact and date of the agency drawing controllers' attention to BP/36 - checked 21 September 2026 [primary]
• Regulation (EU) 2016/679 (GDPR), consolidated text on EUR-Lex - Articles 4(12), 5(1)(f), 24, 32, 33, 34 and 82 quoted from the consolidated text - checked 21 September 2026 [primary]
• EDPB, Guidelines 9/2022 on personal data breach notification under GDPR, version 2.0, adopted 28 March 2023 - the awareness standard at paragraph 31, the breach categories at paragraphs 17 and 18, and the separate-infringements statement at paragraph 28 - checked 21 September 2026 [primary]
• Regulation (EU) 2024/1689 (EU AI Act), Official Journal text - Articles 2, 3(4), 3(65) and 55, and Recital 110 - checked 21 September 2026. Regulation (EU) 2026/1744 (the Digital Omnibus on AI, OJ L 24 July 2026) was read on 3 October 2026: it amends Article 2(2) and 2(7) and adds Article 2(13), and does not amend Article 2(8), 2(10), 3(4) or 55 [primary]
• Directive (EU) 2024/2853 on liability for defective products, Official Journal text - Articles 2, 4, 6, 7 and 22 - checked 21 September 2026 [primary]
• Código Penal (Ley Orgánica 10/1995), consolidated text at the Boletín Oficial del Estado - Articles 197 bis and 264 - checked 21 September 2026 [primary]

Cite this entry as: Onyekwere, Michael K., AIR-2026-015, AI Agent Incident Register, CompanyScope, https://companyscope.io/register/air-2026-015, as at 2026-10-03. Entry IDs are stable; corrections publish as dated addenda on this page. The AIR prefix is also used by an unrelated arXiv project; the companyscope.io URL identifies this register.

This analysis is the work Janus Compliance does for clients before the incident. For a fixed-scope read of your own EU AI Act Article 50 exposure, see the Article 50 teardown; for ongoing agent governance, Janus DPO-as-a-Service. New entries are delivered free through Compliance Engineering on Substack. Browse the full register or the vendor compliance index.