Aller au contenu principal
REALIZED.DEV
Réserver un atelier

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éploiement

Piliers 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é.

Classe de menace
Atténuation runtime
Injection de prompt / détournement d'instructions
Les vérifications de politique sont hors du LLM. Le contenu non fiable est étiqueté en entrée, et le workflow est conçu pour qu'il n'élargisse pas son propre périmètre d'outils.
Vol d'identifiants via mésusage d'outils
L'accès passe par vos propres comptes de dépôt et Cursor, avec des identifiants conçus pour rester hors des prompts et du dépôt.
Rayon d'action non borné
Les chemins d'écriture sont conçus pour rester dans une borne de capacité. Les portes HITL mettent en pause les classes à haut risque ; une exécution est conçue pour s'arrêter sur un signal d'anomalie.
Hallucination en cascade sur plans longs
Chaque étape Observer → Décider → Exécuter se clôt par une vérification ancrée. La télémétrie d'incertitude alimente le routage HITL.
Compromission de la chaîne modèle / prompt
Nous ne fournissons aucun modèle. Les règles et prompts du harness vivent dans votre dépôt, et chaque changement est une pull request relue, qu'une personne approuve.
Preuves manquantes pour le régulateur
Les preuves sont votre historique Git de pull requests relues. Nous pouvons montrer comment il se rattache au Règlement IA de l'UE et à l'OWASP Agentic Top 10 (2026). Cartographié, non certifié ni audité.

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.