Michael JohnsonIl 7 ottobre 2026 Apollo GraphQL ha presentato GraphOS Agent Services, un servizio in anteprima per gestire l’accesso degli agenti IA alle API aziendali. Gli amministratori possono autorizzare, mascherare o bloccare singoli campi di dati. L’attivazione avviene con il coinvolgimento di Apollo.
Che cosa ha presentato Apollo
Secondo la descrizione dell’azienda, Agent Services si colloca tra l’agente e i sistemi interni: trasforma le richieste in chiamate API, gestisce le credenziali e applica le restrizioni. Apollo individua quattro funzioni: ricerca di dati e strumenti, gestione delle identità, politiche di accesso e audit. Sono elencate nell’annuncio ufficiale del servizio.
Il comunicato stampa diffuso su PR Newswire è stato pubblicato il 7 ottobre alle 12:02, ora della costa orientale degli Stati Uniti, ovvero alle 19:02 a Mosca. Si tratta dell’ora di pubblicazione del comunicato; non è indicato separatamente il momento esatto in cui è stato aperto l’accesso.
Perché limitare l’accesso di un agente
Uno scenario pratico proposto da Apollo prevede che un agente lavori con dipendenti diversi. Nell’esempio del blog aziendale, un addetto al supporto e un analista finanziario chiedono informazioni su una fattura contestata. Entrambi vedono la fattura, ma solo l’analista può accedere al limite di credito del cliente. La differenza dipende dalla classificazione del campo e dalla politica di accesso.
Questo approccio può essere utile ai team che collegano agenti ai servizi interni di assistenza clienti, finanza e altri ambiti: le autorizzazioni possono riferirsi a dati specifici e tenere conto di chi ha assegnato il compito all’agente. Apollo riferisce anche di un progetto pilota presso Intuit. GraphOS è già utilizzato in produzione presso l’azienda, mentre il nuovo Agent Services è in fase di test preliminare. Apollo collega il progetto pilota all’analisi delle spese di marketing; l’annuncio non riporta risultati quantitativi sui risparmi.
Come funzionano le regole
Secondo la documentazione sulle regole di accesso, una regola definisce l’utente o il gruppo, l’applicazione chiamante, i dati protetti e l’esito della verifica. I campi sono classificati con tag; una regola può riguardare un tag o un servizio. Sono previsti tre effetti: restituire il valore, nasconderne il contenuto oppure negare l’accesso.
Per negare l’accesso sono previste diverse opzioni: escludere completamente il campo dalla risposta, restituire un errore oppure consentire la richiesta di un accesso aggiuntivo. Se un campo ha più tag, prevale l’effetto più restrittivo: il blocco prevale sul mascheramento e il mascheramento sull’autorizzazione.
Un aspetto importante della configurazione: Apollo avverte nella guida per gli amministratori che, per ora, il servizio non verifica presso il provider di identità l’identificativo dell’utente o del gruppo. Un errore di battitura fa sì che la regola non corrisponda più alle richieste, senza alcun avviso. Perciò, durante il progetto pilota, è necessario verificare l’esito effettivo per ogni ruolo.
Secondo la descrizione dell’architettura di Apollo, la decisione sull’accesso è presa dal motore delle politiche, senza coinvolgere un modello linguistico. La stessa descrizione afferma che i campi privi di un tag di classificazione restano senza restrizioni. L’overview della documentazione, tuttavia, suggerisce di bloccare i campi del servizio collegato prima di concedere autorizzazioni. Queste indicazioni richiedono una verifica nella configurazione specifica: il team dovrebbe testare separatamente l’accesso ai campi con e senza tag.
Audit e disponibilità
La guida a Monitor descrive un registro delle richieste che riporta ora, client, strumento, operazione, servizio interessato ed esito dell’applicazione delle regole. Per ogni richiesta è possibile vedere quali regole sono state applicate e quali campi sono stati mascherati o bloccati.
Una limitazione importante dell’audit: la vista della risposta ne mostra la struttura e i campi modificati, ma non i valori restituiti dal servizio originale. La verifica del contenuto effettivo della risposta va pianificata a parte. L’esportazione CSV include le richieste caricate nella pagina corrente del registro.
Le fonti non concordano sulla fase di accesso. Nel post del blog del 7 ottobre, Apollo annuncia una public preview e propone una lista d’attesa. La documentazione del servizio la definisce invece private preview e richiede l’assistenza di un dipendente Apollo per l’attivazione. La pagina non riporta una data di aggiornamento, quindi non è possibile stabilire in quale ordine siano comparse le due formulazioni.
Per ora, il percorso pratico è concordare un progetto pilota con Apollo. Nei materiali consultati non sono indicati né la data di rilascio stabile né il prezzo di Agent Services. Prima dell’attivazione, il team dovrebbe definire i campi accessibili all’agente, i responsabili delle autorizzazioni e le richieste di test per ciascun ruolo.