Sicherheit & Compliance

Die KLA Control Plane ist eine Govern-in-Place-Schicht für Laufzeitsicherheit, Audit und Governance von KI-Agenten im Unternehmen. Da KLA im Ausführungspfad von Agenten sitzt, die mit echten Kundendaten arbeiten und echte Geschäftsaktionen auslösen, ist ihre Sicherheitsarchitektur keine bloße Liste von Funktionen. Sie ist das Fundament, das die Nachweise vertrauenswürdig macht. Diese Seite richtet sich an Verantwortliche für Compliance, Risiko und Audit sowie an Sicherheitsprüfer, die eine Due-Diligence-Prüfung durchführen. Sie erklärt, wie Daten verarbeitet werden, wie Vertrauen kryptografisch durchgesetzt wird, wer was tun darf und wie jede Kontrolle den Rahmenwerken zugeordnet wird, nach denen Sie berichten.

Ein einziges Prinzip zieht sich durch alles Folgende: Kontrollen erzeugen Nachweise, und Nachweise sind manipulationssicher. Eine Richtlinienentscheidung wird nicht nur durchgesetzt; sie wird als Lineage Record erfasst (eine strukturierte Aufzeichnung der Aktionen eines Agenten und der dazu getroffenen Entscheidungen) und in einem kryptografischen Ledger verankert, damit sie später unabhängig verifiziert werden kann.

Datenverarbeitung

KLA ist darauf ausgelegt, zu minimieren, welche sensiblen Daten Ihre Umgebung überhaupt verlassen, und das, was sie verlässt, zu isolieren.

• PII-Schwärzung während der Übertragung. Die Aktivität von Agenten wird als OpenTelemetry-Spans erfasst und an den KLA Collector gesendet, der personenbezogene Daten (E-Mail-Adressen, Zahlungsnummern, Geheimnisse, API-Schlüssel) schwärzt, bevor die Daten in den dauerhaften Speicher geschrieben werden. Die Schwärzung erfolgt während der Übertragung, sodass ungeschwärzte PII nicht in der Nachweis-Pipeline persistiert werden.
• Mandantenisolierung. Jeder Datensatz ist einem Mandanten zugeordnet. API-Aufrufe führen neben dem Bearer-Token einen x-tenant-id-Header, und der Speicher erzwingt eine Isolierung auf Zeilenebene, sodass ein Mandant niemals die Lineage Records, Releases oder Sealed Evidence Bundles eines anderen lesen kann.
• Ausführung mit minimalen Rechten. Agenten handeln über einen gesteuerten Tool Catalog (das Inventar der Tools, die ein Agent aufrufen darf) und einen Secrets Vault (gesteuerte Geheimnisverwaltung). Eine Decision Request wird gegen die Richtlinie ausgewertet, bevor ein Tool ausgeführt wird, sodass ein Agent stets nur die engste Menge an Aktionen ausführt, die eine Richtlinie ausdrücklich erlaubt.

Verschlüsselung & Signierung

Vertrauen in KLA wird durch Kryptografie an drei Stellen durchgesetzt, nicht durch Konvention.

Identität & Zugriff

KLA authentifiziert jeden Aufrufer über standardisiertes OAuth2 / OIDC (OpenID Connect). Es gibt keine statischen, geteilten API-Schlüssel für menschliche Nutzer.

• Menschliche Nutzer melden sich über einen browserbasierten PKCE-Flow bei Ihrem Identity Provider an und erhalten ein kurzlebiges Bearer-Token.
• Service-Accounts (maschinelle Aufrufer wie eine CI-Pipeline, die einen Release registriert) verwenden einen vertraulichen OAuth2-Client und tauschen ein Client-Secret gegen ein Token.
• Rollen bestimmen, was ein Principal tun darf. Beispielsweise kann eine Reviewer-Rolle am Decision Desk tätig werden, während eine Approver-Rolle eine pausierte Escalation auflösen kann.

Jede API-Anfrage übergibt beide Header:

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

Manipulationssicheres Audit

Die Nachweis-Pipeline ist das, was einem Prüfer erlaubt, einem Datensatz zu vertrauen, dessen Erstellung er nicht persönlich beobachtet hat.

flowchart LR
  A["Agentenaktion"] --> B["OpenTelemetry-Spans"]
  B --> C["KLA Collector"]
  C -->|"PII-Schwärzung"| D["ImmuDB-Ledger"]
  D -->|"Merkle proof"| E["Sealed Evidence Bundle"]

Spans werden gehasht und in ImmuDB festgeschrieben, einem nur anhängbaren (append-only) Ledger auf kryptografischer Basis. Datensätze können nachträglich weder gelöscht noch verändert oder umsortiert werden. Jeder Batch veröffentlicht einen Merkle-Wurzel-Hash, und jeder Auditor kann die Hashes aus einem Sealed Evidence Bundle neu berechnen, um zu bestätigen, dass der Verlauf nicht manipuliert wurde. Das ist es, was wir mit Independent Verification meinen: Sie müssen sich nicht auf das Wort von KLA verlassen, Sie können die Mathematik selbst nachprüfen.

Vertrauensgrenze

Das folgende Diagramm zeigt, wo sich Ihre Daten befinden, wo KLA Kontrollen durchsetzt und was jede Grenze überschreitet.

flowchart TD
  subgraph Customer["Kundenumgebung"]
    AG["Instrumentierte Agenten"]
  end
  subgraph KLA["KLA Control Plane"]
    GATE{"Richtlinienentscheidung"}
    COL["Collector und Schwärzung"]
    LED["ImmuDB-Ledger"]
  end
  AG -->|"mTLS-Spans"| COL
  AG -->|"Decision Request"| GATE
  GATE -->|"require_approval"| DESK["Decision Desk"]
  COL --> LED
  LED --> ROOM["Evidence Room"]

Die Richtlinie wird beim Govern in Place-Muster prozessintern ausgewertet, sodass ein Ergebnis von block oder require_approval die Aktion stoppt, bevor sie ausgeführt wird. Nur geschwärzte, signierte Nachweise gelangen in den Langzeitspeicher.

Control Mapping

Der Evidence Room ist der Ort, an dem das Sicherheitsniveau zu einem Compliance-Liefergegenstand wird. Control Mapping verknüpft die Kontrollen von KLA mit den Anforderungen der Rahmenwerke, nach denen Sie berichten, und ein Control Pack ist der Export, den Sie einem Auditor übergeben. Die folgende Tabelle bildet eine KLA-Fähigkeit auf das ab, was sie einem Prüfer liefert.