When the regulator asks what your agent did, your prompt isn't the answer

Spain's data protection authority has logged something it hasn't seen before: a breach notification describing an attack run end to end by an autonomous AI agent.

Before this becomes the next round of "the robots are coming", the facts are thinner than the headlines. The affected company hasn't been named. The scale hasn't been disclosed. The AEPD hasn't verified the mechanism, and the security researchers quoted on it say there isn't yet enough detail to confirm what actually happened.

So I'm not going to tell you what this incident proves. I'm going to tell you what it changes for anyone who, like my team, ships agents into enterprise workflows. That part doesn't depend on the details.

What the notification describes

According to the AEPD, the agent chained three phases on its own:

Phase   What the agent did
01      Searched generic files for weaknesses, achieved a successful login
02      Once inside, probed the application for vulnerabilities
03      Modified personal data and accessed invoices

None of those steps is new. Credential abuse, vulnerability discovery and data access are the oldest script in the book. The AEPD's stated reason for calling this novel is the chaining: the phases were linked without a human steering between them.

The regulator's own framing is the line worth keeping. AI doesn't create new threats. It increases the speed, scale and adaptability of cyberattacks.

That's the whole story, really. The playbook is old. The tempo isn't.

Why this lands on the builder's desk

Most of the conversation about agent security still happens at the prompt layer. System prompts. Guardrail filters. Refusal tuning. Jailbreak red-teaming.

That work matters, but it answers a question about what the model is willing to say. It doesn't answer the question an incident review asks. When a regulator, an auditor or your own board reconstructs an incident, nobody reads your system prompt. They ask:

• What did the agent actually do, and in what order?
• Under whose authority did each action run?
• What data left the environment, and where did it go?
• How fast can you prove all of that?

If your agent stack can't answer those, the prompt engineering behind it is a seatbelt sticker. It isn't the seatbelt.

There's a symmetry here worth sitting with. The capability that let this attacker chain phases without supervision is exactly what we sell internally as productivity: agents that plan, call tools, read results and adapt. Whatever we'd want to know about a hostile agent in someone else's system, we should be able to say about our own agents in ours.

Three controls that survive an incident review

1. Per-action authorisation

Session-level trust is the default in most agent setups. Authenticate once, hand the agent a key, let it loop. That's how you end up with an agent allowed to do everything its credentials permit, rather than everything its task requires.

The shift is to authorise every tool call:

• A policy check on each action against the task's declared scope
• Short-lived, least-privilege credentials minted per task, not per deployment
• Human approval for irreversible or bulk operations
• Deny by default when an action drifts from the stated intent

Guardrails shape what an agent says. Authorisation governs what it does.

2. Egress logging

Breach scope is ultimately a question about what left. If you can't answer it, you can't bound the notification, and you end up declaring the worst case.

• Every outbound call tied to an agent, a task and a named human owner
• Destination allow-lists, deny by default
• Data classification tags that travel with outbound payloads
• Alerts on volume spikes and exfiltration-shaped patterns

No egress log means no breach scope.

3. Reconstruction-ready trails

Most agent observability today is built for dashboards: token spend, latency, success rates. Useful, and close to useless in front of a regulator. The trail you need looks different:

• An append-only, time-ordered record of plan, tool call and result for every step
• Every step linked to the identity and credential it used
• A timeline you can replay in hours, not weeks
• Retention and access designed around your notification clocks

Those clocks are short. GDPR gives controllers 72 hours to notify the supervisory authority after becoming aware of a personal data breach. In India, CERT-In expects cyber incidents to be reported within six hours of noticing them. Your reconstruction speed is your compliance speed.

What the AEPD is asking organisations to change

The regulator's guidance points the same way. It asks organisations to:

• Include AI-assisted attacks and adversarial agents in their risk analysis
• Revisit incident response procedures designed for manual, human-paced attacks
• Strengthen the protection of digital identities and credentials
• Back human supervision with fast detection, containment and response

Read that list as a builder and it's a spec. Risk analysis that assumes agents. Response that runs at machine speed. Identity as the control plane. Humans in the loop, but not as the only loop.

What this doesn't say

It doesn't say frontier models are compromised. Researchers have floated several explanations, from a jailbroken model to unauthorised penetration testing, and confirming autonomous AI use wouldn't by itself mean a model provider's infrastructure was breached.

It doesn't say this is the first agentic attack anywhere. It's the first such notification the AEPD says it has received.

And it doesn't say your prompt layer is wasted effort. It says that layer is the wrong place to look for evidence.

The question worth asking this week

Pick one agent your team runs in production. Imagine it did something it shouldn't have at 3am.

By 9am, could you show exactly which actions it took, under which credential, what data it touched, and what left the building?

If the answer is yes, you have agent governance. If the answer is "we'd check the logs and hope", you have a demo that happens to be in production.

Attackers are getting agents that don't sleep. Ours need audit trails that don't blink.

Sources: SecurityWeek and BleepingComputer, 16 September 2026. The AEPD's statement is quoted in English translation as reported. Notification windows: GDPR Article 33 (72 hours) and CERT-In Directions of 28 April 2022 (six hours). Related: What I learned restructuring an engineering org around AI agents.