Under GDPR, an AI agent causes a personal data breach if it leads to accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of or access to personal data. Sending one customer's details to another, following an injected instruction to export records, or overwriting data are all breaches. Each must be assessed, recorded and, where risky, notified.
What does GDPR treat as a breach?
GDPR defines a personal data breach, in substance, as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. Three types are usually distinguished:
- Confidentiality breach: unauthorised or accidental disclosure of, or access to, personal data.
- Integrity breach: unauthorised or accidental alteration of personal data.
- Availability breach: accidental or unauthorised loss of access to, or destruction of, personal data.
Intent is irrelevant. An honest mistake is a breach if it meets the definition. And a breach of security here means any failure of the measures meant to protect the data, not only an outside attack.
What must happen after one?
In substance, GDPR requires:
- Notify the supervisory authority without undue delay and within a short fixed deadline after becoming aware of the breach, unless it is unlikely to result in a risk to people's rights and freedoms. Late notifications must explain the delay.
- Notify affected people without undue delay where the breach is likely to result in a high risk to them, in clear language, unless an exception applies, such as the data being unintelligible to anyone who accessed it.
- Processors notify controllers without undue delay after becoming aware.
- Document every breach, whether notified or not: the facts, effects and remedial action.
The controller makes these decisions. An agent platform provider acting as processor must tell you promptly; it does not decide for you.
How do agents cause breaches?
Agents act on data at speed and at scale, often with broad access. That creates breach routes that differ from those of ordinary systems:
Misdirected disclosure. An agent replies to the wrong customer, attaches the wrong document, or includes another person's details in a summary. A confidentiality breach, often affecting one or two people, but repeatable at volume if the cause is systematic.
Manipulation by outside content. An instruction hidden in an email or uploaded file tells the agent to send records to an outside address or reveal another customer's data. A confidentiality breach caused by a security failure. The OWASP Top 10 for LLM applications lists prompt injection and sensitive information disclosure for this reason.
Over-sharing with tools. An agent sends personal data to a tool or service that is not approved to receive it. A disclosure to an unauthorised recipient.
Wrong writes. An agent overwrites a customer's contact details or merges two records. An integrity breach, and sometimes an availability breach if the original is lost.
Deletion. An agent with delete rights removes records it should not. An availability breach.
Minimising what the agent can reach limits all of these; see GDPR data minimisation for AI agents. Special category data raises the severity of any breach; see GDPR special category data and AI agents.
How do you prevent, detect and handle agent breaches?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Security of processing | Agent access scoped to the case and fields needed; no delete rights unless required | Access configuration |
| Resist manipulation | Outside content marked and unable to authorise disclosure or action | Provenance on each input; refusal records |
| Approved recipients only | Agent may send data only to listed tools and verified recipients | Recipient allow-list; refusal records |
| Prevent misdirection | Recipient identity checked against the case before any outbound message | Check records |
| Detect | Alerts on unusual outbound volume, new recipients and cross-case data | Alert log |
| Contain | Stop control halts the capability; pending messages cancelled | Stop events |
| Assess | Breach assessment using the action record to identify every affected person | Assessment with affected list |
| Notify authority | Within the deadline where risk is likely | Notification and reference |
| Notify people | Where high risk is likely | Communications sent |
| Document | Breach register entry for every breach | Register |
The assessment step is where the action record earns its keep. Without a log of every message the agent sent and every record it touched, you cannot know who was affected, and you may have to over-notify or guess. Our playbook on how to assess personal data breaches for notification with an AI agent covers the agent's role in that work.
What will a supervisor or auditor ask?
- What happened, and how many people were affected? How do you know?
- When did you become aware, and when did you notify?
- Why could the agent reach this data or send to this recipient?
- How did outside content influence the agent, if it did?
- What have you changed to stop it recurring?
What does the breach regime not cover?
It does not cover errors that do not involve personal data. It does not require notification of breaches unlikely to result in risk, though they must be recorded. It does not replace reporting duties under other regimes, such as DORA for major ICT incidents at financial entities or the EU AI Act's serious incident duty for high-risk systems. And it does not apportion blame between controller and processor; contracts and other rules do. For the full map, see AI agent regulation, mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Where Pryme fits
In Pryme, content that arrives from outside, such as an emailed invoice or a web page, carries the external provenance class, and an external claim cannot authorise a payment or a disclosure. Every verdict is filed, so the list of records an agent touched during an incident comes from the record, not from estimates.
Questions people ask
Is an agent showing the wrong customer's balance a breach?
Yes. It is an unauthorised disclosure of personal data. Whether it must be notified depends on the risk to the person, but it must be recorded either way.
Does a prompt injection attempt that failed count as a breach?
No, if no personal data was disclosed, altered or lost. Record it as a security event and review why it was attempted and how it was stopped.
Who notifies if the agent platform caused the breach?
The controller notifies the authority and affected people. The platform, as processor, must tell the controller without undue delay and help with the assessment.