Sécurité et conformité | Developer Docs

Le KLA Control Plane est une couche de sécurité, d'audit et de gouvernance d'exécution qui s'applique sur place (govern-in-place) pour les agents d'IA d'entreprise. Parce que KLA se situe sur le chemin d'exécution d'agents qui manipulent de vraies données client et déclenchent de vraies actions métier, sa posture de sécurité n'est pas une simple liste de fonctionnalités. C'est le socle qui rend la preuve digne de confiance. Cette page s'adresse aux responsables de la conformité, des risques et de l'audit, ainsi qu'aux évaluateurs de sécurité menant des travaux de due diligence. Elle explique comment les données sont traitées, comment la confiance est imposée cryptographiquement, qui peut faire quoi, et comment chaque contrôle correspond aux cadres réglementaires auxquels vous devez rendre des comptes.

Un principe unique parcourt tout ce qui suit : les contrôles produisent des preuves, et ces preuves sont infalsifiables. Une décision de politique n'est pas seulement appliquée ; elle est capturée sous la forme d'un Lineage Record (une trace structurée des actions d'un agent et des décisions prises à leur sujet) et ancrée dans un registre cryptographique afin de pouvoir être vérifiée indépendamment par la suite.

Traitement des données

KLA est conçu pour minimiser les données sensibles qui quittent votre environnement et pour isoler celles qui le font.

Caviardage des données personnelles en transit. L'activité des agents est capturée sous forme de spans OpenTelemetry et envoyée au KLA Collector, qui caviarde les informations personnelles identifiables (e-mails, numéros de paiement, secrets, clés API) avant l'écriture des données dans un stockage durable. Le caviardage a lieu en transit, de sorte que les données personnelles brutes ne sont jamais persistées dans le pipeline de preuves.
Isolation des locataires. Chaque enregistrement est rattaché à un locataire. Les appels API portent un en-tête x-tenant-id aux côtés du jeton porteur, et le stockage impose une isolation au niveau des lignes afin qu'un locataire ne puisse jamais lire les Lineage Records, les Releases ou les Sealed Evidence Bundles d'un autre.
Exécution au moindre privilège. Les agents agissent via un Tool Catalog gouverné (l'inventaire des outils qu'un agent est autorisé à appeler) et un Secrets Vault (un stockage de secrets gouverné). Une Decision Request est évaluée au regard de la politique avant l'exécution d'un outil, de sorte qu'un agent n'exécute jamais que l'ensemble d'actions le plus restreint qu'une politique autorise explicitement.

ℹ️ Note

Le caviardage est appliqué avant la persistance, et non après. Si une valeur est masquée en transit, la valeur non masquée n'atteint jamais le registre cryptographique et ne peut donc pas être reconstituée ultérieurement à partir de vos preuves.

Chiffrement et signature

Dans KLA, la confiance est imposée par la cryptographie en trois points, et non par convention.

Contrôle	Ce qu'il sécurise
mTLS entre les services	Chaque saut interne est mutuellement authentifié et chiffré. Chaque service prouve son identité au moyen d'un certificat, de sorte que le trafic ne peut être ni usurpé ni intercepté entre les composants.
Packs de politiques signés	Les politiques déclaratives en YAML sont simulées, puis compilées en un pack de politiques signé de niveau Control Pack. Le Runtime ne charge que les packs dont il peut vérifier la signature, de sorte qu'une politique non autorisée ou modifiée ne peut pas prendre effet.
Sealed Evidence Bundles	Les exports sont scellés cryptographiquement et portent une Merkle proof pour chaque Lineage Record, de sorte que n'importe quel tiers peut vérifier que l'export est complet et inaltéré.

Identité et accès

KLA authentifie chaque appelant via les standards OAuth2 / OIDC (OpenID Connect). Il n'existe aucune clé API statique et partagée pour les utilisateurs humains.

Les utilisateurs humains se connectent via un flux PKCE dans le navigateur auprès de votre fournisseur d'identité et reçoivent un jeton porteur à courte durée de vie.
Les comptes de service (appelants machine, tels qu'un pipeline CI enregistrant une Release) utilisent un client OAuth2 confidentiel et échangent un secret client contre un jeton.
Les rôles régissent ce qu'un principal peut faire. Par exemple, un rôle d'évaluateur peut agir sur le Decision Desk, tandis qu'un rôle d'approbateur peut résoudre une Escalation suspendue.

Chaque requête API présente les deux en-têtes :

curl https://api.kla.digital/v1/tenants.current \
  -H "Authorization: Bearer $KLA_ACCESS_TOKEN" \
  -H "x-tenant-id: $KLA_TENANT_ID"

💡 Tip

Pour l'émission des jetons, l'enregistrement des clients et le choix entre PKCE et compte de service, consultez le guide [Authentication](/docs/getting-started/authentication).

Audit infalsifiable

Le pipeline de preuves est ce qui permet à un évaluateur de faire confiance à un enregistrement dont il n'a pas personnellement observé la création.

flowchart LR
  A["Action de l'agent"] --> B["Spans OpenTelemetry"]
  B --> C["KLA Collector"]
  C -->|"Caviardage des données personnelles"| D["Registre ImmuDB"]
  D -->|"Merkle proof"| E["Sealed Evidence Bundle"]

Les spans sont hachés et inscrits dans ImmuDB, un registre cryptographique en ajout seul (append-only). Les enregistrements ne peuvent être ni supprimés, ni modifiés, ni réordonnés après coup. Chaque lot publie un hash racine de Merkle, et tout auditeur peut recalculer les hashes à partir d'un Sealed Evidence Bundle pour confirmer que l'historique n'a pas été altéré. C'est ce que nous entendons par Vérification indépendante : vous n'avez pas à croire KLA sur parole, vous pouvez vérifier les calculs.

Frontière de confiance

Le diagramme ci-dessous montre où se trouvent vos données, où KLA impose ses contrôles et ce qui franchit chaque frontière.

flowchart TD
  subgraph Customer["Environnement du client"]
    AG["Agents instrumentés"]
  end
  subgraph KLA["KLA Control Plane"]
    GATE{"Décision de politique"}
    COL["Collector et caviardage"]
    LED["Registre ImmuDB"]
  end
  AG -->|"Spans mTLS"| COL
  AG -->|"Decision Request"| GATE
  GATE -->|"require_approval"| DESK["Decision Desk"]
  COL --> LED
  LED --> ROOM["Evidence Room"]

La politique est évaluée en cours de traitement (in process) selon le modèle Govern in Place, de sorte qu'un résultat block ou require_approval arrête l'action avant son exécution. Seules les preuves caviardées et signées franchissent la frontière vers le stockage à long terme.

Control Mapping

L'Evidence Room est l'endroit où la posture de sécurité devient un livrable de conformité. Le Control Mapping relie les contrôles de KLA aux exigences des cadres réglementaires auxquels vous devez rendre des comptes, et un Control Pack est l'export que vous remettez à un auditeur. Le tableau ci-dessous met en correspondance une capacité de KLA avec ce qu'elle apporte à un évaluateur.

Capacité de KLA	Ce qu'obtient un évaluateur
Exécution sous contrôle de politique (allow, warn, require_approval, block)	La preuve que les actions à risque ont été appliquées ou escaladées, répondant aux exigences d'enregistrement de l'Annexe IV de l'EU AI Act relatives à la supervision humaine et aux contrôles des risques.
Escalades du Decision Desk	Un enregistrement signé de chaque approbation humaine, indiquant qui a approuvé, quand et dans quel contexte.
Lineage Records + ImmuDB	Une piste d'audit infalsifiable démontrant les contrôles de journalisation, d'intégrité et de gestion des changements de SOC 2 Type II.
Caviardage des données personnelles + isolation des locataires	La preuve des contrôles de minimisation et de cloisonnement des données pour les revues de confidentialité et de protection des données.
Sealed Evidence Bundles	Un export auto-vérifiable assorti de Merkle proofs, supprimant le besoin de faire confiance au stockage du fournisseur.

🛡️ Important

Un **Control Pack** est généré à partir de preuves scellées, et non réassemblé à la main. L'artefact que vous soumettez correspond aux mêmes données que celles ancrées lors de l'exécution, de sorte que ce que vous attestez et ce qui s'est réellement produit ne peuvent pas diverger.