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.
What the law says
Four sections carry the incident regime.
- Section 3.6 defines a confidentiality incident as access, use, or communication of personal information "not authorized by law," or its loss or any other breach of its protection.
- Section 3.5 applies as soon as an enterprise "has cause to believe" an incident has occurred. It must take reasonable measures to reduce the risk of injury and prevent new incidents of the same nature. If the incident presents a risk of serious injury, it must promptly notify the Commission d'accès à l'information (CAI) and the people concerned.
- Section 3.7 says how to assess that risk: consider in particular the sensitivity of the information, the anticipated consequences of its use, and the likelihood it will be used for injurious purposes, and consult the person in charge of the protection of personal information.
- Section 3.8 requires a register of confidentiality incidents. The Regulation respecting confidentiality incidents sets its content and requires keeping each entry for at least five years after the enterprise became aware of the incident.
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.
Is an out-of-scope agent read "not authorized by law"?
The definition does not say "not authorized by the organization." It says "not authorized by law." So the question is what the law authorizes.
Section 20 is the closest answer. Within an enterprise, authorized employees or agents may access personal information without the consent of the person concerned "only if the information is needed for the performance of their duties." Section 12 adds that personal information may be used only for the purposes for which it was collected, subject to listed exceptions.
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.
"Cause to believe" is a low threshold
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.
The register covers every incident, not only the serious ones
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:
- A description of the personal information concerned, or why it cannot be described
- A brief description of the circumstances
- When the incident occurred and when you became aware of it
- The number of persons concerned
- The elements that led you to conclude whether or not there is a risk of serious injury
- The measures taken to reduce the risk of injury
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.
The evidence the risk assessment needs
Every element the regulation asks for maps to a question about the agent. Each question has an answer only if you logged it.
- What personal information was accessed? You need record-level data access logs for the agent's identity, not only the tool call that wrapped them.
- How many people are concerned? Count distinct individuals in the records returned, not queries made.
- What were the circumstances and the cause? You need the agent's trajectory: the task, the tool calls in order, and the control decisions along the way. NIST practice 5.3 asks for tamper-resistant logs "sufficient to reconstruct agent trajectories, tool calls, reasoning traces, user interactions, environmental states, and security-control decisions."
- When did it happen? Reliable timestamps, from systems the agent cannot alter.
- Was it likely to be used for injurious purposes? This is where exfiltration matters. Did the data leave in an outbound request? Was it sent to a model provider as context, and what does that provider retain? Egress logs and your vendor's retention terms answer this; a guess does not.
- How sensitive was it? Sensitivity is the first factor section 3.7 names. Your data classification has to reach the records the agent can touch, or you cannot assess 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.
When your agent reads someone else's data
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.
How we help
- GenAI Security Readiness Assessment. We check whether each agent's data access is logged at the level a Law 25 risk assessment and register entry need, and map findings to sections 3.5 to 3.8 alongside the NIST practices.
- Agent incident runbooks. A decision path from "the agent read something it should not have" to the privacy officer's section 3.7 assessment, the register entry, and, when required, the CAI notice.
- Tabletop exercises. One realistic scenario, run with your security team and your privacy officer in the same room.
Five questions to test yourself
- If an agent opened 300 customer files outside its task yesterday, how would you find out, and how quickly?
- Can you name exactly which records it read, from logs it could not alter?
- Can you prove whether any of that data left your network or reached a model provider?
- Does your incident runbook route agent data access events to your privacy officer?
- Does your confidentiality incident register have any entries involving AI systems? If you run agents and it has none, is that because nothing happened, or because nothing was looked for?