Le contrôle de sécurité entre l'utilisateur et le modèle : Model Armor pour les déploiements d'IA

Tout ce qui se passe autour d'un modèle d'IA a deux mains : le prompt qui entre et la réponse qui sort. « Model Armor: Securing AI Deployments », de Google Skills, propose de traiter les deux comme une charge qui passe par un contrôle de sécurité, de la même manière qu'un bagage à l'aéroport. Model Armor est le service Google Cloud qui tamise les prompts entrants vers le modèle et les réponses sortantes du modèle, et marque avec MATCH_FOUND tout ce qui contrevient à la configuration : URLs malveillantes, tentatives de jailbreak, données sensibles et contenu offensant.

Le cadre de fond est SAIF (Secure AI Framework), et le catalogue de menaces est l'OWASP Top 10 des vulnérabilités LLM, dont Model Armor couvre quatre : fichiers malveillants et URLs non sécurisées (avec détection d'URLs malveillantes et tamisage de PDF), prompt injection et jailbreak, données sensibles (Sensitive Data Protection) et matériel offensant (filtres Responsible AI).

flowchart LR
    U[Utilisateur] --> P[Prompt]
    P --> MA[Dataplane de Model Armor]
    MA -->|sans match| M[Modèle]
    MA -->|MATCH_FOUND| B[Blocage ou rédaction]
    M --> MA2[Model Armor sur la réponse]
    MA2 --> U2[Utilisateur]

Ce que ça attrape en pratique

Les détections du parcours servent de catalogue du réel : un prompt nuisible, la phrase « ignore all previous instructions », un payload d'injection caché dans une variable de code, une URL de malware consultée contre des bases de données de menaces, la révélation d'un SSN et une sortie qui demande 100 cartes de crédit valides. Il tamise aussi le contenu d'un PDF joint. La liste n'est pas théorique : ce sont les formes qu'un agent exposé finit par répondre — des choses que personne n'a autorisées.

Floor settings et templates : l'architecture de la personnalisation

La personnalisation a deux niveaux, et l'ordre entre eux n'est pas négociable. Les floor settings sont des exigences minimales centralisées, qui peuvent vivre au niveau organisation (seulement via API), dossier ou projet (depuis la console). Ils se créent toujours avant les templates. Si un template essaie d'être moins strict, avec une confiance plus basse ou une détection désactivée, Model Armor renvoie une erreur et rejette sa création ou sa modification ; la tentative reste consignée dans Logs Explorer. Et si un floor setting change, les templates existants doivent être revalidés avant de pouvoir être modifiés.

Les templates sont la configuration par application, créés par l'API Model Armor ou depuis la page de Security Command Center, et ils ont trois parties. General info : ID, région et étiquettes. Détections : malicious URL ; prompt injection et jailbreak avec leur niveau de confiance ; et Sensitive Data Protection, où il faut choisir basique ou avancé, jamais les deux dans le même template. Responsible AI : filtres de hate speech, harcèlement et autres, chacun avec son niveau de confiance.

La règle qui gouverne tout : la confiance du template peut être plus stricte que le floor setting, jamais plus lâche. Et les templates admettent une configuration par requête (model_armor_config), pour appliquer des templates différents d'appel en appel selon le rôle ou la sensibilité de la transaction.

Il y a trois niveaux de confiance. Low and above détecte la moindre correspondance avec les critères, le plus sensible. Medium and above détecte les correspondances modérées et est le point de départ recommandé. High and above ne marque que quand il y a haute certitude. Les trois équilibrent capturer les vrais positifs contre éviter les faux positifs, et le floor setting fixe le minimum exigible au-delà duquel le template peut aller plus loin.

Sensitive Data Protection : marquer ou transformer

Sensitive Data Protection (SDP) a deux modes. Le basique utilise des infoTypes prédéfinis sans configuration : cartes de crédit, comptes financiers, identifiants de compte de service Google Cloud, clés API, mots de passe en clair et, dans les régions des États-Unis, SSN et TIN. Il marque et rapporte.

