Quando il tuo agente si comporta male, sai quale lo ha fatto?
Un agente elimina un record che non dovrebbe toccare. Invia un messaggio al tenant sbagliato. Chiama un'API in un loop e fa schizzare alle stelle la tua bolletta.
Dieci minuti dopo l'inizio di un incidente, ti poni una sola domanda: quale agente lo ha fatto?
Se non lo sai, non puoi risolvere il problema. Non puoi fermare la build. Non puoi sottoporre l'errore ad audit. Non puoi imparare dall'errore.
Questo è un problema di identità.
La maggior parte dei team si trova di fronte a tre schemi che nascondono le azioni degli agenti:
- Shared service accounts: dieci agenti utilizzano lo stesso set di credenziali. Ogni azione appare identica nei tuoi log.
- Human credentials: l'agente utilizza il tuo login. I log mostrano il tuo nome, non quello dell'agente. Questo crea un enorme rischio per la sicurezza.
- Silent drift: due build diverse utilizzano lo stesso nome. Una utilizza un nuovo modello o un nuovo prompt, ma i log mostrano la stessa identità.
Per risolvere il problema, segui questi passaggi:
Dai a ogni agente la propria identità. Non utilizzare credenziali umane. Non utilizzare account condivisi. L'agente deve autenticarsi come se stesso.
Inserisci sei campi specifici in ogni azione:
- Accountable party: chi è responsabile di questo agente?
- Operational owner: chi lo gestisce quotidianamente?
- Tenant: per quale cliente è?
- Agent-type-id: di quale build specifica si tratta?
- Agent-instance-id: di quale esecuzione specifica si tratta?
- Trace context: dove si trova questo nella catena di chiamate?
Usa gli hash per il versionamento. Non chiamare il tuo agente "support-agent-v2". Se cambi il system prompt, il nome rimane lo stesso, ma il comportamento cambia. Invece, usa un hash del contenuto. Crea un hash basato sull'immagine del container, sul prompt, sul modello e sulla configurazione. Se cambi una riga di codice, l'ID cambia. Questo rende visibile il silent drift.
Registra la lineage. Gli agenti generano sub-agenti. Devi registrare quale agente genitore ha avviato il sub-agente. Devi anche registrare il prompt che il genitore ha fornito al sub-agente. Questo è l'unico modo per trovare istruzioni iniettate o dati avvelenati (poisoned data).
L'identità è la tua superficie di ripristino. Ti permette di utilizzare un kill switch e di costruire una traccia di audit. Devi impostare tutto questo prima che si verifichi un incidente. Aggiungere l'identità durante una crisi è troppo tardi.
Controlla i tuoi log proprio ora. Guarda un'azione avvenuta un'ora fa. Riesci a indicare la build specifica che ha compiuto quell'azione? Se non ci riesci, hai una lacuna da colmare.
Fonte: https://dev.to/brennhill/when-your-agent-does-something-bad-can-you-tell-which-agent-did-it-37a2
Community di apprendimento opzionale: https://t.me/GyaanSetuAi