Sicurezza e conformità | Developer Docs

Il KLA Control Plane è un livello di sicurezza, audit e governance a runtime, di tipo govern-in-place, per gli agenti AI aziendali. Poiché KLA si colloca nel percorso di esecuzione di agenti che trattano dati reali dei clienti e attivano azioni di business reali, la sua postura di sicurezza non è un semplice elenco di funzionalità. È la base che rende le prove affidabili. Questa pagina è scritta per i responsabili di conformità, rischio e audit, e per i revisori di sicurezza che conducono attività di due diligence. Spiega come vengono gestiti i dati, come la fiducia viene garantita crittograficamente, chi può fare cosa e come ogni controllo si mappa sui framework rispetto ai quali si effettua la rendicontazione.

Un unico principio attraversa tutto ciò che segue: i controlli producono prove, e le prove sono a prova di manomissione. Una decisione di policy non viene semplicemente applicata; viene catturata come Lineage Record (una traccia strutturata delle azioni di un agente e delle decisioni prese su di esse) e ancorata a un registro crittografico, in modo da poter essere verificata in modo indipendente in un secondo momento.

Gestione dei dati

KLA è progettato per ridurre al minimo i dati sensibili che lasciano il vostro ambiente e per isolare quelli che lo fanno.

Oscuramento dei PII in transito. L'attività degli agenti viene catturata come span OpenTelemetry e inviata al KLA Collector, che oscura le informazioni personali identificabili (email, numeri di pagamento, segreti, chiavi API) prima che i dati vengano scritti nello storage durevole. L'oscuramento avviene in transito, quindi i PII grezzi non vengono mai persistiti nella pipeline delle prove.
Isolamento dei tenant. Ogni record è circoscritto a un tenant. Le chiamate API trasportano un header x-tenant-id insieme al bearer token, e lo storage applica l'isolamento a livello di riga, così che un tenant non possa mai leggere i Lineage Records, le Releases o i Sealed Evidence Bundles di un altro.
Esecuzione con privilegio minimo. Gli agenti operano attraverso un Tool Catalog governato (l'inventario degli strumenti che un agente è autorizzato a invocare) e un Secrets Vault (storage governato dei segreti). Una Decision Request viene valutata rispetto alla policy prima che uno strumento venga eseguito, così che un agente esegua sempre e solo l'insieme più ristretto di azioni esplicitamente consentito da una policy.

ℹ️ Note

L'oscuramento viene applicato prima della persistenza, non dopo. Se un valore viene mascherato in transito, il valore non mascherato non raggiunge mai il registro crittografico e quindi non può essere ricostruito in seguito a partire dalle vostre prove.

Cifratura e firma

In KLA la fiducia è garantita con la crittografia in tre punti, non per convenzione.

Controllo	Cosa protegge
mTLS tra i servizi	Ogni hop interno è autenticato reciprocamente e cifrato. Ciascun servizio dimostra la propria identità con un certificato, così che il traffico non possa essere falsificato o intercettato tra i componenti.
Policy pack firmati	Le policy dichiarative in YAML vengono simulate, poi compilate in un policy pack firmato di livello Control Pack. Il runtime carica solo i pack la cui firma è in grado di verificare, così che una policy non autorizzata o modificata non possa entrare in vigore.
Sealed Evidence Bundles	Le esportazioni sono sigillate crittograficamente e includono una Merkle proof per ogni Lineage Record, così che qualsiasi terza parte possa verificare che l'esportazione sia completa e inalterata.

Identità e accesso

KLA autentica ogni chiamante tramite gli standard OAuth2 / OIDC (OpenID Connect). Non esistono chiavi API statiche e condivise per gli utenti umani.

Gli utenti umani accedono tramite un flusso PKCE basato su browser contro il vostro provider di identità e ricevono un bearer token di breve durata.
Gli account di servizio (chiamanti macchina come una pipeline CI che registra una Release) utilizzano un client OAuth2 confidenziale e scambiano un client secret per ottenere un token.
I ruoli governano ciò che un principal può fare. Ad esempio, un ruolo di revisore può agire sul Decision Desk, mentre un ruolo di approvatore può risolvere un'Escalation in pausa.

Ogni richiesta API presenta entrambi gli header:

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

💡 Tip

Per l'emissione dei token, la registrazione dei client e la scelta tra PKCE e account di servizio, consultate la guida [Autenticazione](/docs/getting-started/authentication).

Audit a prova di manomissione

La pipeline delle prove è ciò che permette a un revisore di fidarsi di un record la cui creazione non ha osservato personalmente.

flowchart LR
  A["Azione dell'agente"] --> B["Span OpenTelemetry"]
  B --> C["KLA Collector"]
  C -->|"Oscuramento dei PII"| D["Registro ImmuDB"]
  D -->|"Merkle proof"| E["Sealed Evidence Bundle"]

Gli span vengono sottoposti a hash e registrati su ImmuDB, un registro crittografico ad accodamento (append-only). I record non possono essere eliminati, modificati o riordinati a posteriori. Ogni batch pubblica un hash radice Merkle, e qualsiasi auditor può ricalcolare gli hash a partire da un Sealed Evidence Bundle per confermare che la cronologia non sia stata manomessa. È questo ciò che intendiamo per verifica indipendente: non dovete fidarvi della parola di KLA, potete verificare la matematica.

Confine di fiducia

Il diagramma seguente mostra dove si trovano i vostri dati, dove KLA applica i controlli e cosa attraversa ciascun confine.

flowchart TD
  subgraph Customer["Ambiente del cliente"]
    AG["Agenti strumentati"]
  end
  subgraph KLA["KLA Control Plane"]
    GATE{"Decisione di policy"}
    COL["Collector e oscuramento"]
    LED["Registro ImmuDB"]
  end
  AG -->|"Span mTLS"| COL
  AG -->|"Decision Request"| GATE
  GATE -->|"require_approval"| DESK["Decision Desk"]
  COL --> LED
  LED --> ROOM["Evidence Room"]

La policy viene valutata in-process secondo il pattern Govern in Place, così che un esito block o require_approval blocchi l'azione prima che venga eseguita. Solo le prove oscurate e firmate attraversano il confine verso lo storage a lungo termine.

Control Mapping

L'Evidence Room è il luogo in cui la postura di sicurezza diventa un deliverable di conformità. Il Control Mapping collega i controlli di KLA ai requisiti dei framework rispetto ai quali si effettua la rendicontazione, e un Control Pack è l'esportazione che consegnate a un auditor. La tabella seguente mappa una capacità di KLA su ciò che essa offre a un revisore.

Capacità di KLA	Cosa ottiene un revisore
Esecuzione regolata da policy (allow, warn, require_approval, block)	Prova che le azioni rischiose sono state applicate o sottoposte a escalation, soddisfacendo i requisiti dell'Allegato IV dell'EU AI Act relativi alla registrazione della supervisione umana e dei controlli sul rischio.
Escalation del Decision Desk	Un record firmato di ogni approvazione umana, che include chi ha approvato, quando e in quale contesto.
Lineage Records + ImmuDB	Un audit trail a prova di manomissione che dimostra i controlli SOC 2 Type II di logging, integrità e gestione delle modifiche.
Oscuramento dei PII + isolamento dei tenant	Prova dei controlli di minimizzazione e segregazione dei dati per le revisioni di privacy e riservatezza.
Sealed Evidence Bundles	Un'esportazione auto-verificabile con Merkle proof, che elimina la necessità di fidarsi dello storage del fornitore.

🛡️ Important

Un **Control Pack** viene generato a partire dalle prove sigillate, non riassemblato a mano. L'artefatto che inviate è lo stesso dato che è stato ancorato a runtime, così che ciò che attestate e ciò che è realmente accaduto non possano divergere.