Spain's Data Regulator Got Its First Breach Report Where the Attacker Was an AI Agent. Its Advice Is About Your Clock, Not the Model

Most incident response plans carry an assumption so basic nobody writes it down: the attacker works at human speed. They log in, look around, stop, come back later, try something else. That pace is what the plan leans on. It is why an alert reviewed the next morning still usually counts as early.

This week Spain's data protection authority told organisations to stop relying on it.

On September 14, 2026, the Agencia Española de Protección de Datos (AEPD) published a blog post describing the first personal data breach notification it has received in which the attack was carried out by an AI agent. The agent was built on a known large language model. The organisation has not been named. The story was picked up by BleepingComputer and much of the Spanish press over the following days.

The attack itself was not new. What caught the regulator's attention was who was running it.

What the notification describes

The AEPD's account is short, and it comes from the organisation's own notification rather than a finished investigation. The regulator says so explicitly. Put together, the sequence runs like this:

1. Reconnaissance. The agent began by searching generic, publicly reachable files for weaknesses.
2. A successful login. It then authenticated to the system. The AEPD describes it as a correct login, not a brute-force attempt or an exploit against the login page.
3. Autonomous probing inside the application. Once in, the agent searched the application itself for vulnerabilities, on its own.
4. Impact. What it found let it modify personal data and access invoices.

Two caveats from the regulator are worth repeating, because headlines tend to drop them. First, everything above is what the affected organisation reported, and it is still being analysed. Second, the AEPD stresses that the use of a particular AI model does not mean the model or its provider's infrastructure was compromised, or that the tool was built for attacks. Someone pointed a general-purpose agent at a target and let it plan the steps.

The number of people affected has not been disclosed. Nor has the sector, the model, or how the agent got working credentials.

"AI does not create new threats"

The most useful line in the post is the one that sounds least alarming. The AEPD writes that AI does not create new threats, but that it increases the speed, scale and adaptive capacity of known malicious techniques, and so shrinks the margin organisations have to respond.

Look at the four steps again. None of them is novel: recon on exposed files, a valid login, poking at an authenticated application, then tampering with records. A pentester would recognise every one. The difference is that a person running that sequence gets tired, takes breaks and has to decide what to try next. An agent does not stop between steps. It reads the result of one attempt and moves on to the next in seconds.

That lines up with what model providers have been reporting from the other side. On Tuesday we covered Anthropic's September threat report, which described intrusions run on stolen AI API keys. The AEPD notification is the same trend from the victim's side, and this time it comes from a regulator describing a formal breach notification, not from a vendor's research blog.

The regulator's advice is mostly about time

The AEPD closes with ten recommendations. Several are standard data protection advice: know your processing, minimise what you collect, limit access permissions, fix vulnerabilities, supervise your suppliers, have an incident response procedure ready.

Four of them are specific to this case, and they are the ones worth reading closely:

• Put AI-assisted and AI-executed attacks explicitly into your risk analysis. Not as a footnote under "emerging threats", but as a scenario with its own likelihood and impact.
• Review response-time procedures that were designed for manual attacks. The AEPD is not asking for a new team. It is asking whether your current timings still make sense.
• Prioritise digital identity and credential management. The agent got in with a login that worked.
• Implement automated detection, containment and response that doesn't depend only on someone watching.

The second one is the most uncomfortable, because it asks a question most runbooks can't answer honestly. If an alert fires at 21:40 and the first person looks at it at 08:30, that has always been a known gap. Against a person working at human speed, the attacker might still be doing reconnaissance by morning. Against an agent that went from login to modified records without stopping, the incident may be over by morning, and you are the one who has to work out afterwards what happened.

Why the 72-hour clock gets harder, not easier

For any organisation under GDPR, this is also a notification problem. Article 33 gives a controller 72 hours from becoming aware of a breach to notify the supervisory authority. The notification is expected to describe the nature of the breach, the categories and approximate number of people and records concerned, and the likely consequences.

Two details from the AEPD case make that harder than usual.

The login was valid. An attack that starts with a correct authentication doesn't leave an obvious break-in to date the incident from. The access log shows a user doing what users do. The question "when did this start?" becomes a question about behaviour — when did this session stop looking like a person? — and that is only answerable if you kept a record detailed enough to show it.

