On 14 September the Spanish data protection authority published that it had received the first notification of a personal data breach that "would have been executed by means of an artificial intelligence agent" — its own conditional, not ours. The whole attack fits in one sentence. That sentence is what interests us, and not because of the attacker: because of what it took to be able to write it.
Let us start with the conditional, which has gone missing from nearly all of this week's coverage. The authority warns before it recounts anything: prior to any kind of conclusion, it notes, the available information comes from the notification filed by the affected organisation and will have to be analysed in due course. What is confirmed, then, is the notification; the attribution is what the organisation that suffered it says. And there is no company name, no sector, no figures, so this is not an analysis of the incident: it is a reading of four administrative lines as what they will eventually be for somebody else — a form. We will give away the conclusion up front, because it is the part that does not sell: of the four phases, three are stopped by boring things that involve no AI at all.
The four phases, in the authority's own words
"The attacking agent began a search for vulnerabilities in generic files, and performed a successful login. Once it had accessed the system, it began searching, autonomously, for vulnerabilities in the application, which, once achieved, allowed it to modify personal data and access invoices." (our translation of the original Spanish)
It is signed by Francisco Pérez Bes, the authority's Deputy to the Presidency. Of the model it says only that it was "a well-known language model", without naming it. And the sentence is best not stretched further than it goes: about this particular case the authority asserts nothing beyond those four phases, and the "autonomously" is attached to just one of them — the search for vulnerabilities inside the application. The rest of what has been read into it this week ("it planned", "it adapted") comes from a different paragraph, the one describing in general what an agent is capable of: an agent can receive an objective, plan intermediate tasks, use tools, run code, consult sources, interpret results and alter its behaviour, autonomously, according to what it finds. That is a catalogue of capabilities, not the record of the incident.
What the notification does not say (and what you should not fill in for it)
It does not say which organisation, in which sector, or how many people were affected. It does not say which model. It does not say how long it lasted, whether anything alerted, or who noticed. And above all: it does not say where the credentials for that successful login came from. In a four-line entry all those gaps are legitimate — the authority is not publishing a forensic report, it is flagging a vector. The problem is what the industry does with the gaps.
The authority does not say this. We do, and it is a conjecture: the first two sentences belong together. "Generic files" is the vocabulary of a sweep across known paths — a forgotten backup, a configuration file served in the clear, a dump with a date in its name. If one of those paths returns something with credentials inside it, the "successful login" in the next sentence stops being a mystery and becomes the consequence of the one before. It is the same mechanism we were discussing this very morning: the vendor publishes the flaw, but your own configuration decides the exposure.
A successful login sets off nothing
Between phase one and phase three sits an authentication that worked. Not an authentication bypass, not a forged token, not a privilege escalation: a login. That breaks the mental model many people build their monitoring on, because the controls nearly everybody has watching the front door count failed attempts. Faced with this sequence they had nothing to count. The door opened first time.
This is where Zero Trust stops being a brochure word and becomes a concrete, slightly uncomfortable decision: assume a perfectly valid session can be hostile, and therefore that authentication is not the end of the control but the beginning. What follows a successful login — what that session reaches, how many different things it touches, at what pace — is exactly what mattered here. And the symmetry with your own agents is uncomfortable on purpose: when you connect an agent to your systems with a person's token, the target system's log records the person, not the agent. The same blind spot, in both directions.
Now put yourself on the other side of the form
The authority also publishes, quite apart from this news, its standing reminder: the deadline for notifying the supervisory authority is 72 hours from the moment the organisation becomes aware of the breach, the notification is filed through the electronic portal "to ensure correct fulfilment of the obligations of Article 33.3 GDPR", and the controller is additionally obliged to document "any personal data breach, including the facts relating to it, its effects and the remedial action taken".
Read the order of those three words again: facts, effects, remedial action. The four phases that open this article are precisely the first of them. Somebody was able to reconstruct four phases, put them in order, and tell which came from an external sweep and which from inside the application. That does not come out of anyone's intuition: it comes out of records. So the uncomfortable question is not whether your application is vulnerable — it is, and so is mine. It is this: with what you keep today, could you write those four sentences about yourself within three days?
Phase by phase, the record you need to assert it
- 1"A search for vulnerabilities in generic files" → the web server access log, with the 404s in it and with enough retention. Everybody has one; from what we find when we come in to audit a platform, it rarely holds more than a fortnight and hardly anyone ever reads it. What gives this phase away is not one 404: it is hundreds, in dictionary order, from the same address.
- 2"Performed a successful login" → an authentication record with user, source address, timestamp and session duration, stored beyond the reach of whoever just walked in. If your access records live on the same machine, the same disk and under the same permissions as the application, that is not evidence: it is a note the visitor can edit.
- 3"Autonomously" → this comes out of no log at all: it is inferred. Cadence without pauses, systematic rather than erratic coverage, continuous activity at four in the morning, the same
User-Agentand the same parameter order request after request, and not one path half-typed or repeated by mistake. To sustain it you need precise timestamps correlated across layers. It is the most fragile claim in the whole notification, and the one you will find hardest to defend if you ever have to write it. - 4"Modify personal data and access invoices" → a change record at the level of the data itself: which row, what the previous value was, by whom and when. It is the one we least often find in place, and the only one that answers point (a) of Article 33.3 GDPR: describe the nature of the breach and, where possible, the categories and approximate number of data subjects and of personal data records concerned. That "where possible" is your only way out if you lack the record, and it is the worst of them: your notification will say the scope could not be determined, which is admissible and comforts nobody.
What the authority now expects in writing
The entry ends with homework. The first item is the one that changes paperwork: incorporate attacks assisted or executed by AI expressly into the risk assessments of your processing activities. The rest is a list you could have read ten years ago: know your processing, minimise the data, limit access, fix vulnerabilities, supervise your suppliers and be ready to respond. It also asks you to review response times and to tighten controls over identities and credentials.
Look at those six verbs: not one of them is new. What is new is the adverb. Expressly. A risk assessment that does not name a scenario does not cover it, and until now the absence was invisible; since 14 September there is a precedent published by the authority, and the absence reads differently. For the technical detail the authority points to the Spanish national cryptologic centre's guide CCN-CERT BP/36, of June 2026, whose central argument is that offensive AI makes it possible to "automate, accelerate and scale up attacks that are already known". The last three words are worth rereading: already known.
And no, this is not fixed by buying something with "AI" in the name
The predictable thing is that this headline becomes a sales argument over the autumn, so let us say the part that does not sell. Of the four phases, three are stopped by things you could already have done last year: take out of the server root the files that should never have been published, put a second factor on authentication, and keep a place where changes to the data are written down and which cannot be wiped from inside the application. None of the three involves AI. None of the three is expensive. All three are boring, and that is exactly why they are still outstanding in so many places.
And now the part we have to say even though it does not suit us. If you are a company of fifteen people with one line-of-business application, you do not need a SIEM. We monitor with Zabbix and SmokePing, on our own platform and on our clients', and we run them by a single rule: alerts that matter, not noise. Deploying a SIEM to satisfy a recommendation is the most reliable way we know of ending up with a permanently red dashboard nobody reads, and that is worse than not having it: the alert ignored every day teaches people to ignore the one that matters. Start with retention and with writing changes down; correlation comes afterwards, and if there is nobody watching it at four in the morning, it comes delegated to somebody who is or it does not come at all. Deciding it the other way round is how technologies get bought and switched off six months later.
The half-hour test
Five questions, with one rule: every answer has to be a number, a file name or a system name. A "yes" does not count as an answer.
- 1How many days of web access log do you keep today, and are the 404s in it or discarded?
- 2Which file or system would you open to find out who logged in successfully at 03:00 the day before yesterday, and from what address?
- 3If somebody with a valid session changed a customer's bank details, where would the previous value be written down, and who can delete that place?
- 4Within how many hours could you say how many people are affected and in which data categories? If the figure is over 72, you have a compliance problem that depends on no attacker at all.
- 5Does the word "AI" appear in your risk assessment, and in which specific scenario?
If three of the five answers are "we would have to check", the work you have outstanding is not security work. It is record-keeping work. And those are two very different budgets.
The bar this notification sets
The headline says AI now attacks on its own, and that is true. What the notification says, read slowly, is less spectacular and considerably more useful: there was an organisation able to describe precisely, in phases and in order, what had happened to it. That is the bar 14 September sets, and it has nothing to do with buying anything. Almost every conversation we have starts the other way round, with "we think they got in over there", and that sentence cannot be written into the regulator's form.
We wrote about the speed of the other side a few weeks ago, when the problem stopped being finding the flaw and became the calendar that follows it. This is the other half of the same thing: if the attacker does not sleep, your advantage is not running faster. It is being able to reconstruct what happened without depending on anybody's memory.
Sources (verified on 2026-09-26): the literal description of the four phases, the conditional («habría sido ejecutada»), the caveat that the information «deberá ser objeto del correspondiente análisis», the generic definition of an agent, the reference to «un conocido modelo de lenguaje» and the recommendations quoted — blog entry of the Spanish data protection authority, 14 September 2026, signed by Francisco Pérez Bes. The entry is in Spanish and every English rendering on this page is our own translation. His role as Deputy to the Presidency of the authority (Royal Decree 143/2025, sworn in on 3 March 2025) is not stated in that entry but in the authority's own press release. The 72-hour deadline from the moment the organisation becomes aware, the electronic filing form and the obligations of Article 33.3 GDPR — the authority's security breach page; the documentation duty is quoted from the official English text of Article 33.5 GDPR, «comprising the facts relating to the personal data breach, its effects and the remedial action taken». The phrase «automatizar, acelerar y ampliar a gran escala ataques ya conocidos» and the guide's framing — note from the authority's Innovation Lab; the guide's date is on the cover of CCN-CERT BP/36 itself ("security guide, June 2026"). What is ours and not the sources': the conjecture that the "successful login" may come from the generic-file sweep (flagged as a conjecture in the text), the list of records per phase, the signals for inferring automation, the warning about SIEMs and the five questions. Our experience with Zabbix and SmokePing in production is what we do, not a study: we do not present it as a statistic. The authority publishes no organisation name, sector, duration or number of affected individuals, and this article does not fill those in. Cover photo: "Archivmagazin Schweizerisches Wirtschaftsarchiv 01", Wikimedia Commons (CC0).
Could you write those four sentences about yourself in 72 hours?
At everyWAN we run that test with the client in the room: which records exist, how long they last, who can delete them, and which sentence could be defended in front of the authority. Out of that comes the compliance and continuity plan — with the AI-assisted attack scenario written down rather than assumed — and, where real watching at three in the morning is needed, the part covered by managed EDR/MDR. If what you are missing is retention rather than a product, we will tell you that too.
Talk to everyWAN
Microsoft 365
ES 
CAT 
EN