Does the AEPD case mean AI agents require a new threat category?

The agency's own answer is no. Its blog post states that AI does not create new threats and instead increases the speed, scale and adaptive capacity of known malicious techniques. What changes is the detection and containment window, and the requirement that risk analyses name AI-assisted and AI-executed attacks explicitly rather than folding them into generic malware wording. A new category is not required, and a new line in the existing register is.

Whose agent carried out the attack in the AEPD case?

The AEPD describes a third party using an AI agent as the instrument of the attack. The agency has not published the affected organisation, the sector, or the model the agent was built on. Coverage that identifies any of those is going beyond the primary record, and a controller citing this case in a board paper should stay with what the agency itself stated.

How does this change an Article 33 notification?

The 72-hour deadline and the required content are unchanged. The difficulty is evidential. An attack chained by an agent produces many actions in a short window, and the notification still asks for categories of data, approximate record counts, and likely consequences. Controllers that can attribute each action to an authorising identity at a timestamp answer within the window. Controllers relying on logs written by the compromised application answer with estimates.

Where does DeepInspect fit against this incident?

DeepInspect evaluates HTTP traffic between authenticated users or agents and LLM endpoints, and produces a per-decision record of each policy outcome. Credential-based login to an internal application, vulnerability scanning, and direct modification of stored personal data are outside that boundary. The relevant coverage is an organisation's own agent-to-model traffic, where identity-bound authorisation and an independent record apply.

Spain's AEPD Logged the First Breach Notification Where an AI Agent Was the Actor

On September 14, 2026, the Agencia Española de Protección de Datos received a personal data breach notification in which the operative actor was an AI agent rather than a person. Francisco Pérez Bes published the account on the AEPD blog the following day. The agent searched for application vulnerabilities, completed a login using valid credentials, modified users' personal data, and pulled the affected entity's invoices. A third party used the agent as the instrument for the whole chain.

The regulator's own framing is the part worth arguing with your risk committee about, because it refuses the dramatic reading.

TL;DR

The AEPD received its first breach notification attributing the attack to an AI agent on September 14, 2026, and published the account on September 15.
The AEPD position is that AI creates no new threat category, and instead raises the speed, scale and adaptability of known techniques.
The agency now expects controllers to write AI-assisted and AI-executed attacks explicitly into Article 32 risk analyses, because generic malware and unauthorised access wording no longer covers the case.
Most of the reported mechanism sits outside any AI gateway's reach, and the part a gateway does cover is an organisation's own agent traffic to model endpoints.
Under Articles 33 and 34 the useful evidence is which identity authorised which action against which system at what time.

What the AEPD actually recorded

The AEPD's post describes a sequence rather than a single exploit. Vulnerability searches ran against generic files, credentials were then used successfully to complete a login, users' personal data was modified, and invoices belonging to the affected entity were accessed. The agency says a third party would have used an AI agent as the instrument chaining those phases together.

The agency has not disclosed the affected organisation, the model behind the agent, or the sector, and the Help Net Security report of September 17 adds no identifying detail either. Treat any version of this story that supplies those details as invention.

The line the AEPD chose to lead with is deflationary: "La IA no crea nuevas amenazas. Pero sí aumenta la velocidad, escala y capacidad de adaptación de técnicas maliciosas ya conocidas." AI creates no new threats, it raises the speed, scale and adaptive capacity of malicious techniques already known. That sentence should end the argument about whether this needs a separate threat taxonomy.

The Article 32 instruction is the operative part

Article 32 of the GDPR requires security of processing appropriate to the risk. The AEPD's directive is that controllers must "incorporar expresamente los ataques asistidos o ejecutados mediante IA a los análisis de riesgos". A generic reference to malware or unauthorised access no longer discharges the analysis.

That is a documentation change with teeth, because a risk analysis is one of the first artefacts a supervisory authority asks for after a notification. A register that lists "ransomware" and "insider misuse" and stops there now reads as out of date against a regulator's published expectation, dated September 2026.

The agency's accompanying guidance runs to the unglamorous list: know your processing activities, minimise data, limit access, correct vulnerabilities, supervise vendors, and have an incident response plan ready. Nothing on that list is new. The AEPD's point is that compressed attack timelines change how quickly each one has to work.

Where this sits against the enforcement boundary

Most of what the AEPD describes is conventional intrusion against the victim's own systems. Credential-based login, vulnerability scanning of internal applications, direct modification of stored records, retrieval of invoice files. None of that is HTTP traffic between an authenticated user or agent and an LLM, and a policy gateway defends none of it. Say that plainly before anyone in a vendor meeting suggests otherwise.

The slice that is in scope runs in the other direction. An organisation that runs its own agents generates outbound HTTP calls from those agents to model APIs. That traffic is where an unsanctioned or over-scoped internal agent first becomes visible, ahead of whatever it does downstream. The argument here is a mirror of the AEPD case rather than a defence against it, and it is worth keeping the two apart in writing.

Read that alongside the post-authentication gap: authentication establishes who is calling, and the separate question of what this specific caller may do with this specific content stays unanswered in most deployments.

Notification under Articles 33 and 34 when the actor is an agent

Article 33 gives the controller 72 hours to notify the supervisory authority, and Article 34 governs communication to affected individuals where the risk is high. Both notifications ask for the nature of the breach, categories and approximate numbers of records, likely consequences, and measures taken.

When a human operator runs the intrusion, the answers come from session logs and endpoint telemetry. When the operative actor is an agent working without step-by-step direction, the reconstruction needs a record that ties each action to an authorising identity at a timestamp. Application logs written by the same system that was compromised are self-attestation, which is the weakest form of evidence a controller can offer.

Our own AI agent incident response material covers the runbook side. The record-keeping question sits alongside it, and it is the one that determines whether a 72-hour notification contains facts or estimates.

What to change in the risk register this quarter

Add AI-executed and AI-assisted attack scenarios as named entries rather than a footnote under malware. For each one, state the affected processing operation, the data categories, and the control that would detect or stop it.

Record which internal agents exist, what they are authorised to reach, and which identity their outbound model calls carry. Anything answered with "the runtime's service account" is a finding, not a control.

Then rehearse the notification itself. Pick one internal agent, assume it acted outside its scope on a Tuesday afternoon, and write the Article 33 form from your existing logs. The gaps show up in about twenty minutes, which is faster than any tabletop exercise I have watched run to conclusion. The GDPR and AI overview covers how the rest of the regime interacts with this.

One caution on scope. This is a data protection authority acting under the GDPR, not an EU AI Act action. The two regimes carry different obligations and different enforcement routes, and the comparison between them is worth keeping straight in any briefing you write off the back of this.

DeepInspect

DeepInspect provides an independent policy decision at the HTTP AI request boundary. For an organisation's own agents calling model endpoints, it evaluates the application-supplied identity and role against policy for the content classification and model authorisation before the request is forwarded.

Each decision produces a signed, tamper-evident record held outside the calling application's write path. When the reconstruction question is which identity authorised which model call at what moment, that record answers it without asking the system under investigation to describe its own behaviour.

Book a technical deep dive at deepinspect.ai.