L'avancé travaille avec deux templates enchaînés. Inspect définit quoi chercher : des infoTypes intégrés comme CREDIT_CARD_NUMBER ou personnalisés avec RegEx ou listes de mots. De-identify définit quoi faire en trouvant : masquer avec X, rédacturer ou tokeniser. La combinaison transforme les données au lieu de bloquer l'interaction : le flux continue et renvoie le texte assaini dans l'objet deidentifyResult.

Le cas de support IT illustre le motif complet. Un employé bloqué doit vérifier son identité dans le chat de support avec son employee ID ; le double défi est de confirmer que l'ID est authentique sans qu'il reste en clair dans l'historique du chat ni ne soit envoyé à des LLM tiers. La solution : un template inspect avec un détecteur RegEx personnalisé de l'ID, un template de-identify qui le transforme (dans la même région), les rôles DLP user et DLP reader pour le compte de service de Model Armor, et les deux templates liés dans un template Model Armor en mode avancé. Résultat : Model Armor intercepte l'ID, exécute le pipeline et, comme il y a inspect et de-identify, il ne bloque pas : il renvoie le texte assaini et l'employé suit son flux.

Il y a un cas où l'avance se coupe. Avec SDP avancé en INSPECT_AND_BLOCK et le mode actif, l'appel entier est bloqué : Model Armor ne renvoie pas de texte rédacté car cela fuiterait des données. C'est une limite architecturale, pas une erreur de configuration.

Inline enforcement sur Agent Platform

La nouveauté que le matériel souligne est que les floor settings au niveau projet ne valident plus seulement les configurations : ils interceptent en temps réel le trafic de Gemini sur Agent Platform, sans changement de code. Les prompts sont interceptés avant les agents et les réponses avant l'utilisateur.

