01 · Identité
- L'agent agit sous sa propre identité, et non sous une clé partagée
- Agents expirés ou révoqués → 403
- Propriétaire, niveau de risque et périmètre à chaque exécution
Architecture
Comment Cortex gouverne chaque exécution.
Chaque action d'agent suit le même cycle de vie — de l'humain au résultat — et les mêmes huit points de contrôle, consignés dans un registre à falsification détectable. Un runtime, ~22 services, un schéma Postgres, vos modèles et votre déploiement au choix.
Humain → Agent → Compétence → Prompt → Politique → Modèle → Outil → Artefact → Résultat → Approbation
Le cycle de vie de l'agent
Dix étapes, entièrement chaînées, de l'intention humaine à l'approbation signée.
Cortex n'exécute pas un prompt dans une boîte noire. Chaque exécution est une chaîne d'étapes typées et attribuées — et chaque maillon est capturé, de sorte que tout résultat peut être remonté jusqu'à la personne qui l'a déclenché et à la politique qui l'a autorisé.
- 01
Humain → Agent → Compétence
Une personne (ou une planification, un canal ou un workflow) invoque un agent enregistré agissant sous sa propre identité — et une compétence déclarée précise, jamais le modèle brut.
- 02
Prompt → Politique → Modèle
Le prompt composé est lié à une décision de politique. Ce n'est qu'ensuite que l'exécution atteint un modèle autorisé — fournisseur et version vérifiés au regard de l'identité de l'agent.
- 03
Outil → Artefact → Résultat → Approbation
Les appels d'outils passent par la passerelle MCP, produisent des artefacts attribués, se concrétisent en un résultat assorti d'un reçu signé, et les résultats à haut risque attendent une approbation humaine.
Le pipeline de contrôle
Huit points de contrôle. Refuser est la règle par défaut.
Entre le prompt et l'exécution, chaque run franchit les mêmes points de contrôle ordonnés. N'importe lequel peut échouer en fermé — et lorsque c'est le cas, l'exécution s'arrête avec un code précis et auditable au lieu de se poursuivre en silence.
02 · Budget
- Plafonds en USD sur 30 jours par locataire et par agent
- Le plafond strict bloque l'exécution à 100% → 402
- Le plafond souple déclenche une alerte et laisse une trace fidèle dans le registre
03 · Garde-fous
- Les garde-fous d'entrée filtrent les prompts avant le modèle
- Contrôles PII / DLP et injection de prompt
- Des règles en langage clair compilées en contrôles appliqués
04 · Registre
- Le modèle et l'outil doivent figurer sur la liste d'autorisation de l'agent
- Modèle non autorisé → exécution refusée
- Versions figées, dérives mises en évidence
05 · Control Tower
- Vue en direct de la flotte avec un unique coupe-circuit
- Limites de concurrence et de débit appliquées
- Mettez une flotte en pause sans déploiement
06 · Exécution
- L'appel au modèle n'a lieu qu'après les points de contrôle 01–05
- Les appels d'outils passent par la passerelle MCP
- Coût et latence mesurés à chaque appel
07 · Contrôle des sorties
- La sortie générée est re-contrôlée avant de partir
- Ancrage aux sources et couverture des citations vérifiés
- Toute sortie non sûre ou non étayée est retenue
08 · Audit
- Chaque exécution est chaînée par hash dans le Trust Ledger
- Reçu signé, vérifiable hors ligne
- verifyChain détecte toute modification ultérieure
Échec fermé, avec des codes auditables
plafond budget402 BUDGET_EXCEEDEDidentité expirée403 EXPIREDpack altéré409 hashOk:false
Architecture du système
Un runtime, ~22 services, un seul schéma.
Cortex est une console Next.js au-dessus d'un runtime d'environ 22 microservices NestJS — agents, actions, ontologie, politique, registre, observabilité et davantage — adossés à un unique schéma Postgres cortex. Chaque lecture et chaque écriture sont limitées au locataire de l'appelant : l'isolation est donc appliquée dans la couche de données, pas ajoutée après coup.
- Console Next.js — une interface simple/avancée sur les mêmes API gouvernées
- ~22 microservices NestJS derrière les huit points de contrôle du runtime
- Un unique schéma Postgres cortex avec isolation multi-locataire au niveau des lignes
- LLM et systèmes en aval interchangeables — aucun verrouillage fournisseur
Multi-locataire par conception
Le cloisonnement est appliqué dans le chemin de données, pas dans l'interface.
Les mêmes points de contrôle et le même registre s'appliquent à chaque locataire — mais aucun locataire ne peut jamais lire, écrire ou importer chez un autre. L'isolation est vérifiée à chaque requête et à chaque import de pack.
Données cloisonnées
- Chaque requête est liée au locataire de l'appelant
- Objets et propriétés de l'ontologie appartiennent au locataire
- Aucune lecture inter-locataires, jamais
Runtime cloisonné
- Les identités d'agent vivent à l'intérieur d'un locataire
- Budgets, politiques et supervision sont propres à chaque locataire
- Le coupe-circuit de Control Tower tient compte du locataire
Registre cloisonné
- Chaque locataire dispose de sa propre chaîne de hachage
- Reçus vérifiables hors ligne par locataire
- L'import d'un pack n'atterrit que dans le locataire de l'appelant
Déployez partout
Cloud, VPC ou totalement isolé — vos données restent où vous les placez.
Le même runtime s'exécute dans notre cloud, dans votre VPC ou dans un environnement déconnecté. Apportez vos propres modèles locaux, fixez la résidence et conservez le registre à falsification détectable en dessous de tout.
Cortex Cloud
Géré, multi-région
Région fixéeInternet
Vos propres modèles locaux (vLLM · Ollama · TGI)
Votre VPC
Mono-locataire dans votre compte
Votre régionLien privé
Vos propres modèles locaux (vLLM · Ollama · TGI)
Isolé du réseau
Déconnecté / sur site
Sur site uniquementAucune sortie réseau
Vos propres modèles locaux (vLLM · Ollama · TGI)
Le même runtime en dessoushuit points de contrôle · schéma cortex · Trust Ledger à falsification détectable · fixation de la résidence
~22Microservices NestJS dans un seul runtime
8Contrôles de gouvernance à chaque exécution
10-hopTraçabilité de l'humain à l'approbation
1Schéma Postgres, isolé par tenant
Pour les développeurs
Gouverné par défaut — via l'API, la CLI ou un pack signé.
Vous ne sacrifiez pas le contrôle à la productivité. Les mêmes points de contrôle qui protègent la console protègent chaque appel programmatique : un agent livré par API est aussi gouverné qu'un agent construit à la main. Définissez ontologie, politique, actions et agents sous forme de code, puis exportez-les en Solution Pack signé et vérifiable.
- Les mêmes huit points de contrôle, que l'exécution démarre dans l'interface, dans un workflow ou via un appel API
- Policy-as-Code, ontologie et actions versionnés avec vos agents
- Solution Packs signés — verifyPack vérifie hashOk + signatureOk avant l'import
- Rejouez n'importe quelle exécution depuis le registre pour reproduire exactement ce qui s'est passé
Voyez toute l'exécution, de bout en bout.
De la personne qui l'a déclenchée à la politique qui l'a autorisée jusqu'au reçu qui la prouve — Cortex rend chaque exécution d'agent opposable.