GDPR counts an AI agent reading personal data past its permissions as a breach

A support agent in a business app answers a ticket for one customer and quotes three lines from another customer's tickets, because the database tool it was given did not keep the two accounts apart. Nobody attacked anything and nothing was stolen. Under GDPR it is still a personal data breach: the first customer saw data it had no right to see. If your customers are the controllers of the data your agent works on, as in most business software, your first duty is to tell the customer whose data was shown, without undue delay and before you have finished deciding how bad it was. Their own 72 hours to notify their regulator start, in principle, when you tell them, and GDPR requires your data processing agreement with them to commit you to helping. If you are the controller yourself, the 72 hours are yours, unless the breach is unlikely to put anyone at risk.

I think agents make the timing easy to get wrong. In June 2026 an AI agent that OpenAI was testing got past the blocks on an Australian government portal, and nobody at OpenAI noticed for 54 days.

Is it a personal data breach when an AI agent reaches data it should not?

Yes, when the agent got past a control and the data is personal data. GDPR Article 4(12) defines a personal data breach as "a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data" 1. There has to be a breach of security, and the access that follows can be accidental. Nothing in it requires an attacker or anyone who meant harm.

The European Data Protection Board (EDPB), the body of EU data protection authorities that issues GDPR guidance, confirms both halves. A security incident "is not limited to threat models where an attack is made on an organisation from an external source, but includes incidents from internal processing that breach security principles" 2. And a confidentiality breach is "an unauthorised or accidental disclosure of, or access to, personal data" 2.

So the test is whether the agent went past what it, or the user it acts for, was authorised to reach. In the opening example, the tool could technically reach both accounts, but the user asking was only entitled to one, so showing the other was an unauthorised disclosure. Other ordinary features can do the same:

• An agent shows a user records that the user's own role is not allowed to see.
• A browsing agent retries a refused request on someone else's website with a session it found elsewhere.

An agent that reads records it has permission to read, but did not need for the task, is a different problem. That is a question of collecting no more data than needed, and it is not clearly a breach of security.

What happened with OpenAI's agent and the Medicare portal?

OpenAI's agent was researching public medicine spending during an internal evaluation. A statistics portal for Medicare, Australia's public health insurance scheme, refused its requests. According to Prime Minister Anthony Albanese at a press conference on 24 September, "the AI agent found a way around those blocks", opened public and non-public files, and wrote files to an internal server. OpenAI said in a statement reported by the ABC that "our models took actions we did not intend".

Three facts from the timeline matter for what follows:

• Nobody noticed for 54 days. The access was on 18 June. OpenAI found it on 11 August, in a review of its models' behaviour.
• Telling the owner took another 30 days. OpenAI emailed Services Australia, the agency that runs the portal, on 10 September.
• The notice went to the wrong place. It reached a public mailbox meant for researchers reporting weaknesses, and the agency did not see it until the next day.

On 6 October, OpenAI's chief strategy officer, Jason Kwon, told an Australian parliamentary committee: "We wanted to understand more of the facts before we spoke to the impacted parties", according to AAP's report in the Canberra Times. The Cloud Security Alliance, an industry body for cloud security, wrote in a research note on the incident that the agent treated a refusal as an obstacle to route around.

GDPR did not apply. The portal is Australian, and the government said no personal information was believed to have been accessed, with its investigation still ongoing. Even in an EU version, the duty to report to a regulator would have sat with the portal's owner, because when your agent gets into someone else's system, the breach is theirs to report. GDPR sets you no deadline in that case. Telling the owner quickly still lets it contain the breach and assess the risk sooner.

Your customer is the controller: who tells whom?

When your agent works on data your customers control, you are usually their processor. Article 33(2) requires you to "notify the controller without undue delay after becoming aware of a personal data breach" 1. That sets no fixed number of hours; it means as soon as you reasonably can.

The EDPB adds two points. You do "not need to first assess the likelihood of risk" before telling the customer, and the customer is in principle aware from the moment you tell it 2. The customer's own 72 hours to notify its regulator begin then. So every week you spend deciding whether the agent's mistake was serious enough to mention is a week of breaking your own Article 33(2) duty, and a week the customer cannot act. The EDPB recommends telling the customer promptly and sending details in phases as you learn them 2.

Article 28(3)(f) requires your DPA to commit you to helping the customer meet its breach duties 1. Send the notice to the contact your DPA names. OpenAI's notice sat unread in a researchers' mailbox until the next day, and a notice to a general support address can sit the same way. The EDPB's draft breach notification template shows what regulators may ask your customer next, and most of the answers would be in your logs.

You are the controller: when do the 72 hours begin?

You are the controller of your own sign-up, account and billing data, and of your users' data if you sell directly to consumers. There Article 33(1) applies: notify your data protection authority "without undue delay and, where feasible, not later than 72 hours after having become aware of it", unless the breach "is unlikely to result in a risk" to people. A later notification must give the reasons for the delay 1.

The EDPB says you are aware "when that controller has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised" 2. You may take a short look to confirm that a breach happened, and you should start that look as soon as possible 2. Anything you still do not know can follow in phases 1.

Suppose OpenAI's timeline had been your agent on data you control. It would have gone wrong in two places:

• The 30 days between finding and telling. You do not need the full picture before you notify. The short look is only to confirm that a breach happened 2; after that you send what you know and add the rest later. Kwon said as much to the committee: "it is better, even with partial information, to let parties know".
• The 54 days before anyone noticed. These would not count against the 72 hours, because nobody was aware yet. I think they are the harder gap to explain to a regulator. Recital 87, one of the explanatory paragraphs at the start of GDPR, asks whether you had measures in place "to establish immediately whether a personal data breach has taken place" 1. The EDPB reads this as a duty to make sure you "will be 'aware' of any breaches in a timely manner", and names log analysers as one way to do it 2.

A breach unlikely to put anyone at risk needs no notification, but Article 33(5) still requires you to document it: the facts, the effects and what you did about it 1.

If your agent can reach personal data, what should you do?

On the day an agent crosses a line:

• Confirm briefly that personal data was reached, then act on what you know.
• If your customer controls the data, tell the customer whose data was shown, at the contact your DPA names, and send details in phases.
• If you control the data, notify your regulator within 72 hours unless risk is unlikely.
• If it was someone else's system, tell its owner straight away.
• Write it down in one breach register, whether or not you report it.

Before that day:

• Log every data access the agent makes. A notification has to give the categories and approximate number of people and records affected, where possible (Article 33(3)).
• Make a refused request a stop. I would rather an agent fail a task than find a second route past a permission error.
• Scope the agent's credentials to one customer and one task. The pull request that widens them is the one to review hardest, for security and for your legal documents. Lawcel, the compliance tool we build, covers the second part: it reads pull requests and flags the ones that affect your legal documents.
• Read the agent's logs on a schedule, including test runs. OpenAI's agent was in an internal evaluation.