La hiérarchie de précédence est template indiqué dans la requête > floor setting > filtres natifs d'Agent Platform. Prérequis : l'API Model Armor activée (et Sensitive Data Protection s'il y a masquage avancé) et le rôle Model Armor User pour le compte de service d'Agent Platform.

flowchart TD
    F[Floor setting : minimum non négociable] --> T[Template : plus strict ou égal]
    T --> G[Filtres natifs d'Agent Platform]
    F -.->|si Model Armor tombe| FA[Agent Platform fait bypass : alerter dans Cloud Logging]

Apparaît ici une décision de résilience qu'il vaut mieux prendre se regardant dans les yeux. Si Model Armor est temporairement indisponible, Agent Platform fait bypass pour éviter les coupures : fail open. Le matériel recommande d'alerter ces événements dans Cloud Logging, car un trafic qui passe sans tamisage pendant une fenêtre d'indisponibilité est un trou silencieux.

De plus, les méthodes de streaming (streamGenerateContent) et les apps Gemini Enterprise indépendantes requièrent une configuration manuelle de sécurité, puisque le floor setting global n'injecte pas de protection inline sur ces voies.

Sans code, pour les équipes métier

Gemini Enterprise peut lier les templates déjà créés pour sécuriser des assistants internes sans écrire de code, et quatre décisions apparaissent là.

Le mode d'application : INSPECT_AND_BLOCK, où la transaction échoue avec un message de politique, ou INSPECT_ONLY, qui ne fait que consigner les violations. La stratégie de panne : fail-closed, le comportement par défaut, qui bloque tout si Model Armor est inaccessible, ou fail-open, qui priorise la disponibilité. L'alignement régional, obligatoire entre le template et l'instance Gemini (multi-région US ou EU comprise) : croiser les régions produit une erreur fatale « Template not found » au runtime. Et le tamisage des pièces jointes (PDF, CSV, Word), qui extrait le texte jusqu'à 4 Mo et bloque tout le document s'il viole en INSPECT_AND_BLOCK.

L'avertissement de logging dans cette intégration est ferme : il vaut désactiver le Cloud Logging basique du template (log_sanitize_operations=false) ou exporter avec des sinks vers des destinations d'accès restreint comme BigQuery. Les logs de payload gardent les prompts en clair, et le rôle roles/logging.privateLogViewer pourrait lire des conversations sensibles.

Versions des filtres et cycle de vie

Chaque template admet une version de filtres. Latest apporte les modèles de détection les plus récents avec mises à jour fréquentes, pour les tests et le staging. Stable apporte la logique éprouvée, pour la production. L'ancien Stable après promotion, avec 90 jours de grâce. Retired l'éteint, et le template revient au Stable actif.

La sélection peut être dynamique, par alias (Stable ou Latest, et le template avance tout seul), ou statique, fixée sur v1 ou v2. Les métadonnées de chaque réponse Sanitize préviennent 30 jours à l'avance du retrait d'une version Legacy. Et un détail qui évite les frayeurs : le réglage n'affecte ni le SDP ni la détection d'URLs malveillantes.

Trouver les violations dans les logs

Trois familles de logs. Cloud Audit Logs : admin activity (le CRUD des templates et floor settings, toujours actif) et data access (métadonnées de tamisage : qui, quand, autorisation, via IAM). Platform logs, facultatifs, qui capturent la conversation complète, le match et le verdict ; ils sont volumineux à cause du coût de Cloud Logging et contiennent des données sensibles visibles pour qui a la permission de log.

Dans Logs Explorer, les violations se localisent avec des filtres comme protoPayload.serviceName=\"modelarmor.googleapis.com\", le methodName de SanitizeUserPrompt et le @type de SanitizeOperationLogEntry ; la violation apparaît comme matchState avec MATCH_FOUND.

L'application décide du verdict

Model Armor livre le constat ; la décision d'affaires appartient à l'application. Avec l'API REST, l'application appelle Model Armor pour tamiser prompt et réponse, parse la réponse et choisit parmi quatre issues : bloquer la requête de l'utilisateur, bloquer la réponse du modèle, avertir l'utilisateur, ou continuer le flux avec le texte rédacté.

Le hotfix qui a oublié le template

Le cas de clôture est le meilleur argument en faveur des floor settings. Chez Cymbal Bank, une équipe Wealth Advisor déploie un hotfix en oubliant le bloc model_armor_config dans la requête, laissant l'agent exposé au niveau application. Un utilisateur saisit une URL de phishing. Avec les floor settings de projet intégrés à Agent Platform, le prompt est acheminé vers le dataplane de Model Armor, qui émet MATCH_FOUND sur le détecteur d'URLs malveillantes et bloque la transaction en renvoyant un motif MODEL_ARMOR.

La piste forense est élégante : dans Logs Explorer, le principalEmail appartient au service agent d'Agent Platform, ce qui dit à l'équipe SecOps que l'appel a contourné le code du développeur et que c'est le floor setting qui l'a attrapé. La réparation : demander à l'équipe de restaurer les paramètres du template au prochain commit. La couche des minimums a fait exactement ce pour quoi elle était conçue : tenir le plancher quand quelqu'un a baissé la garde un après-midi.

Ce que le motif laisse et ce qui est resté non exécuté

Ce qui survit à tout changement d'interface, c'est la structure : des minimums centraux que personne ne peut abaisser par projet, des templates par application qui peuvent être plus stricts, une décision explicite de quoi faire de chaque verdict, et des alertes sur les laps où le service est indisponible.

Ce qui est resté non exécuté dans cette documentation : le lab self-paced « Sanitize Prompts and Responses with Model Armor » et la validation de l'intégration avec Agent Platform, car ils requièrent un projet Google Cloud avec l'API activée ; le guide de lecture renvoie à la documentation du Help Center et à trois vidéos externes qui n'ont pas été téléchargées ; et le comportement de streaming est resté consigné comme limite de la protection inline sans l'avoir testé. Il y a aussi un détail de support à garder en tête : les filtres Responsible AI et prompt injection/jailbreak sont testés sur un ensemble précis de langues, et dans d'autres leurs résultats peuvent varier, il existe donc une détection multi-langues par appel ou par template via l'API REST.

---

*Source : « Model Armor: Securing AI Deployments », de Google Skills (cours google.model-armor).*