Vai al contenuto principale
Una chiave è comparsa in un commit pubblico, in un log di CI, in uno screenshot o in una violazione di un vendor. L’orologio scorre: chiunque possieda quella stringa sk-orca-… può spendere il tuo saldo e guidare i tuoi agent finché non la tagli fuori. Questa pagina è il runbook dell’incidente — taglia prima la credenziale, poi fai l’audit di cosa ha fatto — per i clienti che gestiscono le proprie chiavi nella console. I meccanismi del ciclo di vita (disable vs. delete, stati delle chiavi, ruoli) vivono in Gestire le chiavi; questa pagina è la sequenza sotto-attacco e, soprattutto, cosa controllare nella traccia di audit una volta fermata l’emorragia.
Ferma la spesa prima di indagare. Una chiave con scope, con un cap credit_limit_usd e un elenco allow_ips, vincola il danno, ma una chiave trapelata senza cap può bruciare saldo per tutto il tempo che resta viva. Revoca prima; forensics dopo.

​
1. Revoca la chiave API trapelata (fai questo per primo)

Hai due mosse di taglio, entrambe nella schermata Chiavi della console (/console/token). Entrambe richiedono il ruolo Developer o superiore — l’azione gira sul tuo token di sessione / accesso, mai su una chiave di relay.

Disable — pausa reversibile

Porta lo stato della chiave a Disabled. Ogni richiesta che fa viene rifiutata immediatamente, ma la chiave, i suoi limiti, i suoi collegamenti a policy e la sua cronologia d’uso restano tutti intatti. Usa questo quando ti serve conservare la config e i log mentre indaghi.

Delete — revoca permanente

Scegli Elimina sulla chiave. La credenziale non può mai più autorizzare una richiesta e non è recuperabile. Usa questo una volta che il leak è confermato e hai catturato ciò che ti serve dalla traccia.
Un pattern comune: disabilita all’istante nel momento in cui sospetti l’esposizione (contenimento a latenza zero, nulla perso), esegui l’audit nei §3–§4, poi elimina una volta delimitato il raggio d’esplosione. Qualunque cosa tu faccia, emetti una chiave nuova per la sostituzione — mai riabilitare una credenziale che è stata vista in giro. Il passaggio di consegne zero-downtime è in Rotazione delle chiavi.
Disabilitare o eliminare ha effetto alla richiesta successiva — non c’è redeploy né ritardo di propagazione.

​
2. Già che ci sei, stringi la sostituzione

Un leak è il momento per sistemare lo scope che gli ha permesso di fare male. La chiave sostitutiva dovrebbe portare l’identità più ristretta di cui il workload ha effettivamente bisogno, così che il prossimo leak sia un non-evento:
Un’IP allow-list significa che una chiave trapelata è inutile da qualunque indirizzo che non sia il tuo. Le richieste da IP non elencati vengono rifiutate al livello di autenticazione prima che costino qualcosa.
Un cap di spesa (0 = illimitata) vincola il caso peggiore. Una chiave trapelata con un tetto settimanale stretto non può prosciugare il saldo del tuo workspace.
I limiti sui modelli impediscono a un ladro di spostare la tua chiave economica sul tuo modello più costoso.
Una scadenza (-1 = mai) significa che una chiave che sfugge alla tua attenzione smette comunque di autorizzare da sola.
Vedi la Checklist di minima agenzia per la postura completa una-chiave-per-agent.

​
3. Audit dei request log — cosa ha chiamato la chiave?

Con la credenziale tagliata, delimita il danno. Ogni chiamata di relay che quella chiave ha fatto è registrata nei request log del tuo workspace, e ogni riga porta i campi che ti servono per ricostruire l’incidente:
CampoCosa ti dice
token_name / token_idQuale chiave — conferma che stai guardando quella trapelata.
ipL’indirizzo sorgente di ogni chiamata. Una raffica da un IP che non riconosci è la prova schiacciante.
modello + usoQuali modelli sono stati colpiti e quanto sono costati — la tua esposizione di spesa.
Filtra la vista dei log alla chiave trapelata e ordina per tempo. Due domande rispondono al “quanto è grave” nel modo più rapido:
  1. C’è traffico da un IP che non è tuo? È un abuso confermato, non un falso allarme.
  2. La spesa o il pattern di chiamate ha avuto un picco attorno alla finestra del leak? Un salto improvviso è l’impronta dell’attaccante.
