The situation
A consulting firm holds a contract with a federal department to evaluate a benefits program. The work involves Protected B records: case summaries, client complaint files and internal assessments. A senior analyst is behind on a deliverable. She copies three pages of case notes into a public AI tool on her work laptop and asks for a thematic summary. The summary is useful. The case notes are now with an AI provider that has no security screening, no approval from the Contract Security Program, and no contract with the department.
The analyst had a valid reliability screening and every right to read the notes. The problem was where she sent them. Our post on a widely reported case involving a senior US cybersecurity official shows that seniority and training do not prevent this on their own.
What the rules actually say
The first thing to get right is who is bound by what. Federal employees and federal suppliers answer to different instruments, and they are often confused.
What binds public servants: the Treasury Board guide
The Treasury Board of Canada Secretariat's Guide on the use of generative artificial intelligence, most recently updated in September 2026, is guidance addressed to federal institutions. It states that public servants must not enter personal information into publicly available online generative AI tools, explaining that doing so would be an unlawful disclosure because the supplier might keep a copy. It also advises against entering sensitive or personal information into any tool not managed by the Government of Canada, tells institutions to use infrastructure appropriate to the security classification of the information, and says the institution's chief security officer should approve generative AI use for protected or other sensitive information.
The guide does not name Protected B and does not directly bind suppliers, but it tells you what your client department's own staff are expected to do.
What binds suppliers: the contract and the Contract Security Program
A supplier's obligations come from its contract. When a contract involves protected information, the contracting authority attaches a security requirements check list, and the supplier must hold the appropriate organization screening through the Contract Security Program run by Public Services and Procurement Canada. Protected B, as the program's levels of security page explains, covers information whose compromise could cause serious injury to a person, organization or government.
The Contract Security Manual, which applies to organizations awarded contracts with security requirements, sets two rules that settle the AI question for most suppliers. Access to protected information must be limited to people with the appropriate security level and a need to know. And organizations must not store, process or create protected information on an IT system until the program has issued written IT approval.
The program's IT security requirements page adds that the program does not evaluate or endorse cloud services on its own. Cloud use requires a Canadian Centre for Cyber Security assessment and approval signed by the client department's chief security officer. A public AI tool used through a personal or unmanaged account meets neither condition.
We did not find guidance from the Contract Security Program that addresses generative AI by name. The general rules above are what apply. Confirm your position with your company security officer, the program and your contracting authority.
Why policies and bans fall short
Most cleared suppliers already have a security policy, security briefings and a company security officer. What they often lack is anything at the moment an employee decides to paste. Security briefings happen at onboarding and at intervals; AI prompts happen many times a day.
Blocking AI domains on the corporate network is common and reasonable for protected work, but consulting and professional services firms rarely do only federal work. The same staff use AI legitimately for commercial clients, often on the same laptop and browser, and a blanket block pushes that activity to personal devices. The distinction that matters is not which tool, but what information is going into it. IBM's 2025 Cost of a Data Breach research found that 63% of organizations have no AI governance policy at all, so many suppliers are starting from even less.
Turning off training in an AI tool's settings does not change the analysis either. As our post on the opt-out illusion explains, an opt-out narrows one use of the data. It does not make an unapproved system an approved one.
What a practical control looks like
- Map which contracts carry protected information. Tie each to its security requirements check list and the people with access.
- State the rule plainly. Protected information never goes into any AI tool unless that specific tool has written approval from the program and the client department. Put this in security briefings.
- Separate protected work where possible. Use approved systems and workspaces for protected contracts, and keep general AI use for commercial work away from them.
- Give staff an approved AI option for non-protected work. People who have a sanctioned tool for ordinary tasks are less likely to improvise.
- Rehearse the incident path. Everyone should know that a suspected disclosure goes to the company security officer at once, and the officer should know the reporting route to the program and the department.
- Prepare your evidence. Departments and prime contractors may ask about your AI controls. Our guide to the AI section of security questionnaires covers how to answer.
Sanitized Ai is a browser extension that adds a check at the moment of risk. When someone pastes or uploads content containing personal information, confidential business details or other sensitive data into a major AI assistant, it redacts or blocks that content before submission and explains in plain language what was flagged and why. That turns a security briefing into a reminder at the exact point it is needed. It supports your approved systems and your security officer's judgment; it does not replace Contract Security Program approval or make any tool suitable for protected information.
Your company security officer sees a dashboard of flagged-event metadata (which tool, what type of data, which policy, when) without seeing prompt content. That gives audit-ready records of caught-before-submission events, useful when a department asks how staff are prevented from sending contract information to AI tools. Our security awareness page describes how the coaching side works.