Comment construire un Security Engine IA lifecycle-aware

Le mauvais modele mental : un enorme AI firewall

Le design de securite IA le plus simple est aussi le moins realiste. Les equipes placent un classifieur ou un jeu de regles devant le model et attendent qu'il reponde a toutes les questions : la requete doit-elle etre autorisee, le prompt est-il malveillant, l'utilisateur est-il autorise, la sortie est-elle sure, la requete va-t-elle casser le budget, et le model peut-il appeler des outils ?

Cela ne fonctionne pas parce que ces questions apparaissent a des moments differents.

• Une regle reseau peut s'executer avant l'auth.
• Une decision d'access grant a besoin de l'identite appelante et de la ressource selectionnee.
• Un gate de tokens ou de cout a besoin du contexte model et de l'enveloppe token.
• Un controle de securite de prompt a besoin du texte decode du prompt.
• Un controle de fuite cote reponse a besoin de la sortie provider.
• Une reconciliation finale de cout a besoin que la requete soit terminee.

Des qu'on accepte cette realite de timing, l'architecture change. On cesse de chercher un AI firewall magique et on commence a construire un enforcement par etapes.

Ce qu'impliquent les recommandations recentes pour le design de l'engine

Le meilleur signal public ici n'est pas un cadre unique. C'est le recouvrement entre plusieurs sources.

En janvier 2024, le NIST a publie Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations. Ce rapport compte parce qu'il structure la securite IA autour des etapes du cycle de vie, des objectifs de l'attaquant, de ses capacites, du poisoning, des attaques vie privee, de l'extraction de model et des variantes de prompt injection en GenAI. C'est deja un raisonnement par etapes.

Le 12 mars 2025, le Top 10 OWASP mis a jour pour les applications LLM et GenAI a renforce le meme point du cote applicatif. Prompt injection, divulgation d'informations sensibles, improper output handling, excessive agency et consommation non bornee sont des classes d'echec differentes. Aucun gate unique ne peut toutes les voir avec le bon contexte.

Le 25 mai 2026, le crosswalk AIUC-1 d'OWASP pour les applications agentiques a encore pousse l'architecture en appelant explicitement des manques autour de l'identite des agents, du runtime containment, de l'architectural monitoring, de l'attestation de supply chain et des schema controls. C'est en pratique un avertissement contre une securite trop mince et mono-etape.

Pris ensemble, ces documents disent qu'un vrai Security Engine IA a besoin :

• de controles par etapes
• de frontieres d'acces sensibles aux capacites
• de gestion cote reponse, pas seulement d'un filtrage cote entree
• de controles de cout et d'abus dans le chemin runtime
• de preuves et de monitoring apres la decision

Les etapes dont un vrai Security Engine IA a besoin

Voici la forme pratique d'un engine pret pour la production.

1. Controles d'admission request-aware. Ils gerent IP policy, taille du payload, debit de requetes, concurrence et autres protections peu couteuses avant le travail cher.

2. Controles d'identite et d'acces. Ils repondent a qui appelle, quelle virtual key ou quel tenant porte la requete, et si cette identite peut atteindre le model ou le serveur MCP choisi.

3. Controles resource-aware et token-aware. Ils raisonnent sur le model selectionne, l'enveloppe token, les budgets, les quotas et autres frontieres d'usage qui dependent du contexte de requete decodee.

4. Controles de contenu cote requete. Ils inspectent le texte du prompt, redigent les donnees sensibles en entree, detectent la prompt injection ou les jailbreak patterns et decident si l'execution upstream doit continuer.

5. Controles d'outils et de plugins. Ils appliquent des regles de capacites explicites aux outils MCP ou a d'autres points d'extension afin qu'un prompt faible ne se transforme pas en chemin d'action fort.

6. Controles cote reponse et preuves. Ils inspectent la sortie du model pour y chercher des fuites ou du contenu dangereux, redigent si approprie, bloquent si necessaire et enregistrent suffisamment de preuves pour que les operateurs comprennent ce qui s'est passe.

Cette sequence n'est pas de la sur-ingenierie. C'est la structure minimale pour repondre a des questions de securite differentes avec les bonnes donnees.

Comment Odock se compare

