Plateforme développeur

Développez sur le runtime gouverné.

Un SDK typé, une API REST et une CLI pour la plateforme d'agents IA gouvernés — enregistrez des agents, proposez des actions, rédigez la politique, interrogez l'ontologie et lisez un Trust Ledger à intégrité vérifiable. Les portes qui protègent la console s'appliquent à chaque requête.

Rejoindre la liste d'attente Voir l'architecture

SDK @cortex/client · REST · CLI · Webhooks · Sandbox

agent.tspolicy.tscurl

exemple

// Écrivez une fois. Chaque exécution franchit les portes, chaque action est prouvable.

import { Cortex } from "@cortex/client";

const cortex = new Cortex({ apiKey, tenantId });

// Proposez une action à haut risque — ce sont les portes qui décident.

const res = await cortex.actions.propose({

  key: "refund.issue",

  input: { amount: 5000 },

});

pending_approval{ status: "pending_approval", riskLevel: "high" }

// Les actions à haut risque attendent un admin. Approuvez, puis lisez

// le reçu signé — vérifiable hors ligne face à la chaîne.

audit/verify ▸ { ok: true, brokenAtSeq: null, head: { seq: 1042, hash: "0x9f3a…c1" } }

Démarrage rapide

De l'installation à un verdict gouverné en trois étapes.

Installez le SDK, authentifiez-vous auprès d'un tenant et proposez votre première action gouvernée — chaque appel étant consigné dans un Trust Ledger vérifiable hors ligne. Les extraits ci-dessous sont des exemples illustratifs.

01
Installer @cortex/client
Ajoutez le SDK typé à votre projet. C'est un client léger au-dessus de la même API REST et des mêmes contrôles à refus par défaut.
02
S'authentifier
Construisez le client avec votre clé API limitée au tenant et votre tenantId. Chaque appel est lié à votre tenant dans le chemin de données — aucune lecture inter-tenants.
03
Exécuter une action gouvernée et lire le verdict
Proposez une action. Les exécutions à faible risque se lancent ; les actions à haut risque ou soumises à approbation restent en pending_approval. Lisez le verdict, puis vérifiez le reçu.

installerexemple

# 01 · installez le SDK typé
npm i @cortex/client
 
# 02 · authentifiez-vous (clé d'API + tenant)
import { Cortex } from "@cortex/client";
const cortex = new Cortex({
  apiKey: process.env.CORTEX_KEY,
  tenantId: process.env.CORTEX_TENANT,
});

exécuter une action gouvernéeexemple

// 03 · propose — les portes décident du verdict
const res = await cortex.actions.propose({
  key: "refund.issue",
  input: { amount: 5000 },   // haut risque
});
 
// → { status: "pending_approval", riskLevel: "high" }
// les actions à faible risque renvoient { status: "executed" }

Concepts clés

Six notions à la base de toute intégration.

Ces surfaces sont des clients légers du même runtime gouverné. Assimilez le concept, puis suivez chacune vers sa page de capacité pour la vue complète.

Runtime gouverné et contrôles

Chaque exécution franchit les mêmes portes, dans le même ordre
Le refus est la valeur par défaut — fail-closed
Codes stables : 402 · 403 · 409 · architecture

Ontologie et permissions

Modèle d'objets d'entreprise typé
RBAC au niveau objet et propriété (none/read/write)
Les lectures masquent tout ce qui est en dessous de read · ontologie

Action Fabric

Des actions nommées, avec un niveau de risque
dry-run → propose → approve → execute
Registre d'invocations immuable · action fabric

Trust Ledger et traçabilité

Un audit chaîné par hash et inviolable
Des reçus signés, vérifiables hors ligne
Traçabilité sur 10 sauts · trust ledger

Agent IAM

Les agents sont des identités gouvernées
Propriétaire · niveau de risque · expiration · modèles autorisés
Identité expirée → 403 · agent IAM

Solution Packs

