Seguridad y cumplimiento | Developer Docs

KLA Control Plane es una capa de seguridad, auditoría y gobernanza en tiempo de ejecución que aplica el patrón de gobernanza en el lugar (govern-in-place) para agentes de IA empresariales. Dado que KLA se sitúa en la ruta de ejecución de agentes que manipulan datos reales de clientes y desencadenan acciones de negocio reales, su postura de seguridad no es una lista de funciones. Es la base que hace que la evidencia sea confiable. Esta página está dirigida a responsables de cumplimiento, riesgo y auditoría, así como a los revisores de seguridad que llevan a cabo la diligencia debida. Explica cómo se manejan los datos, cómo se hace cumplir la confianza de forma criptográfica, quién puede hacer qué y cómo cada control se corresponde con los marcos sobre los que usted informa.

Un único principio recorre todo lo que sigue: los controles producen evidencia, y la evidencia es a prueba de manipulaciones. Una decisión de política no solo se aplica: se captura como un Lineage Record (una traza estructurada de las acciones de un agente y de las decisiones tomadas sobre ellas) y se ancla a un libro mayor criptográfico para que pueda verificarse de forma independiente más adelante.

Manejo de datos

KLA está diseñado para minimizar la cantidad de datos sensibles que llegan a salir de su entorno y para aislar los que sí lo hacen.

Redacción de PII en tránsito. La actividad de los agentes se captura como spans de OpenTelemetry y se envía al KLA Collector, que redacta la información de identificación personal (correos electrónicos, números de pago, secretos, claves de API) antes de que los datos se escriban en almacenamiento duradero. La redacción ocurre en tránsito, por lo que la PII en bruto no se conserva en la canalización de evidencia.
Aislamiento de inquilinos. Cada registro está acotado a un inquilino. Las llamadas a la API incluyen una cabecera x-tenant-id junto al token de portador, y el almacenamiento aplica aislamiento a nivel de fila para que un inquilino nunca pueda leer los Lineage Records, Releases o Sealed Evidence Bundles de otro.
Ejecución con privilegios mínimos. Los agentes actúan a través de un Tool Catalog gobernado (el inventario de herramientas que un agente tiene permitido invocar) y de un Secrets Vault (almacenamiento gobernado de secretos). Una Decision Request se evalúa frente a la política antes de que se ejecute una herramienta, de modo que un agente solo ejecuta el conjunto más reducido de acciones que una política permite de forma explícita.

ℹ️ Note

La redacción se aplica antes de la persistencia, no después. Si un valor se enmascara en tránsito, el valor sin enmascarar nunca llega al libro mayor criptográfico, por lo que no puede reconstruirse más adelante a partir de su evidencia.

Cifrado y firma

La confianza en KLA se hace cumplir con criptografía en tres puntos, no por convención.

Control	Qué protege
mTLS entre servicios	Cada salto interno está autenticado mutuamente y cifrado. Cada servicio prueba su identidad con un certificado, de modo que el tráfico no puede suplantarse ni interceptarse entre componentes.
Paquetes de políticas firmados	Las políticas declarativas en YAML se simulan y luego se compilan en un paquete de políticas firmado con calidad de Control Pack. El runtime solo carga paquetes cuya firma puede verificar, por lo que una política no autorizada o modificada no puede surtir efecto.
Sealed Evidence Bundles	Las exportaciones se sellan criptográficamente y llevan una Merkle proof por cada Lineage Record, de modo que cualquier tercero puede verificar que la exportación está completa y sin alterar.

Identidad y acceso

KLA autentica a todos los llamantes mediante OAuth2 / OIDC (OpenID Connect) estándar. No existen claves de API estáticas ni compartidas para usuarios humanos.

