AI agents and confidential data: an architecture that protects

The security question we get about a custom AI agent is almost always the same one: "is the model vendor serious?" Fair question, one layer too late. Your contract with Anthropic or OpenAI governs what those companies do with data once they have it. It says nothing about what your agent sends them, or about who inside your company can get the agent talking about a file that is none of their business.

That second layer is what actually protects you, and it's the one we design. A well-architected agent sends little, reads according to the rights of the person asking, keeps even less, and leaves a verifiable trace of what it did. Here are the five decisions that do that work, with the data policies actually in force at the two main API vendors, read off their official pages in August 2026.

The short answer, for the busy

Protecting confidential data in an AI agent is an architecture problem, not a vendor-promise problem. Five decisions do the work. Minimize at ingestion: the agent receives only the fields a task needs, never the whole record, which section 5 of Quebec's Law 25 already requires. Read by permission: the agent answering an employee sees only what that employee is allowed to see. Configure the API: neither Anthropic nor OpenAI trains on API data by default, Anthropic deletes API inputs and outputs within 30 days, OpenAI keeps abuse-monitoring logs for up to 30 days, and zero data retention exists but by approval and with carve-outs. Know where the data physically travels, since anything leaving Quebec triggers section 17 and its privacy impact assessment. Log the decision and its coordinates rather than the full prompt, then give that log an expiry date, because section 23 requires destroying information once its purpose is achieved.

The real perimeter isn't the vendor contract

Section 10 of Quebec's Act respecting the protection of personal information in the private sector (P-39.1, "Law 25") requires security measures that are "reasonable given the sensitivity of the information, the purposes for which it is to be used, the quantity and distribution of the information and the medium on which it is stored".

Reread the word "quantity". The volume of personal information involved is part of how the reasonableness of your measures gets judged. The amount of data your agent handles is therefore a compliance parameter in its own right: an agent that receives three fields per request does not create the same risk as one wired into your whole CRM, and does not call for the same protections. Shrinking what the agent sees is the cheapest security measure available, and the most effective.

Falling short of section 10 is also listed among the penal offences in section 91, where fines for a company run from $15,000 to $25M, or 4% of worldwide turnover for the preceding fiscal year if that amount is higher.

Minimize at ingestion: the agent doesn't need your whole CRM

The default architecture, the one you see in demos, hands the agent broad access and trusts it to use only what it needs. Comfortable to build, indefensible to document.

The architecture that holds does the opposite. For each task, you define the smallest set of fields that gets it done. The agent qualifying a service request receives the problem description and an internal identifier, not the name, address and billing history. The one drafting a payment reminder receives the amount and the due date, not the full file. When a sensitive field has to travel, you replace it with a token only your own application can resolve. Section 5 of Law 25 already says the essential part: anyone collecting personal information "may collect only the information necessary for the purposes determined before collecting it".

There's a very concrete reason to take this seriously. Anthropic states plainly that for paid API customers, ad hoc deletion is not supported: you cannot ask for a specific request to be erased. The only data you can be certain was never stored anywhere is the data you didn't send.

Read by permission, not through a service account

Here is the most common architecture mistake, and the quietest. You index the internal documentation, the contracts, the HR files and the email into one vector store, wire the agent to it with a service account that has every right, and put a chat box in front. The agent works beautifully. It also answers the warehouse employee who asks what their manager earns, because nothing in that chain knows who is asking.

The fix is a design decision, taken early. The identity of the person querying the agent has to travel all the way down to the data layer, and retrieval has to run with their rights. Every indexed document carries the same access restrictions it has in its source system, and the filtering happens before the content enters the model's context, never afterwards through an instruction like "don't reveal salaries". A line in a prompt is a courtesy, not an access control.

The test takes a minute: open the agent with a limited-rights employee account, ask a question whose answer sits in a document they can't reach, and watch. Before go-live, then after every new data source.

The API settings nobody reads

Both vendors have changed these policies more than once. Here is what their official pages say in August 2026.

Anthropic. By default, inputs and outputs from commercial products, including the API, are not used to train the models. They are automatically deleted from Anthropic's backend within 30 days of receipt or generation, with exceptions (a longer-retention service you control such as the Files API, a contrary agreement, Usage Policy enforcement, legal obligation). A zero data retention arrangement exists, granted per organization after approval: Anthropic then stores neither prompts nor responses once the response has been returned. One wrinkle since June 9, 2026: models designated "covered models" (Claude Fable 5 and Claude Mythos 5) require 30-day retention and are not available under zero retention. And in every case, content flagged by the automated safety systems can be kept for up to two years.

OpenAI. Since March 1, 2023, data sent to the API is not used to train the models unless you explicitly opt in. Abuse monitoring logs are generated for all API feature usage and retained for up to 30 days, unless longer retention is legally required or reasonably necessary to protect the service or a third party. Zero Data Retention and Modified Abuse Monitoring exist, subject to OpenAI's prior approval. Two caveats worth knowing: OpenAI reserves the right to make certain models ineligible for those regimes for a given customer, with written notice, and zero retention does not cover every endpoint. Stateful endpoints (/v1/conversations, /v1/assistants, /v1/threads, /v1/vector_stores) retain data until you delete it, and are not eligible for zero data retention.

That's the architectural lesson: zero retention gets verified endpoint by endpoint, never at the level of the project. An agent that switches to a stateful feature to keep conversation history reintroduces storage the contract does not cancel.

Then there's geography. Anthropic's residency parameter, inference_geo, accepts only "global" or "us", and workspace geography is currently limited to "us". No Canadian option on the direct API, so section 17 applies. The obligations and the workable setups are in your AI agent runs on American servers.

Log without hoarding

An agent in production needs a trail: to explain a decision, diagnose an error, answer a complaint. The temptation is to record every prompt and every response in full. You have just created a second copy of the personal information, usually less well protected than the first, and subject to the same obligations.

Log the decision and its coordinates instead: timestamp, requester identity, action taken, sources consulted by reference, whether it escalated to a human. The content stays in its source system, where it is already governed. Then set a retention period for the log, because section 23 requires destroying or anonymizing the information once the purposes for which it was collected or used are achieved, subject to any preservation period set by another statute. A log with no expiry date is a warehouse that keeps growing.

The questions that separate a governed agent from a paste into ChatGPT

An employee pasting a client contract into a consumer tool to move faster is shadow AI, and it's the most common scenario in small companies. We devote a full article to it: employees and shadow AI. A governed agent is the answer to that, provided it can answer five questions.

Which fields exactly leave for the model, for each task? How does the agent know what the person querying it is allowed to see? Which API endpoints are in use, and which of them hold state? What goes into the log, and how long do you keep it? What happens when the agent isn't sure?

That last one runs into governing the agent once it's live, which we cover in hallucinations and errors. A vendor who answers all five without checking with anyone designed the architecture. A vendor who answers "it's secure, we use Claude" read a sales page.

Where to start

Take the task you want to hand to an agent and write down, in one line, the fields it genuinely needs. The list is almost always shorter than what the system would send by default, and that gap is your risk.

That's the first exercise we run with a client: map what has to move, decide who sees what, choose the API settings accordingly, before the first line of code. 30 minutes, no commitment, and if the architecture you already have holds up, we'll say so.

→ First conversation, no commitment

This piece is general information, not legal advice. For anything involving sensitive information or a decision with real consequences, consult qualified legal counsel. The authoritative sources are the Commission d'accès à l'information and the statutes published on LégisQuébec.