Security & Compliance

The KLA Control Plane is a govern-in-place runtime safety, audit, and governance layer for enterprise AI agents. Because KLA sits in the execution path of agents that touch real customer data and trigger real business actions, its security posture is not a feature list. It is the foundation that makes the evidence trustworthy. This page is written for compliance, risk, and audit officers, and for security reviewers conducting due diligence. It explains how data is handled, how trust is enforced cryptographically, who can do what, and how every control maps to the frameworks you report against.

A single principle runs through everything below: controls produce evidence, and evidence is tamper-evident. A policy decision is not merely enforced; it is captured as a Lineage Record (a structured trace of an agent's actions and the decisions made on them) and anchored to a cryptographic ledger so it can be independently verified later.

Data Handling

KLA is built to minimize what sensitive data ever leaves your environment and to isolate what does.

• PII redaction in transit. Agent activity is captured as OpenTelemetry spans and sent to the KLA Collector, which redacts personally identifiable information (emails, payment numbers, secrets, API keys) before the data is written to durable storage. Redaction happens in flight, so raw PII is not persisted in the evidence pipeline.
• Tenant isolation. Every record is scoped to a tenant. API calls carry an x-tenant-id header alongside the bearer token, and storage enforces row-level isolation so one tenant can never read another's Lineage Records, Releases, or Sealed Evidence Bundles.
• Least-privilege execution. Agents act through a governed Tool Catalog (the inventory of tools an agent is permitted to call) and Secrets Vault (governed secret storage). A Decision Request is evaluated against policy before a tool runs, so an agent only ever executes the narrowest set of actions a policy explicitly allows.

Encryption & Signing

Trust in KLA is enforced with cryptography at three points, not by convention.

Identity & Access

KLA authenticates every caller through standard OAuth2 / OIDC (OpenID Connect). There are no static, shared API keys for human users.

• Human users sign in through a browser-based PKCE flow against your identity provider and receive a short-lived bearer token.
• Service accounts (machine callers such as a CI pipeline registering a Release) use a confidential OAuth2 client and exchange a client secret for a token.
• Roles govern what a principal can do. For example, a reviewer role can act on the Decision Desk, while an approver role can resolve a paused Escalation.

Every API request presents both headers:

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

Tamper-Evident Audit

The evidence pipeline is what lets a reviewer trust a record they did not personally observe being created.

flowchart LR
  A["Agent action"] --> B["OpenTelemetry spans"]
  B --> C["KLA Collector"]
  C -->|"PII redaction"| D["ImmuDB ledger"]
  D -->|"Merkle proof"| E["Sealed Evidence Bundle"]

Spans are hashed and committed to ImmuDB, an append-only cryptographic ledger. Records cannot be deleted, modified, or re-ordered after the fact. Any auditor can verify a Sealed Evidence Bundle offline (confirming its signatures, every artifact hash, and the bundle's own recomputed Merkle root) to confirm the export was not altered. This is what we mean by Independent Verification: most checks need only the bundle, not a live connection to KLA. (The ledger anchor and Bitcoin timestamp are retained in the bundle; deeper ledger-inclusion and on-chain confirmation require the ledger's signed state and the Bitcoin chain respectively.)

Trust Boundary

The diagram below shows where your data is, where KLA enforces controls, and what crosses each boundary.

flowchart TD
  subgraph Customer["Customer environment"]
    AG["Instrumented agents"]
  end
  subgraph KLA["KLA Control Plane"]
    GATE{"Policy decision"}
    COL["Collector and redaction"]
    LED["ImmuDB ledger"]
  end
  AG -->|"mTLS spans"| COL
  AG -->|"Decision Request"| GATE
  GATE -->|"require_approval"| DESK["Decision Desk"]
  COL --> LED
  LED --> ROOM["Evidence Room"]

Policy is evaluated in process for the Govern in Place pattern, so a block or require_approval outcome stops the action before it executes. Only redacted, signed evidence crosses into long-term storage.

Control Mapping

The Evidence Room is where security posture becomes a compliance deliverable. Control Mapping links KLA's controls to the requirements of the frameworks you report against, and a Control Pack is the export you hand to an auditor. The table below maps a KLA capability to what it gives a reviewer.