Protezioni e sicurezza degli agenti IA in Jira
Le protezioni ti permettono di adottare l'IA su larga scala creando fiducia nei flussi di lavoro agentici. Quelle che funzionano sono integrate nei tuoi flussi di lavoro, quindi il sistema le applica invece di affidarsi all'agente.
In Jira, quel sistema è quello in cui il tuo team gestisce già i ticket. Jira concede a un agente l'accesso previsto tramite autorizzazioni, punti di controllo in cui le persone applicano il proprio giudizio alle transizioni del flusso di lavoro e una registrazione di ogni azione dell'agente sul ticket. Il Teamwork Graph fornisce all'agente il contesto giusto per agire.
Questa guida descrive i rischi affrontati dalle protezioni degli agenti e come applicarle in Jira, così da poter ampliare l'utilizzo dell'IA in modo sicuro e responsabile, dando agli agenti maggiore autonomia nelle attività del tuo team, dai task di routine necessari per la continuità operativa ai progetti di maggior valore, senza perdere il controllo. L'autonomia, in dimensioni di questo livello, si basa su quattro protezioni che puoi impostare in Jira, utilizzando i flussi di lavoro, le autorizzazioni e le regole che il tuo team già utilizza:
Definisci l'ambito dell'accesso. Stabilisci quali dati può ottenere un agente, gli strumenti che può utilizzare e dove può agire, tramite le autorizzazioni Jira esistenti.
Blocca le chiamate rischiose. Utilizza le transizioni del flusso di lavoro per richiedere l'approvazione umana prima che i ticket ad alto impatto vengano implementati.
Rivedi l'output. Verifica cosa ha prodotto l'agente durante la normale revisione della richiesta pull prima del rilascio.
Conserva il record. Ogni azione dell'agente finisce nella cronologia del ticket, associata a chi l'ha approvata.
Che cosa sono le protezioni nell'ingegneria agentica?
Le protezioni dell'agente sono i controlli che mantengono il ticket di un agente IA sicuro, conforme a quanto previsto e tracciato: a cosa può accedere, i punti di controllo in cui interviene una persona e il registro di ciò che ha fatto. Una protezione viene applicata dal sistema in cui lavora l'agente, non lasciata alla discrezione dell'agente.
Non puoi rendere sicuro un agente limitandoti a istruirlo su come comportarsi, perché le istruzioni possono essere dimenticate, fraintese o ignorate. Una vera protezione si trova al di sopra dell'agente, nel suo ambiente, dove il confine resta valido indipendentemente da ciò che viene detto all'agente. È lo stesso principio su cui si basa già il tuo team: è il sistema a decidere che cosa è possibile, non la singola persona a cui viene chiesto di seguire le regole.
In pratica, i controlli dell'agente interessano alcune aree correlate tra loro:
Accesso e ambito. I dati a cui un agente può accedere, gli strumenti che può usare e l'area in cui può agire.
Task delimitati. I task che un agente può gestire direttamente e quelli che, invece, spettano a una persona.
Approvazione con intervento umano. I checkpoint in cui qualcuno rivede o approva il lavoro prima che passi alla fase successiva.
Revisione dell'output. La convalida di ciò è stato prodotto dall'agente prima che venga distribuito.
Responsabilità e audit. Un record di ciò che l'agente ha fatto, del perché e di chi ha dato l'approvazione.
Governance. I controlli permanenti che garantiscono la coerenza man mano che l'uso dell'agente si espande.
Insieme, questi elementi creano fiducia nei flussi di lavoro agentici e consentono a un team di affidare maggiori responsabilità agli agenti senza rinunciare al controllo, perché una persona resta responsabile del risultato.
Perché gli agenti IA hanno bisogno di controlli?
Gli agenti, per definizione, agiscono. A differenza dei chatbot che si limitano a dare consigli, possono modificare il codice, trasferire i ticket e innescare azioni concrete all'interno degli strumenti. Questa autonomia è allo stesso tempo ciò che li rende utili e il motivo per cui richiedono controlli: più cose un agente può fare da solo, più è importante che il suo lavoro sia sempre allineato, verificato e tracciabile.
Vediamo ora i principali rischi che i controlli affrontano e i casi in cui il giudizio umano resta imprescindibile.
Disallineamento: l'agente ottimizza in base all'elemento sbagliato o si allontana dal task.
Output di bassa qualità o errato: un lavoro che sembra finito ma non è pertinente, ad esempio codice o fatti che presentano allucinazioni.
Accesso troppo esteso: l'agente può usare dati o sistemi a cui non dovrebbe accedere.
Azioni irreversibili non verificate: modifiche ad alto impatto che non si possono annullare facilmente, come il passaggio all'ambiente di produzione o l'eliminazione di dati, che richiedono il controllo umano prima dell'applicazione.
Assenza di responsabilità o visibilità: senza un record, nessuno può vedere cosa ha fatto l'agente o chi l'ha approvato.
Costi incontrollati: gli agenti possono consumare token e capacità di calcolo in modo imprevedibile, quindi la spesa deve essere limitata come qualsiasi altra risorsa.
I controlli funzionano solo se è il sistema ad applicarli, non l'agente. Dire a un agente cosa non deve fare non è un controllo, perché l'agente può continuare a eseguire l'azione nonostante le istruzioni, senza che tu lo sappia. I veri controlli si trovano al di sopra dell'agente, nell'ambiente in cui opera, in modo che l'azione indesiderata sia impossibile da eseguire e non solo scoraggiata.
Ecco perché i controlli sono la condizione preliminare, anziché un freno, per l'autonomia. I team che si fidano dei limiti possono assegnare agli agenti maggiori responsabilità con meno supervisione diretta. I team che, invece, non possono fidarsi perderanno la velocità per cui hanno adottato gli agenti.
Come si gestiscono in modo sicuro gli agenti IA in Jira?
Se un controllo deve trovarsi sopra l'agente nel sistema in cui viene eseguito, allora è quel sistema a essere importante, e per le operazioni di ingegneria si tratta di Jira. Quando operano all'interno del System of Work Atlassian, gli agenti accedono ai dati e ai ticket attraverso le stesse autorizzazioni di Jira usate dal tuo team, oltre che ai flussi di lavoro esistenti e all'audit trail. Ciò che un agente può eseguire nel proprio ambiente viene sempre disciplinato dall'agente stesso, quindi Jira controlla l'accesso al lavoro, mentre le autorizzazioni a livello di agente regolano gli strumenti che può eseguire.
Di per sé, un agente di codifica gestisce solo le proprie azioni. Jira gestisce i ticket, quindi i controlli si applicano in un unico ambiente a ogni agente e puoi vedere quale rischio affronta ciascuno di loro.
I flussi di lavoro sono l'area in cui viene applicata la maggior parte dei controlli. Gli stati, le transizioni e le regole che indirizzano i ticket tra le persone li instradano anche agli agenti, decidono quali transizioni un agente può eseguire e trattengono le modifiche ad alto impatto in attesa dell'approvazione.
Accesso: cosa puoi controllare in Jira
Il primo controllo è l'ambito: con quali dati, strumenti e progetti può lavorare un agente. Questa è la misura di protezione contro un accesso troppo esteso. In Jira, si imposta così come per qualsiasi collega del team, quindi è un controllo familiare e adattabile alle esigenze personali.
Come funziona in Jira: sei tu a scegliere l'identità con cui un agente lavora. Per impostazione predefinita, l'agente opera per conto della persona che lo usa e quindi ha accesso agli stessi dati, progetti e ticket di quella persona. Puoi anche assegnare all'agente un proprio account con le relative autorizzazioni, in modo che il suo accesso non dipenda da una singola persona. Gli amministratori controllano quali agenti sono attivi e dove operano. Ciò che un agente può fare con i propri strumenti è stabilito dall'agente stesso, non da Jira. Mantieni un accesso ampio o limita rigorosamente l'ambito ed estendilo man mano che la fiducia si rafforza.
I controlli che regoli. Corrispondono ai meccanismi di autorizzazione che usi già per le persone: gli schemi autorizzazione e i ruoli di progetto definiscono cosa può fare un agente in un progetto, mentre la sicurezza dei ticket limita quali ticket specifici può vedere. Se rafforzi uno dei controlli, il raggio d'azione dell'agente si restringe senza bisogno di un sistema specifico per l'agente.
Concedi l'accesso a ciò che occorre per il task. La maggior parte degli agenti funziona meglio con un certo margine di movimento, quindi definisci l'ambito del task. Per i sistemi molto sensibili, applica limiti specifici.
Come si controlla ciò che gli agenti fanno nel flusso di lavoro?
Il secondo controllo è il flusso di lavoro: le regole che decidono quando un agente viene eseguito, cosa può fare in autonomia e quali decisioni spettano a una persona. È la tua difesa contro il disallineamento e le azioni irreversibili. Queste regole vengono impostate nelle transizioni che il tuo team già usa, in modo che la supervisione non consista in un unico passaggio finale.
Una condizione di transizione limita le fasi in cui un agente può agire, un componente di convalida blocca i ticket che non sono pronti e un passaggio di approvazione trattiene le modifiche ad alto impatto per sottoporle a una persona. L'approvazione umana è solo una delle regole disponibili e il compito è abbinare ogni regola al rischio.
Come si configura in Jira: apri il flusso di lavoro relativo al tipo di ticket e aggiungi un agente a una transizione, ad esempio quando il lavoro passa a "In revisione", così che l'agente venga eseguito quando un ticket raggiunge la fase indicata. L'aggiunta di un agente determina quando viene eseguito, non se una persona lo approva. L'approvazione umana è un controllo separato: un passaggio di approvazione del flusso di lavoro regola la transizione e puoi abbinarlo alle istruzioni dell'agente relative a quando interrompere e chiedere oppure a una regola di automazione. Una transizione è uno dei vari punti di accesso. Un agente può anche avviarsi quando:
Un ticket viene creato, in modo che venga sottoposto a valutazione non appena arriva
Un'etichetta o un campo cambia oppure in base a una programmazione, attraverso una regola di automazione
Viene eseguito in background per aggiornamenti di routine come la creazione di una bozza delle note di rilascio.
Abbina il controllo al rischio. Lascia che i ticket a basso rischio (aggiornamento di una dipendenza) vengano eseguiti in autonomia, invia una notifica a una persona per i ticket a medio rischio (modifica a una configurazione condivisa) e richiedi l'approvazione per le azioni ad alto rischio o irreversibili (interventi sulla produzione o eliminazione di dati).
Decidi di quali task è responsabile l'agente. La definizione delle responsabilità di un agente viene prima della configurazione di un checkpoint. Permetti a un agente di occuparsi dei ticket a basso rischio e di preparare i ticket a impatto maggiore perché vengano completati da una persona e lascia che le richieste più delicate vengano gestite da un collega umano. La definizione dei limiti del task è la prima decisione, il checkpoint è il modo in cui la applichi.
Assegna agli agenti istruzioni proprie. Definisci come un agente deve comportarsi e portare avanti i ticket, tra cui le decisioni che può prendere autonomamente e quando deve fermarsi e chiedere, in modo che segua le convenzioni del tuo team anziché impostazioni predefinite generiche.
Rivedi l'output: come si convalida il lavoro prodotto dall'agente?
Il terzo controllo è la revisione del prodotto stesso, in cui una persona intercetta output di bassa qualità e allucinazioni prima che arrivino a destinazione. Per un agente di codifica, si tratta della richiesta pull che apre.
In Jira: considera l'output dell'agente non attendibile finché non viene verificato da una persona o dai controlli in atto, con lo stesso livello di attenzione che riserveresti al codice di un nuovo collaboratore. Il lavoro dell'agente rimanda al ticket e le modifiche al codice arrivano sotto forma di richiesta pull che segue il normale processo di revisione e unione. Niente di ciò che un agente produce salta la fase di revisione già applicata dal team.
Visualizza il lavoro alla base dell'output. Non si vede solo il risultato finale. Sessioni dell'agente in Jira offre un unico ambiente in cui vedere cosa ha fatto un agente e perché, così un revisore dispone del contesto necessario per comprendere l'output anziché doverlo ricostruire.
Didascalia: Esempio: definisci gli standard di revisione del codice IA in Bitbucket Cloud e applicali in automatico a ogni richiesta pull.
Mantieni un record tracciabile: chi ha fatto cosa? Quando?
Il quarto controllo è il record, la risposta alla responsabilità. Ricollega il lavoro dell'agente alle intenzioni: cosa ha fatto l'agente, perché, quale ticket ha supportato e chi lo ha approvato. Questo collegamento consente di individuare e risolvere facilmente i problemi quando si verifica un errore.
In Jira: ogni agente viene eseguito con un'identità nota, cioè quella della persona che ha assegnato il task o lo ha configurato, operando con le autorizzazioni di quella persona o con il proprio account di agente con le autorizzazioni da te assegnate. In ogni caso, il record associa ogni azione a un'identità responsabile e registra ciò che l'agente ha fatto e chi ne è responsabile, nella cronologia del ticket insieme all'attività umana, con le approvazioni associate al revisore che ha dato l'approvazione. Gli amministratori possono inoltre monitorare gli audit log per individuare attività insolite.
Inserisci il lavoro dell'agente locale nel record. Il monitoraggio delle sessioni degli agenti trasferisce l'attività dagli agenti di codifica IA locali agli IDE o ai terminali locali, collegati al ticket, così il lavoro svolto fuori da Jira confluisce comunque in un unico record tracciabile. Mettiti in lista d'attesa.
Quali sono le best practice per i controlli degli agenti?
Abbina l'accesso di un agente al suo task e amplialo man mano che la fiducia aumenta (gli agenti usano le autorizzazioni Jira esistenti).
Fornisci agli agenti istruzioni chiare su come agire e quando interrompersi per chiedere.
Fai partire gli agenti con il lavoro a basso rischio e reversibile e poi passa ai task ad alto impatto.
Coinvolgi una persona nelle decisioni che contano, con controlli in più momenti, non solo un'approvazione finale.
Esamina l'output dell'agente come faresti per l'output umano (revisione e merge della richiesta pull).
Mantieni una registrazione di ogni azione dell'agente, collegata al ticket (cronologia e audit log).
Fornisci agli agenti il contesto per monitorare i costi, dal momento che le spese fuori controllo sono causate dalla necessità di fare supposizioni e ripetere il lavoro.
Atlassian ha rilevato che l'IA basata su Teamwork Graph ha migliorato la qualità delle risposte del 44% riducendo al contempo il consumo di token del 48%.
Quali controlli copre Jira? Quali, invece, si trovano altrove?
I controlli operano a diversi livelli dello stack di agenti. Jira gestisce il livello di lavoro e accesso, gli altri livelli, invece, sono responsabilità del fornitore del modello, del framework dell'agente e della CI.
Controlli applicati da Jira | Controlli gestiti altrove nello stack |
Limita l'accesso dell'agente tramite le autorizzazioni e la configurazione del progetto di Jira | Filtra o modera l'output del modello (lo fa il provider del modello) |
Subordina il lavoro all'approvazione umana in una transizione del flusso di lavoro | Esegui il modello o il runtime di esecuzione dell'agente (Jira Coding Agent viene eseguito in una sandbox fornita da Atlassian, gli agenti di terze parti nel proprio framework) |
Registra le azioni dell'agente nella cronologia del ticket e negli audit log dell'amministratore | Blocca tutte le prompt injection (il filtraggio è utile ma niente riesce a intercettarle tutte, Jira limita i danni nel caso in cui una eludesse il blocco). |
Imposta l'esecuzione autonoma o con approvazione per task | Applica controlli a livello di codice, come test e scansioni di sicurezza (lo fa la pipeline CI) |
Jira stabilisce cosa possono fare gli agenti e registra quali operazioni hanno completato; integra la sicurezza a livello di modello e di runtime, non la sostituisce.
Come aggiungere il primo controllo dell'agente in Jira
Per iniziare, non c'è bisogno di un programma di governance completo. Un controllo ti permette di affidare lavoro reale a un agente in modo responsabile, con una persona coinvolta nelle decisioni che contano, e ampliare la portata man mano che la fiducia aumenta.
Scegli un task di routine e reversibile, come un test instabile o un intoppo in una dipendenza (limita il costo di un errore).
Esegui l'agente con l'accesso che concederesti a un nuovo collega del team, non superiore a quello richiesto dal task.
Aggiungilo a una transizione del flusso di lavoro, in modo che la prima approvazione sia di una persona (intercetta azioni non allineate o rischiose).
Esamina la richiesta pull seguendo il processo normale (intercetta gli output di bassa qualità o le allucinazioni).
Verifica che sia registrato nel ticket (per garantire tracciabilità nel caso in cui occorra tornare indietro).
Ecco come creare il flusso di lavoro per adattare l'IA in modo responsabile: migliore output dell'agente, meno tempo dedicato alla revisione e più autonomia, che puoi ampliare in sicurezza da qui.
Dai un'occhiata alla nostra guida pratica a una governance responsabile dell'IA, che fa parte dei Principi di tecnologia responsabile di Atlassian.
Domande frequenti sui controlli degli agenti IA
Come è possibile tenere al sicuro gli agenti IA?
Per tenere al sicuro gli agenti IA, occorre controllare a cosa possono accedere, richiedere l'approvazione umana per le azioni ad alto impatto e registrare tutto ciò che fanno, con un livello di supervisione commisurato al rischio di ogni task.
In che modo Jira gestisce gli agenti IA?
Jira gestisce gli agenti IA tramite i controlli che il tuo team impiega già: gli agenti operano all'interno delle autorizzazioni e dei flussi di lavoro di Jira, puoi sottoporli all'approvazione umana in una transizione del flusso di lavoro e le loro azioni vengono registrate nella cronologia del ticket e nell'audit log.
Gli agenti IA in Jira possono richiedere l'approvazione umana?
Sì. Puoi aggiungere un agente a una transizione del flusso di lavoro in modo che una persona ne esamini e approvi l'output prima che il lavoro proceda, e riservare l'autonomia ai task reversibili e a basso rischio.
Cos'è la prompt injection con gli agenti IA?
La prompt injection è un input non attendibile che cerca di indirizzare un agente verso azioni non intenzionali. Atlassian filtra l'input per gli agenti basati su Rovo per individuare i tentativi di injection e, poiché nessun filtro è completo, i controlli stratificati restringono il resto: accesso limitato, approvazione umana e audit trail completo.