Ontologie, politiques et actions en un seul artefact
Signé · vérifié · comparé à l'import
Redéployez-le dans votre tenant · packs

API et ressources

Les domaines de ressources que vous manipulerez.

Atteignez chaque surface gouvernée via REST, le SDK typé @cortex/client ou la CLI. Vous trouverez ci-dessous le rôle de chaque domaine de ressources — et non une référence exhaustive des endpoints. Suivez une carte pour découvrir la capacité complète.

Agents et identités

client.agentIdentities

Enregistrez vos agents comme des identités gouvernées, avec un propriétaire, un niveau de risque, une expiration et des modèles/actions autorisés. Une identité expirée ou suspendue est refusée à l'exécution (403).

Actions

client.actions

Des actions nommées, dotées d'un niveau de risque et d'une politique d'approbation. Dry-run → propose → approve/deny → execute → compensate : chaque étape est consignée dans un registre d'invocations immuable, avec son pack de preuves.

Politiques

client.governance

Rédigez vos règles, puis simulez une décision (avec la trace règle par règle) ou exécutez des tests golden de politiques sur un jeu de règles candidat avant de livrer — l'effet le plus restrictif l'emporte.

Ontologie et permissions

client.ontology

Un modèle d'objets d'entreprise typé, avec un RBAC au niveau objet et propriété. Les autorisations se résolvent en none / read / write ; les lectures masquent les propriétés situées sous read et les écritures sont contrôlées par type.

Audit et vérification

GET /v1/audit/verify

Un registre d'audit chaîné par hash et inviolable. verify renvoie { ok, brokenAtSeq, head } sur une plage, et head renvoie la tête de chaîne actuelle pour un ancrage externe.

Solution Packs

client.packs

Regroupez des types d'ontologie, des politiques et des actions dans un artefact signé et versionné. verify contrôle hashOk + signatureOk ; import prévisualise un diff puis l'applique dans le tenant de l'appelant.

REST APISDK @cortex/clientCLIWebhooks & événements

Modes d'intégration

Cinq surfaces, un seul runtime gouverné.

L'API, le SDK, la CLI et les webhooks sont des clients légers des mêmes portes fail-closed — identité, budget, garde-fous, registre, control tower, exécution, filtre de sortie et audit. Il n'existe aucune porte dérobée non gouvernée.

REST API

Pilotez chaque surface gouvernée en HTTPS — enregistrez des actions, proposez-les et approuvez-les, interrogez l'ontologie, lancez des simulations de gouvernance et consultez le Trust Ledger. Les portes qui protègent la console protègent l'API.

limité au tenant · Bearer token

Le cloisonnement par tenant est appliqué dans le chemin de données
Routes réservées aux administrateurs (approve · deny · pack import), contrôlées côté serveur
Des codes de statut stables sur lesquels brancher votre logique — 402 · 403 · 409

@cortex/client SDK

Client TypeScript typé au-dessus de l'API REST. Des ressources fortement typées pour les agents, les actions, la gouvernance, l'ontologie, l'audit et les packs — avec le même cloisonnement par tenant et la même sémantique de portes que l'API brute.

npm i @cortex/client · ESM + types

client.actions · client.governance · client.packs
client.ontology.permissions · client.agentIdentities
Token + tenantId à chaque appel

CLI

Livrez la gouvernance depuis votre terminal et votre CI. Exportez et vérifiez des Solution Packs signés, exécutez des tests de politiques comme garde-fou anti-régression et consultez le Trust Ledger — sans quitter le pipeline.

scriptable · compatible CI

Exécutez les tests de politiques avant de livrer une modification de règle
Exportez et vérifiez un pack signé (hashOk · signatureOk)
Vérifiez la chaîne du ledger hors ligne

Webhooks et événements

Cortex émet des événements de cycle de vie gouvernés — ActionExecuted, ActionFailed, décisions d'approbation — via le chemin d'événements de la plateforme qui scelle aussi le Trust Ledger. Abonnez-vous pour vous réconcilier avec la piste d'audit à intégrité vérifiable.

