Un agent peut-il pousser en production ?

Non. Les agents ouvrent des pull requests en brouillon ; une personne relit et fusionne chaque changement.

Où sont conservés les identifiants ?

Dans votre propre coffre. Aucun dans le dépôt.

Realized.dev détient-il des certifications ?

Non. SOC 2, ISO 27001 et ISO 42001 inspirent nos pratiques. Cartographié, non certifié ni audité.

Y a-t-il un coupe-circuit ?

Non. Le contrôle vient des fusions approuvées par une personne et de l'annulation d'une fusion.

Nos données quittent-elles notre environnement ?

Le travail s'exécute dans vos dépôts et votre chaîne d'outils ; nous n'hébergeons ni runtime ni modèle.

Référence · Sécurité et déploiement

Référence sécurité et déploiement

Où se trouvent les contrôles, où le travail s'exécute, ce qu'est la piste d'audit, et les limites de ce que nous revendiquons.

Mis à jour le 12 octobre 2026

Modèle de menaces, en bref

Les principaux risques des agents de code : changements non relus, permissions excessives, fuites d'identifiants et objectifs détournés par des entrées non fiables. Notre réponse est structurelle : les agents travaillent dans votre chaîne d'outils, via des outils typés, et ne peuvent pas fusionner. La cartographie complète figure sur la page Sécurité.

Frontières de contrôle

Vérifications hors du modèle: Elles s'exécutent dans le harness, pas dans un prompt.
Appels d'outils typés: Les actions sur les systèmes de référence passent par des outils typés et autorisés, conçus pour éviter les écritures libres.
Aucun identifiant dans le dépôt: Les secrets restent dans votre propre coffre.
Les agents ne peuvent pas fusionner: Ils ouvrent des pull requests en brouillon ; une personne relit et fusionne chaque changement. Rien ne fusionne automatiquement.
Retour arrière: Annuler la fusion.

Déploiement

Le travail s'exécute dans vos propres dépôts et votre chaîne d'outils, avec Cursor et vos modèles. Realized.dev n'héberge ni runtime ni modèle : votre code et vos données restent où ils sont.

Piste d'audit

Votre historique Git et les revues de pull requests : qui a proposé chaque changement, quels tests ont tourné, qui a approuvé la fusion.

Cartographie des cadres

Cartographié, non certifié ni audité. Une cartographie des contrôles, pas une évaluation.

Cadre	Lien
OWASP Agentic Top 10 (2026)	Risques mis en correspondance avec les contrôles.
EU AI Act art. 12 + 14	Tenue des registres via l'historique Git ; supervision humaine via des fusions approuvées par une personne.
SOC 2, ISO 27001, ISO 42001	Inspirent nos pratiques.

Voir la cartographie de conformité

Ce que nous ne revendiquons pas

SOC 2, ISO 27001 et ISO 42001 : Cartographié, non certifié ni audité.
Il n'y a ni Stop Button, ni coupe-circuit, ni journal d'audit signé cryptographiquement.
Nous n'hébergeons ni votre runtime, ni vos modèles, ni vos données.
La cartographie n'est pas une évaluation juridique ou réglementaire.

Questions

Un agent peut-il pousser en production ?: Non. Les agents ouvrent des pull requests en brouillon ; une personne relit et fusionne chaque changement.
Où sont conservés les identifiants ?: Dans votre propre coffre. Aucun dans le dépôt.
Realized.dev détient-il des certifications ?: Non. SOC 2, ISO 27001 et ISO 42001 inspirent nos pratiques. Cartographié, non certifié ni audité.
Quelle est la piste d'audit ?: Votre historique Git et les revues de pull requests.
Y a-t-il un coupe-circuit ?: Non. Le contrôle vient des fusions approuvées par une personne et de l'annulation d'une fusion.
Nos données quittent-elles notre environnement ?: Le travail s'exécute dans vos dépôts et votre chaîne d'outils ; nous n'hébergeons ni runtime ni modèle.

Passer en revue les contrôles pour votre environnement ?

Réserver l'atelier de 90 minutes Guide d'architecture