Chez Odock, notre runtime suit presque exactement ce schema par etapes. Notre cycle de vie passe par des request-aware gates, des identity and access gates, des resource-aware gates, des token and cost gates, la securite cote requete, des plugin gates, l'execution upstream, la securite cote reponse, les plugin gates post-upstream, l'ecriture de la reponse puis les preuves finales d'usage.

SafetySec traite ensuite les parties sensibles au contenu de ce flux. Dans SafetySec, nous gerons :

• la detection de prompt injection
• la detection de jailbreak patterns
• la sensitive redaction
• la detection de data leakage
• la repeated-risk awareness
• les safety evidence

C'est un choix de design important. SafetySec ne remplace pas le controle d'acces, les budgets, les quotas ou la policy de capacites MCP. Il gere la securite des prompts et des reponses pendant que d'autres guardrails gerent la forme du trafic, l'acces et les frontieres de ressources.

Le mapping est simple :

• Controles de requete amont :

Nous arretons l'abus avant le travail couteux avec des request-aware gates sur l'origine, le payload, les rate limits et la concurrence.

• Permissions liees a l'identite :

Nous gardons l'acces aux models et aux outils attache aux principals avec des access grants explicites pour les models et les serveurs MCP.

• Enforcement tokens et cout :

Nous evitons le denial of wallet et l'usage hors de controle avec les token gates, les budgets, les quotas et la reconciliation lifecycle-aware.

• Defense de prompt cote requete :

Nous stoppons les entrees dangereuses avant l'execution upstream avec les controles SafetySec de prompt risk cote requete et l'input redaction.

• Gouvernance des capacites d'outils :

Nous limitons ce que les agents peuvent reellement faire avec les allowed tools, blocked tools, scopes et semantic filters MCP.

• Defense cote reponse :

Nous attrapons les fuites ou sorties dangereuses avant le client avec les controles SafetySec de data leakage cote reponse et l'output redaction.

• Preuves et audit :

Nous rendons les decisions explicables et observables avec les safety evidence ainsi que l'enregistrement de l'usage, du statut, du cout et de la latency.

Pourquoi c'est plus solide que des filtres applicatifs

Les filtres applicatifs ne sont pas inutiles. Ils sont simplement insuffisants comme surface de controle principale.

Dans des systemes IA distribues, la securite au niveau applicatif derive vite :

• des services differents implementent des regles differentes
• les equipes ne release pas a la meme vitesse
• l'acces aux outils est ajoute avant revue plateforme
• la forme des logs diverge
• les limites de cout deviennent best-effort au lieu d'etre enforcees

Une approche lifecycle-aware au niveau gateway corrige le point de controle. Les equipes produit continuent de livrer des fonctionnalites, mais l'enforcement le plus risque reste dans une infrastructure partagee.

C'est particulierement important pour les systemes agentiques. A partir du moment ou un model peut appeler un outil repository, navigateur, ticketing ou une action interne, le rayon d'impact n'est plus seulement "du mauvais texte" mais "de vrais effets de bord". C'est la que l'enforcement par etapes compte.

La frontiere realiste de l'engine

Meme un bon Security Engine n'est pas tout le programme. Chez Odock, nous ne survendons pas ce point.

Il faut encore du travail adjacent pour :

• le developpement securise et le patching des serveurs MCP et des plugins
• les controles de supply chain pour les models, datasets et dependances
• les revues d'architecture sur les workflows a haut risque
• la validation de schema et de regles metier dans les handlers d'outils
• la gouvernance de release, l'evaluation et le red teaming hors du chemin de requete live

Mais si la couche runtime est faible, tous les autres controles compensent le mauvais probleme. Le chemin runtime est l'endroit ou les requetes deviennent des actions, des couts et des sorties. C'est pour cela que le design de l'engine compte autant.

Sources

• NIST AI 100-2e2023: Adversarial Machine Learning, janvier 2024
• OWASP Top 10 Risk & Mitigations for LLMs and Gen AI Apps, 2025
• OWASP AIUC-1 Crosswalks for Agentic Applications, 25 mai 2026
• OWASP State of Agentic AI Security and Governance 2.01, 1 juin 2026
• Odock Runtime Enforcement
• Odock Security Engine
• Odock Guardrail Modules