événementiel · scellé dans le ledger

Cycle de vie de l'action : proposed · approved · executed · compensated
Chaque événement est scellé dans la chaîne de hachage au moment de son enregistrement
Réconciliez par séquence du ledger (seq)

Sandbox et démarrage rapide

Un tenant gouverné que vous pouvez provisionner et alimenter avec une ontologie, des politiques et des actions d'exemple. Lancez votre première action soumise aux portes et consultez un vrai Trust Ledger vérifiable — sans toucher à la production.

isolé par tenant · 0 impact sur la production

Chargez une ontologie, des politiques et des actions d'exemple
D'abord un dry-run — l'entrée est validée, sans effet de bord
Inspectez chaque décision de porte dans le journal d'invocations

Policy-as-Code

Versionnez la gouvernance comme vous versionnez votre application. Rédigez des règles allow / require-approval / deny, simulez une décision avant de livrer et verrouillez les changements avec des tests de politiques de référence dans la CI.

simuler · tester · promouvoir

La plus restrictive l'emporte : deny > require_approval > allow
simulate() renvoie la trace de décision règle par règle
tests.run() comme garde-fou anti-régression avant la livraison

Démontrable, pas seulement journalisé

Vérifiez le registre hors ligne.

Le Trust Ledger est chaîné par hachage : chaque enregistrement scelle le précédent. verifyChain recalcule la chaîne et renvoie { ok, brokenAtSeq } — toute insertion, modification, suppression ou réorganisation fait passer ok à false. Les reçus de résultat sont des signatures détachées que vous pouvez vérifier avec la clé publiée : un tiers peut ainsi confirmer qu'une exécution a bien eu lieu sans faire confiance à la base de données de Cortex. L'extrait est un exemple illustratif.

Intégrité de la chaîne : verifyChain(records) → { ok, brokenAtSeq }
Reçus signés : verifyReceipt(claims, sig, key), en temps constant
HMAC-SHA256 aujourd'hui ; les clés de vérification publiables Ed25519 constituent l'évolution documentée

Découvrir le Trust Ledger Voir l'architecture

vérifier hors ligneexemple

import {
  verifyChain, verifyReceipt,
} from "@cortex/provenance";
 
// 1 · recalculez la chaîne de hachages
const v = verifyChain(records);
// → { ok: true, brokenAtSeq: null }
 
// 2 · vérifiez un reçu de résultat signé
const valid = verifyReceipt(
  claims, signature, verifyKey,
);
// → true   (falsification → false)

Aller plus loin

Comprenez le runtime sur lequel vous développez.

Les surfaces développeur reposent sur l'intégralité de la plateforme. Découvrez comment les portes s'articulent et explorez chaque capacité gouvernée de bout en bout.

L'architecture

La console, les portes du runtime, ~22 microservices et une ontologie unique adossée à Postgres avec le Trust Ledger — le système en couches que traverse chaque appel d'API.

Voir l'architecture

La plateforme

Action Fabric, Agent IAM, l'ontologie, les modes de supervision, la passerelle MCP et le Trust Ledger — chaque capacité gouvernée, accessible depuis l'API et le SDK.

Explorer la plateforme

Créez des agents gouvernés dès le premier jour.

Bénéficiez d'une visite guidée de l'API, du SDK et de la CLI — et voyez votre première action soumise aux portes atterrir dans un Trust Ledger vérifiable.

Rejoindre la liste d'attente Parler à l'équipe d'ingénierie

Développez sur le runtime gouverné.

De l'installation à un verdict gouverné en trois étapes.

Installer @cortex/client

S'authentifier

Exécuter une action gouvernée et lire le verdict

Six notions à la base de toute intégration.

Les domaines de ressources que vous manipulerez.

Cinq surfaces, un seul runtime gouverné.

Vérifiez le registre hors ligne.

Comprenez le runtime sur lequel vous développez.

L'architecture

La plateforme

Créez des agents gouvernés dès le premier jour.