Data was modified, not just read. A breach where records were changed is harder to scope than one where they were copied. You need to know which records were touched, what they said before, and whether any downstream process has already used the altered values. A record that was quietly changed can stay wrong for a long time, because nobody thinks to go back and check it.

Neither of those is a problem an AI model created. Both get worse when the attacker covers more ground in an hour than a person would in a week.

What to do with this now

For security and privacy teams, the practical steps are:

1. Run the scenario. Take the AEPD sequence (recon, valid login, in-app probing, data change) and walk it through your own detection. For each step, write down which log would show it, who would see it, and when. The gaps you find are your real response time.
2. Treat valid-credential sessions as something to watch, not trust. Look at behaviour inside a session: request rate, the spread of endpoints touched, error bursts from repeated malformed requests, writes to records the account doesn't normally touch. Speed is the giveaway. People don't hit forty endpoints in a minute.
3. Close the overnight gap for high-impact actions. For bulk writes to personal data or access to financial documents, decide in advance what happens automatically, such as step-up authentication, a session kill or a rate limit, rather than what a person will decide in the morning.
4. Keep the evidence off the box. Application and access logs need to be shipped somewhere central as they happen, with enough detail to rebuild a session. That is what makes the Article 33 questions answerable inside 72 hours.
5. Fix the application flaws, not just the perimeter. The agent found its way through the application after login. Vulnerabilities in authenticated parts of an app tend to get deprioritised because "you'd need an account first". This case is a reminder that the account was the easy part.

Where Obiguard fits

The boundary first. Obiguard SOC does not block logins or enforce step-up authentication, and it does not sit inline in front of your application to stop a request mid-flight. The containment in step 3 above belongs in your identity provider, WAF or application. What SOC addresses is the other half of the AEPD's advice: detection that doesn't wait for a person to go looking, and a record detailed enough to scope what happened afterwards.

Machine-speed probing shows up in the trace data. An agent looking for vulnerabilities inside an application sends a burst of unusual requests, and most of them fail. SOC ingests distributed traces over OpenTelemetry and shows latency and error rate per service. The Service Map builds itself from that traffic, so a sudden rise in errors on the service behind your invoicing screens shows up where someone will see it, alongside whatever it calls downstream. That is the in-app probing step from the AEPD account, seen as a change in how the service behaves, not a rule someone had to anticipate.

The session reads as one story. Live Logs streams application, access and host events in real time, filterable by source and full text. When the question is "what did this login do between 21:40 and 21:52?", the answer is one filtered view, not an export from three systems. Alerts fire on log-volume changes and rule matches without detection rules to write first, and each alert keeps its evidence timeline linked back to the raw events. That timeline is what the Article 33 notification is built from.

The application's own weaknesses get found first. The agent in this case found something exploitable after it logged in. SOC's CVE Radar scans every connected repository for vulnerable dependencies on every push and daily. Threat Intelligence then checks each finding against CISA's KEV catalog and FIRST.org's EPSS scores, so a flaw that is already being exploited moves to the top of the queue. Every commit also gets an automatic LLM code review. That won't catch every logic bug in an authenticated workflow, but it moves some of the AEPD's "remediate vulnerabilities" advice from a quarterly audit into every push.

If your own teams are building agents with access to personal data, the attribution question is the mirror image of this one. That is what Governance AI and its audit ledger are for. We looked at the supply-chain version of that risk yesterday.

The uncomfortable part

The AEPD's notification will not be the last, and the next one will probably be less remarkable. That is the point. When the regulator says AI creates no new threats, it is not playing the risk down. It is saying the attack techniques you already defend against are now available to anyone with an agent and a working set of credentials, running at a speed your response plan was never timed for.

So the question for your security and privacy teams is not would we recognise an AI attacker? There may be nothing to recognise. It is: if a valid login started probing our application at 21:40 tonight, what would we know by 21:52, and what would we be able to tell the regulator in 72 hours?

Explore Obiguard SOC or talk to us about detection and evidence that work on an attacker's schedule rather than your team's.