Obsidian Security lancia un motore di policy in runtime per controllare le azioni degli agenti IA

Obsidian Security ha lanciato un motore decisionale per le policy in runtime, progettato per consentire alle aziende di controllare le azioni degli agenti IA nelle applicazioni aziendali prima che vengano eseguite. L’annuncio amplia la piattaforma dell’azienda per la sicurezza degli agenti con un proxy di sicurezza MCP, un’API decisionale per le policy e una copertura aggiuntiva per gli strumenti di programmazione e gli agenti integrati in software di terze parti.

Il lancio affronta un problema che i normali controlli di accesso non risolvono del tutto: un agente può disporre di credenziali valide e usare un’applicazione autorizzata, ma tentare comunque di compiere un’azione inappropriata. Per esempio, il permesso di leggere i dati dei clienti non implica necessariamente quello di esportarli verso una destinazione esterna.

L’approccio di Obsidian consiste nel valutare l’azione proposta in base a policy gestite centralmente, considerando la persona che si trova dietro l’agente, il suo rapporto di lavoro e le sue autorizzazioni, l’applicazione coinvolta e le classificazioni dei dati fornite dal cliente. I punti di applicazione dei controlli collegati consentono quindi o bloccano l’azione, oppure richiedono un’approvazione, laddove tale funzionalità sia supportata.

Dalla scoperta degli agenti al controllo delle loro azioni

La scoperta degli agenti permette di sapere quali strumenti sono presenti e a quali risorse possono accedere. La governance può ridurre le autorizzazioni non necessarie o individuare configurazioni rischiose. Le policy in runtime affrontano la questione ancora aperta: cosa dovrebbe essere consentito fare, in quel preciso momento, a un agente altrimenti autorizzato?

L’annuncio di Obsidian riguarda sia gli agenti utilizzati dai dipendenti sia quelli integrati nel software che l’azienda già usa. Le funzionalità ampliate di scoperta e governance comprendono Salesforce Agentforce, Databricks, GitHub, Microsoft 365, Snowflake, ServiceNow e Workday.

Si tratta di punti di controllo diversi. Individuare un agente all’interno di un’applicazione SaaS non significa, di per sé, che ogni azione svolta nell’applicazione venga intercettata. L’applicazione delle policy in runtime dipende dall’integrazione supportata e dal punto attraverso cui passa l’azione.

L’azienda ha inoltre aggiunto il supporto alle policy in runtime per OpenAI Codex, affiancandolo ai controlli già disponibili per gli agenti di programmazione. Nell’annuncio vengono indicati rischi quali comandi distruttivi, esposizione delle credenziali e letture al di fuori dell’ambito previsto per un progetto: azioni che possono verificarsi anche durante una sessione di sviluppo altrimenti legittima.

Il Knowledge Graph fornisce il contesto mancante

Un gateway può esaminare una richiesta, ma la richiesta, da sola, potrebbe non chiarire quali autorizzazioni vi siano dietro. Per prendere una decisione di sicurezza adeguata può essere necessario sapere se l’account che invia la richiesta appartiene a un dipendente o a un collaboratore esterno, se il rapporto di lavoro è terminato e quali autorizzazioni l’account possiede effettivamente nell’applicazione di destinazione.

L’architettura Knowledge Graph di Obsidian collega persone, account, applicazioni, token, diritti di accesso e le relazioni tra questi elementi. L’azienda spiega di normalizzare in un modello comune le informazioni provenienti da API amministrative, flussi di attività e integrazioni, usando entità e relazioni con versioni per registrare i cambiamenti nel tempo.

Questa struttura aiuta a ricostruire i percorsi di accesso attraverso più sistemi, invece di esaminare ogni account isolatamente. Il ruolo apparente di un agente può essere circoscritto, mentre un token o un diritto di accesso ereditato può garantirgli una portata più ampia altrove. Collegare queste relazioni offre al motore di policy basi più solide per stabilire se una determinata azione sia conforme alle regole dell’organizzazione.

