Limita l'autorità di un agente

Descrivi il compito prima di concedere accesso

Un agente che legge codice ha bisogno di un’autorità diversa da un agente che distribuisce un servizio. Non concedere entrambi gli insiemi di permessi solo perché lo stesso prodotto gestisce entrambe le azioni.

Definisci l’autorità con tre parti: un’azione, una risorsa e una condizione. Per una correzione fittizia di un report, l’agente può scrivere su un feature branch mentre il compito è attivo. Può leggere i file approvati del repository. Non può modificare dati di produzione o regole di protezione del repository.

L’applicazione precisa del limite dipende dallo strumento. Se un token non può esprimere una restrizione al branch, usa ulteriori controlli del repository o un servizio di esecuzione. Documenta con chiarezza l’autorità residua.

Applica il limite fuori dal modello

Un prompt non è un sistema di controllo degli accessi. Il componente di esecuzione deve verificare azione richiesta e destinazione rispetto ai permessi attuali. Non deve accettare l’affermazione del modello secondo cui l’approvazione esiste già.

AWS raccomanda permessi limitati e credenziali temporanee per i carichi di lavoro appropriati. OWASP applica un ragionamento simile sul privilegio minimo agli agenti e ai loro strumenti. Questi principi devono essere implementati nei sistemi effettivi di identità ed esecuzione. Indicazioni AWS IAM, Indicazioni OWASP sugli agenti.

Usa credenziali di breve durata dove disponibili. Escludi dall’ambiente i segreti non pertinenti. Un compito di sola lettura sul repository non deve ereditare una password del database di produzione dalla shell dello sviluppatore.

Vincola l’approvazione all’azione effettiva

L’approvazione a preparare una modifica non implica l’approvazione a distribuirla. Una decisione di deployment deve identificare artefatto, ambiente di destinazione e condizioni pertinenti. Se cambiano, la decisione precedente potrebbe non essere più applicabile.

Considera un agente che propone una lettura sicura del database, poi esegue una query diversa dopo l’approvazione. Un meccanismo utile di approvazione verifica l’operazione realmente eseguita. Un messaggio generico «continua» senza una destinazione definita può nascondere la differenza.

Separa anche identità e capacità. Registra quale persona o carico di lavoro ha avviato l’esecuzione. Verifica che l’identità iniziale abbia ancora il permesso quando avviene l’azione. La rimozione dell’accesso di una persona deve avere un effetto esplicito sul lavoro in coda.

Verifica un rifiuto e un’interruzione

Verifica più del solo percorso riuscito. In un ambiente di test isolato, tenta un’azione fuori dalla risorsa consentita. Conferma che il sistema di esecuzione la rifiuti. Esamina l’evento di audit senza registrare credenziali.

Verifica poi l’annullamento o la scadenza delle credenziali. Stabilisci quale lavoro si ferma subito e quale operazione può terminare. Un pulsante di arresto non annulla necessariamente un’azione già arrivata a un altro sistema.

Conserva con il compito una breve registrazione dei permessi. Includi responsabile, ambito approvato, controlli effettivi, test del rifiuto e scadenza. Rende una revisione successiva abbastanza specifica da migliorare il flusso.