Los usuarios humanos inician sesión mediante un flujo PKCE basado en navegador contra su proveedor de identidad y reciben un token de portador de corta duración.
Las cuentas de servicio (llamantes de máquina, como una canalización de CI que registra un Release) usan un cliente OAuth2 confidencial e intercambian un secreto de cliente por un token.
Los roles determinan lo que un principal puede hacer. Por ejemplo, un rol de revisor puede actuar en el Decision Desk, mientras que un rol de aprobador puede resolver una Escalation pausada.

Cada solicitud a la API presenta ambas cabeceras:

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

💡 Tip

Para la emisión de tokens, el registro de clientes y la decisión entre PKCE y cuenta de servicio, consulte la guía de [Autenticación](/docs/getting-started/authentication).

Auditoría a prueba de manipulaciones

La canalización de evidencia es lo que permite a un revisor confiar en un registro cuya creación no presenció personalmente.

flowchart LR
  A["Acción del agente"] --> B["spans de OpenTelemetry"]
  B --> C["KLA Collector"]
  C -->|"Redacción de PII"| D["Libro mayor ImmuDB"]
  D -->|"Merkle proof"| E["Sealed Evidence Bundle"]

A los spans se les calcula un hash y se confirman en ImmuDB, un libro mayor criptográfico de solo anexión. Los registros no pueden eliminarse, modificarse ni reordenarse a posteriori. Cada lote publica un hash de raíz Merkle, y cualquier auditor puede recalcular los hashes a partir de un Sealed Evidence Bundle para confirmar que el historial no se manipuló. Esto es lo que entendemos por verificación independiente: no tiene que confiar en la palabra de KLA, puede verificar las matemáticas.

Límite de confianza

El diagrama siguiente muestra dónde están sus datos, dónde aplica KLA los controles y qué cruza cada límite.

flowchart TD
  subgraph Customer["Entorno del cliente"]
    AG["Agentes instrumentados"]
  end
  subgraph KLA["KLA Control Plane"]
    GATE{"Decisión de política"}
    COL["Collector y redacción"]
    LED["Libro mayor ImmuDB"]
  end
  AG -->|"spans por mTLS"| COL
  AG -->|"Decision Request"| GATE
  GATE -->|"require_approval"| DESK["Decision Desk"]
  COL --> LED
  LED --> ROOM["Evidence Room"]

La política se evalúa en proceso para el patrón Govern in Place, de modo que un resultado block o require_approval detiene la acción antes de que se ejecute. Solo la evidencia redactada y firmada cruza al almacenamiento a largo plazo.

Control Mapping

El Evidence Room es donde la postura de seguridad se convierte en un entregable de cumplimiento. Control Mapping vincula los controles de KLA con los requisitos de los marcos sobre los que usted informa, y un Control Pack es la exportación que entrega a un auditor. La tabla siguiente relaciona una capacidad de KLA con lo que ofrece a un revisor.

Capacidad de KLA	Qué obtiene un revisor
Ejecución gobernada por políticas (allow, warn, require_approval, block)	Evidencia de que las acciones de riesgo se aplicaron o escalaron, cumpliendo con los registros del Anexo IV de la EU AI Act sobre supervisión humana y controles de riesgo.
Escalaciones del Decision Desk	Un registro firmado de cada aprobación humana, incluyendo quién aprobó, cuándo y en qué contexto.
Lineage Records + ImmuDB	Un rastro de auditoría a prueba de manipulaciones que demuestra los controles de registro, integridad y gestión de cambios de SOC 2 Type II.
Redacción de PII + aislamiento de inquilinos	Evidencia de controles de minimización y segregación de datos para revisiones de privacidad y confidencialidad.
Sealed Evidence Bundles	Una exportación autoverificable con Merkle proofs, que elimina la necesidad de confiar en el almacenamiento del proveedor.

🛡️ Important

Un **Control Pack** se genera a partir de evidencia sellada, no se rearma a mano. El artefacto que envía son los mismos datos que se anclaron en tiempo de ejecución, por lo que lo que atestigua y lo que realmente ocurrió no pueden divergir.