I clienti possono aggiungere informazioni contestuali proprie, comprese etichette di classificazione. Una policy può così distinguere un file ordinario da uno che l’azienda considera altamente sensibile, anziché basarsi soltanto sulla definizione generica di dati riservati adottata da un fornitore di sicurezza.

Dalla decisione all’applicazione dei controlli

L’architettura separa la decisione dall’azione. Nella spiegazione del motore in runtime di Obsidian, un punto di applicazione dei controlli sospende l’operazione proposta, ne invia i dettagli per la valutazione e applica la decisione ricevuta insieme alla relativa motivazione.

La nuova API decisionale per le policy estende questo modello ai gateway gestiti dai clienti, agli ambienti di esecuzione degli agenti e ai flussi di lavoro. Un’azienda può mantenere l’infrastruttura esistente e chiedere a Obsidian una valutazione che tenga conto del contesto. Il componente del cliente che applica i controlli deve quindi attuare tale valutazione prima che l’operazione prosegua.

Obsidian documenta anche una modalità di segnalazione per verificare le corrispondenze con le policy sul traffico reale prima di bloccare le operazioni. I registri delle decisioni riportano l’agente, la persona che ha avviato la richiesta, lo strumento, gli argomenti, l’esito e la policy corrispondente, offrendo ai team di sicurezza un modo per verificare perché un’azione sia stata consentita o bloccata.

Il supporto alle approvazioni è più limitato rispetto all’architettura complessiva di autorizzazione o blocco: la documentazione attuale dell’azienda indica che la richiesta di approvazione è disponibile per le policy di Claude Code eseguite prima di un’operazione. Per progettare controlli per un insieme eterogeneo di agenti, è quindi importante considerare le funzionalità disponibili a livello di integrazione.

Il proxy MCP tiene i token delle applicazioni fuori dai client IA

Il proxy di sicurezza MCP governa le connessioni tra i client IA e le applicazioni aziendali supportate. Il Model Context Protocol, o MCP, offre agli agenti un metodo standard per richiamare gli strumenti messi a disposizione da server esterni. Obsidian inserisce un controllo delle policy tra il client e il server MCP dell’applicazione.

La documentazione del prodotto descrive la sostituzione dell’URL MCP diretto del fornitore con un endpoint gestito da Obsidian. Gli utenti autorizzano l’accesso tramite la procedura di consenso del fornitore dell’applicazione; il client IA riceve un token rilasciato dal proxy, anziché memorizzare direttamente il token di accesso all’applicazione.

Il proxy associa una sessione all’utente, al suo account nell’applicazione e al tenant pertinente, ad esempio una specifica organizzazione o area di lavoro Salesforce. Controlla le chiamate agli strumenti prima di inoltrarle e registra se sono state consentite o bloccate. Obsidian afferma che il sistema opera nell’ambito delle autorizzazioni già esistenti dell’utente nell’applicazione, anziché concedere privilegi aggiuntivi tramite un account di servizio condiviso.

L’annuncio menziona inoltre una collaborazione con Cloudflare e il suo MCP Server Portal. L’obiettivo è combinare la posizione di un gateway nel percorso del traffico con il contesto di identità, applicazioni e dati di Obsidian.

Perché i controlli a livello di azione sono importanti

Per le aziende che implementano agenti, la sfida concreta consiste nel consentire attività utili contenendo al contempo gli errori con conseguenze rilevanti. Un divieto generalizzato può bloccare del tutto un flusso di lavoro; una decisione circoscritta può consentire le normali operazioni di lettura, impedendo al contempo un’esportazione non autorizzata o richiedendo una revisione prima di una modifica distruttiva.

Obsidian sta riunendo queste decisioni in un livello di policy condiviso, applicabile agli strumenti supportati e ai punti di enforcement. Il valore dipenderà dalla qualità del contesto di accesso sottostante e dalla completezza dei percorsi sottoposti a controllo. Man mano che gli agenti assumono maggiori responsabilità operative, la capacità di spiegare e applicare una decisione prima della sua esecuzione diventa una componente sempre più importante della sicurezza aziendale.