KLA Digital Logo
KLA Digital
SDK e API

Riferimento API

Riferimento REST per la KLA Control Plane API: registra gli agenti, valuta le decisioni di policy e recupera le prove crittografiche di audit.

4 min di lettura888 parole

KLA Control Plane espone una REST API per governare in loco gli agenti AI aziendali. Usala per registrare gli agenti che già esegui, valutare una decisione di policy prima che un'azione venga eseguita e recuperare la prova crittografica che un'esecuzione sia stata registrata nel registro a prova di manomissione. Questa pagina documenta i tre endpoint principali, oltre ad autenticazione, gestione degli errori e header operativi. KLA Control Plane è il livello di sicurezza, audit e governance a runtime che affianca i tuoi agenti esistenti invece di sostituirli.

Tutte le richieste sono delimitate per tenant e usano JSON su HTTPS. L'URL di base è:

https://api.kla.digital/v1

Autenticazione

Ogni richiesta deve includere un token bearer e un identificatore di tenant. Il token è un access token OAuth 2.0 di breve durata; l'header del tenant delimita la richiesta alla tua organizzazione. Consulta il documento Autenticazione per sapere come generare i token (accesso browser PKCE per gli utenti, oppure un client secret di un service account per l'accesso programmatico).

Header Obbligatorio Esempio
Authorization Bearer eyJhbGciOi...
x-tenant-id acme-prod
Content-Type In scrittura application/json
curl https://api.kla.digital/v1/agents \
  -H "Authorization: Bearer $KLA_ACCESS_TOKEN" \
  -H "x-tenant-id: acme-prod" \
  -H "Content-Type: application/json"
🛡️ Important
I token hanno una durata breve. Rinnovali prima della scadenza; un token scaduto restituisce `401`. Non incorporare mai segreti a lunga durata nel codice lato client.

Registrare un agente

Dichiara un agente affinché KLA possa tracciarne identità, proprietà e versione nell'Agent Registry. La registrazione restituisce un agentId stabile e un hash firmato del manifest che puoi referenziare da span e decisioni di policy.

  • Endpoint: POST /agents

Corpo della richiesta

{
  "name": "claims-triage",
  "description": "Triages inbound insurance claims",
  "model": "gpt-4.1",
  "temperature": 0.2,
  "tools": ["lookup_policy", "flag_for_review"]
}

Risposta: 201 Created

{
  "agentId": "agt_9f81a7",
  "manifestHash": "sha256:d8a29fbc81d293...",
  "registeredAt": "2026-06-01T10:48:00Z"
}

Valutare una decisione di policy

Invia un'azione di un agente e il relativo contesto al motore di policy. KLA valuta le tue policy pubblicate (YAML dichiarativo compilato in policy pack firmati) e restituisce uno tra quattro esiti, in ordine di precedenza: allow, warn, require_approval, block. Una decisione require_approval mette in pausa l'esecuzione e instrada un'Escalation al Decision Desk per la revisione umana, condizione che la risposta segnala con requiresDeskApproval: true.

  • Endpoint: POST /decisions.evaluate

Corpo della richiesta

{
  "agentId": "agt_9f81a7",
  "action": "execute_refund",
  "context": {
    "amount": 1250.00,
    "user_id": "usr_22"
  }
}

Risposta: 200 OK

{
  "decision": "require_approval",
  "reasonCodes": ["AMOUNT_OVER_THRESHOLD"],
  "requiresDeskApproval": true,
  "decisionId": "dec_8f29e12"
}
Campo Tipo Significato
decision string Uno tra allow, warn, require_approval, block.
reasonCodes string[] Codici stabili leggibili dalla macchina che spiegano l'esito.
requiresDeskApproval boolean true solo per require_approval; il chiamante deve mettere in pausa e attendere una risoluzione del Decision Desk.
decisionId string Identificatore di questa Decision Request, usato per correlare l'eventuale approvazione.
💡 Tip
Tratta `block` come fail-closed: non eseguire l'azione. Tratta `warn` come consentito-con-segnalazione: esegui, ma la decisione viene registrata per la revisione di assurance.

Recuperare una prova di audit

Verifica che un'esecuzione sia stata ancorata nel registro crittografico. KLA registra gli span OpenTelemetry, oscura i dati personali (PII) e li scrive in modo permanente in un registro append-only che produce Merkle proof. Questo endpoint restituisce la prova per un determinato Lineage Record (trace), permettendoti di confermare in autonomia che il record non sia stato alterato.

  • Endpoint: GET /lineage/{lineageId}/verify

Risposta: 200 OK

{
  "lineageId": "lr_99a1287fbc",
  "anchored": true,
  "ledgerIndex": 128994,
  "rootHash": "sha256:9f8d2e8ab219d...",
  "merklePath": [
    "sha256:bc892a76f...",
    "sha256:e829dc76a..."
  ]
}

Ricalcola la root a partire dall'hash della foglia e da merklePath, quindi confrontala con rootHash per verificare l'integrità senza fidarti di KLA. Queste prove sono alla base di ogni Sealed Evidence Bundle esportato dall'Evidence Room.

Errori e codici di stato

Gli errori restituiscono un corpo JSON con code e message. Usa lo stato HTTP per decidere il comportamento di retry.

Stato Codice Quando si verifica
400 invalid_request JSON malformato o validazione di schema fallita.
401 unauthorized Token bearer mancante, scaduto o non valido.
403 forbidden Token valido ma privo dei permessi per questo tenant o questa azione.
404 not_found agentId, lineageId o route sconosciuti.
409 conflict Riutilizzo di una chiave di idempotenza con un payload diverso, oppure una registrazione duplicata.
429 rate_limited Limite di frequenza superato; rispetta l'header Retry-After.
5xx internal_error Guasto transitorio del server; riprova con backoff.
{
  "code": "invalid_request",
  "message": "field 'amount' must be a number"
}

Limiti di frequenza e idempotenza

Le richieste sono soggette a un limite di frequenza per tenant; in caso di 429, applica un backoff e riprova dopo il valore di Retry-After. Per le chiamate in scrittura (POST /agents, POST /decisions.evaluate), invia un header Idempotency-Key con un valore univoco per rendere sicuri i retry. Riproporre la stessa chiave restituisce il risultato originale invece di creare un duplicato.

Riferimento API | Developer Docs | KLA Control Plane