Canada ITSG-33 et IA : répondre au cadre de contrôle de sécurité du CST dans des environnements agentiques
Les agences fédérales canadiennes, leurs sous-traitants et les organisations du secteur privé qui traitent des informations classifiées gouvernementales déploient des agents IA pour automatiser le traitement documentaire, les services aux citoyens, la revue réglementaire et l’administration des programmes.
De nombreux workflows impliquent des informations Protégé A et Protégé B — les classifications canadiennes pour les données gouvernementales sensibles dont la divulgation non autorisée pourrait causer un préjudice sérieux aux personnes, aux organisations ou au fonctionnement du gouvernement.
Ces déploiements d’agents IA relèvent donc pleinement de l’ITSG-33, le cadre de gestion de la sécurité des technologies de l’information publié par le Centre canadien pour la cybersécurité.
L’ITSG-33 est le référentiel canadien de gestion des risques en sécurité IT, étroitement aligné sur le NIST 800-53, et sert de base aux évaluations de sécurité cloud, aux exigences du Programme de sécurité des contrats et à l’autorisation cloud équivalente à FedRAMP dans le contexte fédéral canadien.
Comme ses équivalents américains, l’ITSG-33 n’accorde aucune exemption aux agents IA ou aux systèmes automatisés accédant à des informations protégées. Les contrôles d’accès, exigences d’audit, obligations de chiffrement et exigences de réponse aux incidents qui protègent l’accès des employés humains aux données Protégé B s’appliquent également à l’accès des agents IA.
Cet article détaille les exigences de l’ITSG-33 pour les workflows dopés à l’IA traitant des informations gouvernementales protégées, identifie les écarts de conformité générés par les déploiements d’agents dans le contexte canadien, présente les bonnes pratiques pour encadrer l’accès des agents IA aux données Protégé A et B, et explique pourquoi la gouvernance au niveau de la donnée constitue l’architecture la plus adaptée pour répondre aux exigences de contrôle de sécurité de l’ITSG-33 pour les systèmes à base d’agents.
Résumé Exécutif
À retenir : Les contrôles de sécurité de l’ITSG-33 — contrôle d’accès, audit et responsabilité, identification et authentification, protection des systèmes et des communications, réponse aux incidents — s’appliquent aux agents IA accédant aux informations Protégé A et Protégé B. Les agences gouvernementales canadiennes et leurs sous-traitants qui déploient l’IA sur des workflows traitant des informations protégées sans adapter leurs contrôles de sécurité pour couvrir les agents IA présentent des écarts de conformité que le Secrétariat du Conseil du Trésor et le Centre canadien pour la cybersécurité examineront de plus en plus.
Pourquoi c’est important : Les organisations manipulant des données Protégé B risquent l’exclusion des marchés publics fédéraux, l’obligation de notifier toute violation en vertu de la LPRPDE, et des sanctions pouvant atteindre 10 millions de dollars canadiens selon la Loi 25 du Québec en cas de non-conformité. Le Programme de sécurité des contrats évalue les organisations et leur posture de sécurité avant d’autoriser l’accès aux données Protégé B — et un déploiement IA dépourvu des contrôles de gouvernance des données requis par l’ITSG-33 constitue un risque de conformité qui impacte tous les contrats gouvernementaux détenus par l’organisation.
Résumé des points clés
- Les contrôles de sécurité de l’ITSG-33 s’appliquent sans exception aux agents IA accédant aux informations Protégé A et B. Le cadre régit l’accès aux informations gouvernementales classifiées, que l’utilisateur soit humain ou automatisé. Un agent IA qui lit, traite ou transmet des données Protégé B est soumis aux mêmes exigences de contrôle d’accès, d’audit et de chiffrement qu’un employé humain effectuant la même tâche.
- Les données Protégé B doivent rester sur le territoire canadien — y compris lorsqu’elles sont traitées par des systèmes IA. Les services cloud utilisés pour traiter des données Protégé B doivent être évalués par le Centre canadien pour la cybersécurité selon le profil PBMM (Protégé B/Intégrité moyenne/Disponibilité moyenne). Les pipelines d’inférence IA qui font transiter des données Protégé B par une infrastructure cloud non évaluée, ou sans garantie de résidence des données au Canada, créent un risque de souveraineté des données non couvert par l’ITSG-33.
- Les exigences d’audit de l’ITSG-33 imposent des journaux détaillés pour chaque accès aux données Protégé B. La famille de contrôles AU (Audit et responsabilité) du cadre exige que chaque accès à des informations protégées soit consigné au niveau de l’opération : quoi, par qui, avec quelle autorisation, et quand. Les agents IA utilisant des comptes de service partagés produisent des journaux qui ne répondent à aucune de ces exigences. La traçabilité doit relier chaque accès Protégé B à une personne autorisée identifiable.
- Les exigences de contrôle d’accès de l’ITSG-33 s’étendent aux workflows d’agents IA au niveau de l’opération. La famille de contrôles AC impose que l’accès aux informations protégées soit limité aux utilisateurs et processus autorisés, avec des contrôles d’accès basés sur les rôles appliquant le principe du moindre privilège. Pour les agents IA, cela signifie que l’accès doit être limité, opération par opération, uniquement aux données Protégé B nécessaires à la tâche — et non accordé globalement via des identifiants de compte de service à large périmètre.
- L’évaluation du Programme de sécurité des contrats pour votre déploiement IA est un enjeu d’éligibilité aux marchés publics. Les organisations souhaitant répondre à des marchés fédéraux impliquant des données Protégé B doivent prouver que leurs systèmes d’information — y compris les systèmes IA — respectent les contrôles de sécurité requis pour ce niveau de classification. Un déploiement IA incapable de démontrer des contrôles d’accès, une traçabilité et une résidence des données conformes à l’ITSG-33 pour les données Protégé B représente un risque pour l’éligibilité aux marchés, et pas seulement un problème technique de conformité.
Exigences de l’ITSG-33 pour les workflows IA
L’ITSG-33 propose un catalogue de contrôles de sécurité organisés en classes techniques, opérationnelles et de gestion, alignées sur le NIST SP 800-53. Pour la conformité Protégé B/PBMM, quatre familles de contrôles sont directement concernées par les déploiements d’agents IA : Contrôle d’accès (AC), Audit et responsabilité (AU), Identification et authentification (IA), et Protection des systèmes et des communications (SC). Chacune correspond à des fonctions que la plupart des déploiements IA actuels ne couvrent pas.
Contrôle d’accès (famille AC)
Les contrôles AC de l’ITSG-33 exigent que l’accès aux informations Protégé B soit limité aux utilisateurs et processus autorisés, avec application du principe du moindre privilège. Pour les agents IA, cela implique deux choses. D’abord, l’agent doit disposer d’une identité authentifiée et vérifiable avant tout accès à des informations protégées. Ensuite, l’accès doit être limité au strict nécessaire pour la tâche : un agent autorisé à lire un dossier protégé n’est pas automatiquement autorisé à télécharger tous les fichiers, transmettre des données à l’externe ou accéder à d’autres catégories d’informations protégées. Le contrôle d’accès basé sur les attributs, évalué à l’opération, est le mécanisme adapté pour les systèmes à base d’agents.
Audit et responsabilité (famille AU)
La famille de contrôles AU impose un audit détaillé de tous les accès aux données Protégé B, avec des journaux protégés contre toute altération. Le journal d’audit doit indiquer qui a accédé à l’information protégée, quoi, quelle opération a été réalisée, et quand — dans un format exploitable pour les audits de conformité et les enquêtes forensiques. Les agents IA utilisant des comptes de service partagés produisent des journaux d’infrastructure qui consignent les appels API sans le niveau de détail opérationnel, d’attribution individuelle ou de protection contre la falsification exigé par la famille AU. Les journaux standards d’inférence IA ne sont pas conformes à l’ITSG-33 pour les accès Protégé B.
Identification et authentification (famille IA)
Les contrôles IA de l’ITSG-33 imposent que chaque utilisateur et processus soit identifié et authentifié de façon unique avant d’accéder à des informations protégées. L’authentification multifactorielle est requise pour l’accès aux systèmes Protégé B. Pour les agents IA, cela signifie que chaque agent doit disposer d’un identifiant unique — et non d’un compte de service partagé — lié au workflow spécifique et à l’humain ayant délégué la tâche. Si plusieurs agents partagent des identifiants, ou si l’authentification ne permet pas de remonter à un décideur humain précis, les contrôles IA ne peuvent être considérés comme satisfaits.
Protection des systèmes et des communications (famille SC)
Les contrôles SC imposent le chiffrement AES-256 des données Protégé B en transit et au repos. Pour les déploiements d’agents IA, cela signifie que chaque composant du pipeline d’inférence — appels API, environnement d’inférence du modèle, bases vectorielles, stockages temporaires, canaux de restitution — doit chiffrer les données Protégé B avec des implémentations cryptographiques validées. La confidentialité, l’intégrité et la disponibilité des données Protégé B doivent être garanties sur tout le parcours de la donnée, et pas seulement au niveau de l’application principale.
Résidence des données Protégé B : l’exigence d’évaluation cloud
L’une des exigences opérationnelles majeures de l’ITSG-33 pour les déploiements IA concerne l’obligation d’évaluation des services cloud. Les services cloud utilisés pour traiter des charges Protégé B doivent être évalués par le Centre canadien pour la cybersécurité selon le profil PBMM.
Cette évaluation vérifie que l’infrastructure cloud respecte les contrôles de sécurité pour les données Protégé B — y compris la résidence des données au Canada. Les agents IA qui traitent des données Protégé B via des services cloud non évalués PBMM, ou sans documentation sur la résidence canadienne des données, opèrent hors du périmètre autorisé pour ce niveau de classification.
Les régions cloud commerciales généralistes — y compris les régions canadiennes des grands hyperscalers non spécifiquement évaluées PBMM — ne satisfont pas automatiquement à cette exigence.
Quelles normes de conformité des données sont essentielles ?
Pour en savoir plus :
Où les déploiements IA créent des écarts de conformité ITSG-33
Les écarts de conformité générés par les déploiements d’agents IA dans les environnements régis par l’ITSG-33 sont structurellement similaires à ceux observés dans d’autres cadres réglementaires, avec une dimension supplémentaire : l’exigence canadienne de résidence des données et d’évaluation cloud PBMM crée une exposition au niveau de l’infrastructure qui ne peut être résolue par une simple configuration applicative.
Infrastructure cloud non évaluée pour les workloads IA Protégé B
L’écart ITSG-33 le plus courant dans les déploiements IA canadiens est l’utilisation d’une infrastructure cloud non évaluée selon le profil PBMM. Les principales plateformes IA — fournisseurs LLM commerciaux, services d’orchestration IA, éditeurs de bases vectorielles — fonctionnent généralement sur des clouds multi-régions sans évaluation PBMM du CCE pour le contexte gouvernemental canadien. Les organisations qui déploient ces plateformes sur des workflows Protégé B traitent donc des informations classifiées gouvernementales sur une infrastructure hors périmètre, quelle que soit la configuration des contrôles d’accès applicatifs.
Comptes de service partagés et absence d’attribution individuelle
L’ITSG-33 ne peut être respecté si les agents IA utilisent des identifiants de compte de service partagés. Lorsque plusieurs agents IA partagent un compte de service, le journal d’audit ne permet pas d’attribuer un accès Protégé B à une personne autorisée précise. Le Programme de sécurité des contrats exige que les organisations prouvent qui a accédé à l’information protégée — un journal d’audit mentionnant un compte de service plutôt qu’une personne ne satisfait pas à cette exigence pour les données Protégé B.
Chiffrement insuffisant sur tout le pipeline d’inférence IA
Les contrôles SC de l’ITSG-33 imposent le chiffrement AES-256 des données Protégé B en transit et au repos. Les pipelines d’inférence IA comportent de nombreux points de transit et de stockage : appels API au modèle, environnement d’inférence, bases vectorielles, canaux de restitution. Les organisations qui n’ont validé le chiffrement qu’au niveau applicatif principal n’ont pas forcément vérifié la couverture sur chaque segment du pipeline. Tout segment non chiffré représente une faille SC pour toute donnée Protégé B qui y transite.
Bonnes pratiques pour un accès agent IA conforme à l’ITSG-33
1. Utiliser une infrastructure cloud évaluée PBMM pour les workloads IA Protégé B
Toute pipeline d’inférence IA traitant des données Protégé B doit fonctionner sur une infrastructure cloud évaluée par le Centre canadien pour la cybersécurité selon le profil PBMM, avec une résidence des données documentée au Canada. Les organisations doivent exiger la documentation d’évaluation PBMM auprès des fournisseurs IA et cloud avant tout déploiement de workflow Protégé B — une autorisation FedRAMP Moderate ne remplace pas une évaluation PBMM du CCE.
2. Attribuer des identifiants uniques à chaque workflow agent IA
Chaque agent IA accédant à des informations Protégé B doit fonctionner avec un identifiant unique, provisionné au niveau du workflow et lié à l’humain ayant délégué la tâche. Les comptes de service partagés et les clés API mutualisées ne satisfont pas aux exigences de contrôle IA de l’ITSG-33. L’événement d’authentification et la chaîne de délégation doivent figurer dans chaque journal d’audit, assurant l’attribution individuelle exigée par le Programme de sécurité des contrats et les contrôles AU de l’ITSG-33.
3. Appliquer des contrôles d’accès opérationnels via l’ABAC
Mettez en place une ABAC qui évalue chaque demande d’accès IA aux données Protégé B selon le profil authentifié de l’agent, le niveau de classification des données demandées, le contexte du workflow et l’opération précise. L’application du moindre privilège au niveau de l’opération signifie qu’un agent autorisé à lire un document Protégé B ne peut pas automatiquement le télécharger, le transmettre à l’externe ou accéder à des enregistrements hors du périmètre de la tâche.
4. Déployer un audit inviolable pour chaque accès agent IA aux données Protégé B
Implémentez une journalisation opérationnelle pour chaque interaction agent IA/donnée Protégé B : identité authentifiée de l’agent, humain délégant, donnée accédée, opération réalisée, résultat de la politique, horodatage. Les journaux doivent être inviolables, conservés selon la politique de gestion documentaire du Conseil du Trésor, et intégrés au SIEM de l’organisation pour la détection d’anomalies en temps réel.
5. Actualiser les plans de réponse aux incidents pour couvrir les incidents IA sur données Protégé B
L’ITSG-33 exige des plans de réponse capables de traiter tous les types d’incidents de cybersécurité pertinents. Les déploiements IA introduisent de nouvelles catégories d’incidents Protégé B : accès agent non autorisé, exfiltration de données via injection de prompt, compromission de modèle, incidents côté fournisseur impactant la résidence canadienne des données. Chacune requiert des critères de détection, procédures de confinement et obligations de notification selon la LPRPDE et les exigences du Conseil du Trésor.
Comment Kiteworks contribue à la conformité ITSG-33 pour les déploiements d’agents IA
Gérer l’accès des agents IA aux données Protégé B selon l’ITSG-33 requiert une plateforme qui applique les contrôles de sécurité exigés — au niveau de la donnée, et non du modèle, et dans le respect de la résidence canadienne des données. Le Réseau de données privé Kiteworks fournit aux agences gouvernementales canadiennes et à leurs sous-traitants une architecture de gouvernance qui intercepte chaque interaction agent IA/information protégée avant l’accès, impose une identité authentifiée, une politique ABAC, un chiffrement validé FIPS 140-3 niveau 1 et une journalisation inviolable pour chaque opération.
Identité agent unique et chaîne de délégation pour les contrôles IA et AU de l’ITSG-33
Kiteworks authentifie chaque agent IA avant tout accès Protégé B, avec un identifiant unique par workflow lié à l’humain délégant la tâche. La chaîne de délégation complète — identité du délégant, identité de l’agent, donnée Protégé B accédée, opération réalisée — est conservée dans chaque entrée du journal d’audit. Cela répond aux exigences IA de l’ITSG-33 pour l’attribution individuelle et fournit le journal AU exigé par le Programme de sécurité des contrats : un log inviolable reliant chaque accès à une personne autorisée précise.
ABAC opérationnel pour les contrôles AC et le moindre privilège ITSG-33
Le moteur de politique de données Kiteworks évalue chaque demande d’accès agent/donnée Protégé B selon une politique multidimensionnelle : profil authentifié de l’agent, niveau de classification, contexte du workflow, opération précise. Un agent autorisé à lire un enregistrement Protégé B ne peut pas le télécharger, le transmettre à l’externe ou accéder à d’autres données Protégé B hors de son périmètre autorisé. Cette application opérationnelle répond aux contrôles AC du moindre privilège de l’ITSG-33 pour l’accès agent IA — remplaçant la gestion de session par compte de service, insuffisante dans la plupart des déploiements actuels.
Chiffrement FIPS 140-3 et journalisation SIEM intégrée
Toutes les données Protégé B accédées via Kiteworks sont protégées par un chiffrement validé FIPS 140-3 en transit et au repos, répondant aux exigences SC de l’ITSG-33 sur tout le parcours des données agent. Chaque interaction Protégé B est consignée dans un journal inviolable, opération par opération, alimentant directement le SIEM de l’organisation. Lorsqu’une évaluation de conformité ITSG-33 ou une notification de violation exige une preuve des contrôles d’accès pour les workflows IA Protégé B, le dossier de preuve est un rapport — et non une investigation sur de multiples logs d’infrastructure.
Déploiement flexible et résidence canadienne des données
Kiteworks propose des configurations sur site, cloud privé et hybride qui maintiennent les données Protégé B au Canada — répondant aux exigences de résidence ITSG-33 pour les workloads cloud Protégé B. Les organisations peuvent déployer Kiteworks sur une infrastructure approuvée par le gouvernement canadien, garantissant que l’accès agent IA aux données Protégé B reste dans le périmètre évalué CCE requis pour ce niveau de classification. Les options de déploiement sécurisé étendent la même architecture de gouvernance aux environnements hybrides où l’information protégée circule entre dépôts sur site et workflows IA hébergés dans le cloud.
Pour les agences gouvernementales canadiennes et leurs sous-traitants souhaitant déployer des agents IA sur des workflows Protégé B sans compromettre leur conformité ITSG-33, Kiteworks fournit l’infrastructure de gouvernance qui rend chaque interaction agent IA/information protégée défendable par conception. Découvrez comment Kiteworks accompagne le secteur public ou demandez une démo.
Foire aux questions
L’ITSG-33 s’applique aux agents IA accédant à des informations Protégé B. Les contrôles AC, AU, IA et SC du cadre régissent l’accès aux informations gouvernementales protégées, que l’utilisateur soit un employé humain ou un processus automatisé. Un agent IA qui lit, traite ou transmet des données Protégé B est soumis aux mêmes exigences de contrôle d’accès, d’audit, d’authentification et de chiffrement qu’un employé humain effectuant la même tâche. La conformité ITSG-33 impose aux organisations d’étendre la mise en œuvre de leurs contrôles de sécurité aux workflows agents IA traitant des données Protégé B.
Non. L’ITSG-33 exige que les services cloud traitant des données Protégé B soient évalués par le Centre canadien pour la cybersécurité selon le profil PBMM. Une certification SOC 2, ISO 27001 ou même une autorisation FedRAMP Moderate ne remplace pas une évaluation PBMM du CCE dans le contexte fédéral canadien. Les organisations doivent demander la documentation d’évaluation PBMM spécifique aux fournisseurs cloud et IA avant tout déploiement de workflow Protégé B sur leur infrastructure. La souveraineté des données Protégé B exige une résidence canadienne confirmée par le CCE, et non des attestations de conformité à d’autres cadres.
La famille de contrôles AU de l’ITSG-33 impose que les journaux d’audit pour les accès Protégé B consignent l’identité authentifiée de l’utilisateur (ou du processus), la donnée accédée, l’opération réalisée et un horodatage inviolable — au niveau de l’opération, et non simplement de la session ou de l’appel API. Pour les agents IA, cela signifie que chaque interaction Protégé B doit être journalisée avec l’identifiant unique de l’agent, l’humain ayant délégué le workflow, la ressource Protégé B accédée et le type d’opération. Les journaux d’infrastructure et d’inférence IA qui ne consignent que les appels API ou les sessions ne suffisent pas. La qualité de la traçabilité est la base de la preuve de conformité ITSG-33.
L’ITSG-33 exige que les services cloud traitant des données Protégé B soient évalués PBMM avec une résidence canadienne confirmée. Cela signifie que les plateformes IA ne doivent pas faire transiter les données Protégé B par une infrastructure hors du Canada ou par des régions cloud non spécifiquement évaluées PBMM. Lors de l’évaluation des plateformes IA, les sous-traitants doivent examiner chaque composant du pipeline d’inférence — hébergement du modèle, passerelle API, base vectorielle, restitution — au regard de l’exigence de résidence PBMM. Seules les architectures maintenant tout le traitement Protégé B dans une infrastructure évaluée canadienne répondent à cette exigence de conformité ITSG-33 Protégé B.
Le Programme de sécurité des contrats évalue les organisations et leur posture de sécurité avant d’autoriser l’accès aux données Protégé B dans le cadre de contrats gouvernementaux. Un déploiement IA incapable de démontrer des contrôles d’accès, une traçabilité et une résidence des données conformes à l’ITSG-33 pour les données Protégé B représente une faille de sécurité pouvant compromettre l’éligibilité aux marchés. Au-delà du risque d’attribution, une protection insuffisante des données Protégé B entraîne des obligations de notification en vertu de la LPRPDE et des sanctions potentielles selon la Loi 25 du Québec. Les organisations doivent réaliser une analyse de risques formelle de leurs déploiements IA au regard des exigences PBMM de l’ITSG-33 avant de soumissionner à des contrats fédéraux impliquant des données Protégé B.
Ressources complémentaires
- Article de blog
Stratégies Zero Trust pour une protection abordable de la confidentialité IA - Article de blog
77 % des organisations échouent à sécuriser les données IA - eBook
Écart de gouvernance IA : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025 - Article de blog
Il n’existe pas de « –dangerously-skip-permissions » pour vos données - Article de blog
Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent des preuves concrètes.