Sécurité
La gouvernance comme architecture.
Pas des prompts garde-fous.
La surface d'attaque 2026 des agents autonomes n'est pas le désalignement — c'est l'injection de prompt, le vol d'identifiants et le rayon d'action non borné. Realized.dev est conçu pour réduire ces modes d'échec par la structure du travail, pas seulement par des règles.
Référence sécurité et déploiementPiliers du runtime
Quatre piliers, conçus pour rester hors du modèle.
Le LLM est traité comme un planificateur non fiable. Les actions sont conçues pour passer par des vérifications hors du modèle, et une personne approuve chaque fusion.
Vérifications de politique hors du modèle
Les règles vivent hors du LLM, dans votre dépôt, et sont conçues pour que le contenu des prompts ne les modifie pas ; tout changement passe par une pull request en brouillon qu'une personne approuve.
- Compilé depuis votre OWASP ASI 2026 + catalogue de contrôles interne
- Autorisation par action avant tout appel d'outil
- Refus renvoyés au modèle en retour structuré, pas en échec silencieux
Approbation humaine ; retour arrière par revert de la fusion
Les agents ouvrent des pull requests en brouillon. Une personne approuve chaque fusion.
- Chaque fusion est une décision humaine
- Les agents ouvrent des pull requests en brouillon. Une personne approuve chaque fusion.
- Retour arrière : un revert de la fusion rétablit l'état précédent
Porte HITL
Les classes d'actions à haut risque se mettent en pause pour une approbation humaine en un clic. La télémétrie d'incertitude remonte à l'UI pour contrer le biais d'automatisation.
- Configurable par classe d'action, par environnement, par rôle
- Scores d'incertitude et de provenance affichés inline
- Chaque approbation est une fusion enregistrée dans l'historique Git
Piste d'audit dans Git
Chaque changement arrive sur votre branche principale sous forme de pull request relue : votre historique Git montre ce qui a changé, quand, et qui l'a fusionné.
- Une pull request par changement, avec son diff et sa relecture
- Chaque fusion indique qui a approuvé le changement
- Specs, éléments de travail et constats versionnés dans docs/
Modèle de menaces
La surface d'attaque agentique 2026, mappée aux contrôles.
Chaque classe de menace du paysage OWASP Agentic Security Initiative 2026 est mappée à un contrôle runtime — avec preuves exportées vers la matrice de conformité.
Clés, identité et emplacement du code
Vos dépôts. Vos comptes. Vos fusions.
Nous n'hébergeons aucun runtime. Le travail s'exécute dans vos propres dépôts et outils, avec Cursor, et une personne de votre équipe approuve chaque fusion.
Vos comptes, votre identité
L'accès passe par vos propres comptes de dépôt et Cursor. Le harness ne conserve aucun identifiant dans le dépôt.
Où vit votre code
Dans vos propres dépôts. Le harness ne fournit ni runtime hébergé ni modèle : votre code ne va que là où votre propre configuration Cursor et Git l'envoie.
Gestion du changement
Chaque changement, y compris de politique ou de configuration, arrive sur votre branche principale sous forme de pull request relue, qu'une personne approuve.
Étape suivante
Parcourez l'architecture sécurité avec notre équipe.
90 minutes avec vos parties prenantes sécurité et conformité. Vous repartez avec une cartographie de contrôles scopée sur OWASP ASI 2026, le Règlement IA UE et votre catalogue interne.