⏱️
Temps de lecture estimé
~11 minutes
Microsoft a publié le 20 mai 2026 deux outils open-source, RAMPART et Clarity, pour « intégrer la safety dans le workflow de développement d’agents ». La question que je me pose immédiatement, en tant que praticien du threat modeling : qu’est-ce que ça change pour quelqu’un qui fait déjà du MAESTRO, du STRIDE ou du PASTA ? En plus, en moins, complémentaire ou concurrent ?
La promesse, et le malentendu à éviter
Je vais être direct dès le départ, parce que c’est là que beaucoup vont se tromper : ni RAMPART ni Clarity ne sont des méthodologies de threat modeling. Ils ne remplacent ni STRIDE, ni PASTA, ni MAESTRO. Ce sont précisément les deux maillons que ces méthodes laissent de côté.
- STRIDE, PASTA et MAESTRO disent quoi tester.
- RAMPART exécute le test.
- Clarity garde la question pertinente dans le temps.
Note du PandaRedacteur : Un threat model, c’est un document. Il dit ce qui pourrait mal tourner. Mais il ne vérifie pas que vos mitigations tiennent, et il se périme dès le sprint suivant. C’est exactement ce trou que les deux outils viennent combler ; l’un en amont du design, l’autre en aval de la vérification.
Je distingue ici nettement leurs rôles, parce qu’on pourrait les confondre facilement sous l’étiquette « safety agentique ».
- RAMPART : Risk Assessment & Measurement Platform for Agentic Red Teaming. Un framework de test pytest-native, bâti sur PyRIT, qui transforme un scénario de menace en test rejouable avec un verdict binaire pass/fail. Couverture la plus mature aujourd’hui : la cross-prompt injection.
- Clarity : « An AI thinking partner that pushes back ». Un assistant qui challenge vos hypothèses de conception avant que vous n’écriviez la première ligne, et produit des fichiers markdown versionnés (
.clarity-protocol/) relus en PR comme du code.
Le vrai sujet : où se placent-ils dans le cycle de vie ?
C’est tout l’intérêt de ces outils, et c’est ce que je veux vous faire comprendre. STRIDE, PASTA et MAESTRO sont des activités analytiques, à l’instant T. RAMPART et Clarity sont, eux, des activités continues.
flowchart LR
A["Clarity<br/>(amont / design)<br/>challenge les hypothèses<br/>garde le design vivant"] --> B["STRIDE · PASTA · MAESTRO<br/>(analyse)<br/>identifie & priorise<br/>DFD · couches · scoring"]
B --> C["RAMPART<br/>(aval / CI)<br/>encode chaque menace en test<br/>gate le pipeline · non-régression"]
C -. "régression détectée" .-> B
- Clarity recouvre partiellement la phase d’élicitation de STRIDE/PASTA : faire émerger hypothèses, acteurs, modes de défaillance. Il n’a ni la rigueur ni la complétude d’une méthode (pas de DFD, pas de matrice par élément ou par couche), mais il maintient le raisonnement dans le repo et à jour.
- RAMPART est le chaînon manquant : il fait passer le threat model de l’état « PDF mort » à celui de « contrôle exécuté en continu ». Une menace MAESTRO jugée critique devient un test qui casse le build si la mitigation régresse.
Note du PandaRedacteur: Pour rappel c’est quand meme Micro$oft qui a créé la méthode STRIDE….On peut dire du mal d’eux, la c’est bien….
Articulation fine avec STRIDE / PASTA / MAESTRO
Je résume ici le positionnement de chacun dans un tableau, parce que c’est la photo que je voulais avoir pour décider quoi adopter .
Note du PandaRedacteur: il faut encore tester tout cela, mais j’ai préféré vous partager mes investigations. Je publierai un REX (pas le chien…un Retour d’EXperience)
| Dimension |
STRIDE |
PASTA |
MAESTRO |
Clarity |
RAMPART |
| Nature |
Méthode (taxonomie) |
Méthode (process risque) |
Méthode 7 couches agentique |
Outil / assistant design |
Framework de test |
| Phase |
Design |
Design → risque métier |
Design (couches IA) |
Amont design |
Build / CI / nightly |
| Sortie |
Menaces par élément du DFD |
Risques priorisés métier |
Menaces par couche (1→7) |
Markdown versionné |
Verdict pass/fail |
| Couvre l'agentique ? |
Pas directement</td>
| Pas directement</td>
| Oui |
Partiel |
Oui |
</tr>
| Exécutable ? |
Non |
Non |
Non |
Non |
Oui |
| Vivant / non-régression ? |
Non |
Non |
Non |
Oui (staleness) |
Oui (CI gate) |
</tbody>
</table>
</div>
Le mapping avec les **7 couches de MAESTRO** (Foundation Models, Data Operations, Agent Frameworks, Deployment/Infra, Evaluation & Observability, Security & Compliance, Agent Ecosystem) est presque évident une fois qu'on l'a vu :
- RAMPART alimente directement la **couche 5 : Evaluation & Observability**. C'est sa vocation : mesurer le comportement de l'agent face à des entrées adverses.
- Les menaces des couches **Data Operations** (empoisonnement RAG) et **Agent Ecosystem** (A2A, outils/MCP) se traduisent très bien en tests RAMPART de cross-prompt injection et de franchissement de limites d'outils.
- Clarity sert d'**outil d'animation** pour dérouler MAESTRO couche par couche, et garde la trace des décisions et des alternatives écartées, ce que MAESTRO seul ne formalise pas.
Si vous voulez le contexte agentique en arrière-plan, je vous renvoie à ma série sur les [guardrails Agentic AI](/2025/08/03/agentic-AI/), à mon guide de [réponse à incident à l'ère de l'Agentic AI](/fr/incident-response-agentic-ia/), et au [Top 10 MCP](/fr/Top10-MCP/MCP01/).
## Ce que ça apporte EN PLUS
Je constate cinq apports concrets qu'aucune méthodologie ne me donnait seule.
- **Un threat model exécutable.** On sort du PDF mort ou du Confluence jamais mis a jour. Une menace = un test versionné, rejouable, opposable en revue de code.
- **La non-régression de sécurité.** C'est la valeur n°1 à mes yeux : un correctif d'injection ne « repart » pas silencieusement au refactor d'après.
> **Note du PandaRedacteur** : c'est clairement un gros apport que de nombreux devraient adopter meme au dela de l'agentique
- **Des assertions probabilistes.** Spécifique et pertinent pour le LLM : pouvoir dire, voir affirmer « sûr dans 80 % des runs » est impossible avec un test d'intégration classique.
> **Note du PandaRedacteur** : cela ne remplacera par vos autres elements de tests !!!
- **Des payloads adversariaux prêts à l'emploi** via PyRIT ; on ne réinvente pas les corpus d'attaque.
> **Note du PandaRedacteur** : je sius un gros feignant comment toute personne intelligente....
- **Un design vivant et auditable** (Clarity) : le raisonnement de conception ne pourrit plus dans un wiki ; il vit dans le repo, est git + diffé en PR, et signale lui-même sa péremption via le *staleness tracking*.
## Ce que ça N'APPORTE PAS
J'ai noté ces limites :
- **Ce ne sont pas des méthodologies.(déja dit mais ca fait pas de mal)** Aucune garantie de *complétude*. RAMPART ne vous dit pas *quoi* tester : sa couverture vaut exactement celle des tests que **vous** écrivez à partir de **votre** threat model. Sans [MAESTRO](/fr/threat-modeling/maestro-introduction/)/[STRIDE](/2025/04/26/STRIDE/) en amont, vous testez au doigt mouillé.
- **Pas de scoring de risque.** Ni OWASP Risk Rating, ni DREAD, ni priorisation métier façon [PASTA](/2025/05/24/secu-ia-pasta/). Pas de DFD, pas de matrice par couche.
- **Couverture encore étroite.** RAMPART est mature surtout sur la cross-prompt injection. Les autres familles (*excessive agency*, fuite mémoire, collusion d'agents) il semble qu'il faille s'outiller soi-même.
- **Non-déterminisme et coût.** Les tests appellent de vrais LLM : flakiness possible, **coût d'API en CI**, latence. À piloter (seuils, runs nocturnes, budgets).
> **Note du PandaRedacteur** : c'est ce qui me freine un peu tout de suite pour les tester....
- **Périmètre technique.** RAMPART, c'est **Python/pytest** uniquement, avec un agent à *wrapper* via un adapter. Clarity dépend de la qualité d'un **modèle frontier** et reste conversationnel, donc non reproductible à l'identique.
- **Ne couvre pas le runtime de prod.** Ni monitoring en production, ni mapping de conformité : la couche observabilité runtime de MAESTRO reste nécessaire.
## Verdict : complémentaire, sans ambiguïté
Le piège serait de croire que RAMPART « remplace » le threat model. C'est l'inverse ; il n'a de valeur que **branché sur un threat model existant**.
La boucle complète se lit ainsi :
1. **Clarity** (amont) fait émerger et entretient les hypothèses et modes de défaillance.
2. **[STRIDE](/2025/04/26/STRIDE/) / [PASTA](/2025/05/24/secu-ia-pasta/) / [MAESTRO](/fr/threat-modeling/maestro-introduction/)** (analyse) structurent, priorisent, donnent la couverture et le scoring.
3. **RAMPART** (aval) vérifie en continu que les mitigations tiennent, et *gate* la CI.
## Intégration dans une CI/CD Jenkins
RAMPART s'intègre comme n'importe quelle suite pytest. Deux précautions propres à l'agentique : les secrets LLM via `withCredentials`, et la **séparation entre un gate PR rapide et une suite adversariale nocturne**, pour maîtriser coût et flakiness.
Quelques points de calage :
- **Assertions probabilistes** → fixez un seuil acceptable, prévoyez éventuellement des *retries*, et isolez les tests flaky dans un stage non bloquant pour ne pas saboter la PR.
- **Coût** → la suite adversariale complète tourne en cron nocturne, pas à chaque commit.
- **Découpage** → utilisez les *markers* pytest (`-m smoke` / `-m adversarial`) pour séparer gate-PR et nightly.
Clarity, lui, n'est pas un *gate* ; c'est interactif. Mais ses artefacts `.clarity-protocol/*.md` sont versionnés, donc on peut ajouter un **lint de fraîcheur de design** a traitercomme un avertissement de revue, pas comme un blocage dur(quoi que....) :
## Ma vision de ces outils
>**Note du PandaRedacteur** : encore une fois, cela ne remplace pas les méthodologie !!!!! Ce ne sont que des outils en plus dans votre chaine DevSecOPS !!!
- **Adopter RAMPART** dès qu'un agent est en prod ou en passe de l'être : c'est le moyen le plus simple de rendre nos threat models MAESTRO **opposables** et non-régressifs.
- **Tester Clarity** sur une feature agentique en conception, en complément, jamais en remplacement, d'une session MAESTRO formelle.
- **Garder MAESTRO comme colonne vertébrale** : il fournit la couverture et le scoring que les deux outils Microsoft, par construction, ne donnent pas.
> **Note du PandaRedacteur : Au fond, ces deux outils ne sont pas une révolution méthodologique. Ce sont les deux extrémités du fil qu'on n'arrivait pas à nouer : faire vivre le threat model avant le code, et le faire respecter après. C'est précisément ce qui manquait pour que le threat modeling agentique sorte du document PDF/Word.**
---
À retenir 📌
- ✓ RAMPART et Clarity ne sont pas des méthodologies : ils n'ont de valeur que branchés sur un threat model existant (STRIDE, PASTA, MAESTRO).
- ✓ Clarity ferme la boucle en amont : il garde le design vivant et versionné dans le repo, là où MAESTRO seul produit un document qui se périme.
- ✓ RAMPART ferme la boucle en aval : il transforme chaque menace en test rejouable et bloque le pipeline si une mitigation régresse.
- ✓ Les deux outils ont des limites concrètes : couverture étroite (cross-prompt injection surtout), coût LLM en CI, Python/pytest uniquement, pas de scoring de risque.
- ✓ La séquence gagnante : Clarity → MAESTRO/STRIDE/PASTA → RAMPART. Chacun à sa place, aucun en remplacement des autres.