When an AI Agent Reads Too Much: Law 25 Confidentiality Incidents

Posted on Nov 2 • Originally published at codacon.ai

In October, India's national CERT reported that AI agents under evaluation had reached live systems of Indian organizations and read business records containing personal and confidential information ( CIAD-2026-0049 ). None of the affected organizations detected it. The AI providers told them.

Now move the scenario to Quebec, and make it closer to home. An agent you deployed, running with credentials you issued, is asked to summarize open support tickets. Along the way it opens customer files that have nothing to do with the task. Nothing leaves your network, as far as you know.

Is that a confidentiality incident under Law 25? If it is, the clock on your obligations has already started, and the evidence you need to meet them lives in logs you may not keep.

We are security practitioners, not lawyers. This post explains how the obligations meet agent architecture; your counsel decides how they apply to you. Section references are to Quebec's private sector privacy act, as amended by Law 25.

Four sections carry the incident regime.

Failing to report a confidentiality incident is one of the grounds for an administrative monetary penalty under section 90.1, as we covered in our Law 25 and generative AI overview.

The definition does not say "not authorized by the organization." It says "not authorized by law." So the question is what the law authorizes.

An AI agent is not an employee, and probably not an agent in the legal sense of a mandatary. But it acts under an identity your enterprise issued, so its access is your enterprise's access. If the information it opened was not needed for the task it was given, there is a credible argument that the access was not authorized by law, even though your access controls allowed it. Technical permission and legal authorization are different tests.

That is an argument, not a ruling. The CAI has not, to our knowledge, published a decision on an AI agent's access. The practical consequence is still clear: an out-of-scope read of personal information by an agent is a candidate incident. It goes to your privacy officer for assessment, not into a debugging ticket.

Section 3.5 does not wait for certainty. It applies when you have cause to believe an incident occurred. In an agent deployment, that cause usually arrives as a log line: a tool call that returned customer records, an alert from a data access monitor, a canary record that was read.

Two consequences follow. First, the moment of awareness matters, because the register records both when the incident occurred and when you became aware of it. CERT-In's victims became aware when a third party told them. Second, an enterprise without record-level logging of agent data access may never reach "cause to believe" at all. That is not compliance. It is blindness.

Notification to the CAI applies only when there is a risk of serious injury. The register applies to every confidentiality incident. Under the regulation, each entry needs, among other things:

The CAI can ask for a copy at any time. An agent that read 300 customer files outside its scope, with no evidence of exfiltration, may well not be notifiable. It is still an entry, and the entry must explain why you concluded the risk was not serious.

Distinguish this from a near-miss. If your controls blocked the agent before it read anything, no personal information was accessed and there is no confidentiality incident. Record it as a near-miss in your security process, as the NIST, NSA and CISA key practices recommend. If the agent read the records and nothing bad happened afterwards, that is not a near-miss. That is an incident with a favourable risk assessment.

Every element the regulation asks for maps to a question about the agent. Each question has an answer only if you logged it.

If your logs cannot answer these questions, the risk assessment defaults to uncertainty. Uncertainty about what an agent read and where it went is a poor basis for concluding that the risk of serious injury is low.

CERT-In's case runs the other way too. If your agent reaches another organization's system, that organization holds the personal information and carries the section 3.5 duties. You hold the evidence. NIST practice 8.1 asks operators to notify parties whose systems were compromised, including third parties who were not the final target. Practice 8.2 asks them to share timelines and transcripts. Have that notification path written before you need it.