Se la chiave portava un elenco allow_ips, le chiamate da fuori non hanno mai autorizzato in primo luogo — quindi l’assenza di righe da IP esterni è di per sé un certificato di buona salute. È esattamente per questo che fissare la sorgente (§2) trasforma un leak in un non-evento.

​
4. Leggi la traccia delle policy — cosa ha provato a fare?

I request log ti dicono cosa la chiave ha chiamato; i piani di policy ti dicono cosa ha provato a far dire o fare al modello, e se i tuoi guardrail e il tuo firewall l’hanno catturato. Entrambi hanno scope a livello di workspace. I match dei guardrail sono leggibili da qualsiasi membro del workspace; la vista Events / Runs del firewall richiede il ruolo Developer o superiore (le policy e le impostazioni del firewall restano aperte a ogni membro).

Match dei guardrail

Ogni volta che il traffico della chiave ha colpito una regola di guardrail, è atterrato un record di match a GET /api/guardrail/match — che porta il tipo di regola, action (block / mask / flag), stage e il dettaglio incriminato. Filtra alla finestra della chiave trapelata per vedere quali contenuti ha spinto attraverso (PII, segreti, tentativi di jailbreak).

Eventi del firewall

Ogni chiamata a tool che la chiave ha emesso è un evento del firewall — allow, audit, deny, sanitize, o held. Una sequenza di eventi deny è un agent che ha provato qualcosa che non gli era permesso. Aggregali per esecuzione nella vista Events / Runs.
Alcuni dettagli che vale la pena conoscere mentre leggi la traccia:
  • I match dei guardrail loggano la sottostringa corrispondente solo se “Log raw content” era attivo per quel guardrail (è disattivato per default) — quindi una riga di match può mostrare la regola e l’azione senza il testo grezzo. Il tipo / l’azione / lo stage ci sono sempre.
  • mark-fp su un match (POST /api/guardrail/match/:id/mark-fp, Admin) ti permette di segnalare un hit come falso positivo così che smetta di distorcere la tua vista dell’incidente — non usarlo per seppellire un abuso reale.
  • I deny del firewall sono pre-tool. Un evento deny significa che la chiamata a tool dell’attaccante è stata bloccata prima di raggiungere il tool — il firewall ha già contenuto quell’azione. L’evento è la tua prova che ci ha provato.
Incrocia le tre tracce sulla stessa finestra temporale: un IP esterno nei request log, un picco di match dei guardrail e un cluster di eventi deny del firewall insieme dipingono il quadro completo — cosa l’attaccante aveva, cosa ha tentato, e cosa è stato fermato.

​
5. Dopo l’incidente

Ricontrolla l’elenco Chiavi: la chiave trapelata dovrebbe leggere Disabled o essere sparita del tutto. Se l’hai solo disabilitata, programma l’eliminazione una volta finito l’audit — vedi Gestire le chiavi.
Sposta il traffico sulla nuova chiave con scope più stretto prima di ritirare quella vecchia così che non ci sia mai un gap senza-chiave-funzionante. Passaggio di consegne completo: Rotazione delle chiavi.
Se la chiave trapelata non aveva allow_ips, non aveva credit_limit_usd e aveva model_limits ampi, quella è la vera scoperta. Dai a ogni agent la propria chiave con scope ristretto — la Checklist di minima agenzia e Scope e chiavi percorrono l’intera postura.

​
6. Correlati

Gestire le chiavi

Disable vs. delete, stati delle chiavi, e i role gate dietro ogni azione.

Rotazione delle chiavi

Il passaggio di consegne zero-downtime da una chiave compromessa a una pulita.

IP allow-list

Fissa una chiave ai tuoi indirizzi sorgente così che un leak non possa essere usato altrove.

Esfiltrazione di dati

La minaccia che una chiave trapelata alimenta più spesso, e come la superficie di egress del firewall la vincola.
L’intera sequenza è breve di proposito: revoca, poi audit. Più ristretto è lo scope di ciascuna chiave in partenza, più piccolo è l’audit che devi eseguire — e più rapidamente una credenziale trapelata passa da emergenza a nota a piè di pagina.