Dust + Okta Agent Gateway: collega i tool MCP in sicurezza

Dalla Blueprint Alliance a un’integrazione concreta

#

Nel mio precedente articolo sulla Blueprint Alliance, ho evidenziato l’importanza di inserire controlli di identità e policy nel percorso delle chiamate ai tool effettuate dagli agenti IA. Okta Agent Gateway è un modo per mettere in pratica questo principio. Vediamo ora un esempio concreto di configurazione.

Dust sta suscitando molto interesse qui in Francia, quindi mi è sembrata una piattaforma utile da cui partire. Collegheremo Dust ad alcuni server MCP di esempio tramite Okta Agent Gateway, poi verificheremo come le richieste vengono associate all’agente e all’utente per conto del quale opera.

Nei prossimi giorni pubblicherò un articolo più generale su Okta Agent Gateway, sulla sua architettura e sul suo ruolo nell’accesso dell’IA alle risorse aziendali. Qui ci concentriamo sulla configurazione necessaria per collegare un chatbot Dust.

Al termine di questa guida avrai:

• Un agente IA registrato in Okta e collegato a un’applicazione OIDC.
• Un Gateway attivo che espone i tool selezionati dei tuoi server MCP.
• Una connessione Dust che utilizza Static OAuth e Personal accounts.
• Una conversazione di test funzionante e la relativa attività in Okta.

Cosa colleghiamo

#

Okta Agent Gateway riunisce i tool di più server MCP remoti dietro un endpoint protetto da Okta. Dust si collega a quell’endpoint e il Gateway gestisce l’accesso ai server downstream configurati.²

La stessa configurazione può esporre i tool di uno o più server MCP. Scegli i servizi adatti al tuo caso d’uso, come cercare documenti, leggere informazioni dai repository o aggiornare un record aziendale.

Ci sono due connessioni distinte da configurare:

Prepariamo prima le connessioni MCP downstream, poi configuriamo Dust per utilizzare il Gateway. Anche ciascun provider downstream potrebbe richiedere all’utente di autenticarsi e concedere il consenso prima di poter utilizzare i suoi tool.

La vista dei componenti mostra le connessioni configurate. La sequenza seguente si concentra su una richiesta a un tool MCP, includendo la connessione dell’account personale quando necessaria.

sequenceDiagram
    actor User as Utente
    participant Dust as Dust
    participant Okta as Okta Authorization Server
    participant Gateway as Okta Agent Gateway
    participant MCP as Server MCP remoto
    User->>Dust: Richiede un’azione tramite un tool MCP
    opt Connessione dell’account personale necessaria
    Dust-->>User: Richiede la connessione dell’account personale
    User->>Okta: Si autentica e autorizza l’accesso se richiesto
    Okta-->>Dust: Authorization code tramite la callback registrata
    Dust->>Okta: Scambia il codice usando le credenziali del client registrato
    Okta-->>Dust: Access token e refresh token quando concesso
    end
    Dust->>Gateway: Discovery o chiamata ai tool con access token
    Gateway->>Gateway: Verifica l’accesso e applica i controlli configurati
    Gateway->>MCP: Chiama il tool selezionato tramite la connessione downstream
    MCP-->>Gateway: Risultato del tool
    Gateway-->>Dust: Risultato del tool
    Dust-->>User: Presenta il risultato del tool

L’integrazione Dust utilizzata qui non offre Cross App Access (XAA) per questa connessione, quindi utilizziamo un OAuth authorization code flow con un client registrato e un client secret. Quando Dust aggiungerà un supporto XAA compatibile, sarà la mia opzione preferita per l’autenticazione delegata, con accesso gestito centralmente e meno passaggi separati di consenso per l’utente. La migrazione dipenderà dall’integrazione di Dust e dovrà mantenere i controlli e la visibilità del Gateway di cui hai bisogno. Per il modello di delega, consulta la guida alla configurazione XAA³ e il mio approfondimento sugli access pattern.

Prerequisiti

#

Prima di iniziare, assicurati di avere:

1. Un tenant Okta con AI Agents e Agent Gateway abilitati, oltre ai permessi per gestirli.

   Okta Preview

   Ho utilizzato un tenant Okta Preview per provare le funzionalità disponibili in questa configurazione. I tenant Preview ricevono le release prima di quelli di produzione, ma la disponibilità dipende anche dall’abilitazione delle funzionalità e dalle licenze. Verifica questi requisiti per il tuo tenant.⁴

2. Un workspace Dust con accesso amministrativo per aggiungere server MCP e creare agenti.

   Dust Free Tier

   Dust offre attualmente una licenza Free con 500 crediti una tantum nel piano Business, utile per provare la configurazione. Questi crediti non si rinnovano ogni mese; verifica i prezzi e i limiti attuali del piano prima di iniziare.⁵

3. Almeno un server MCP remoto raggiungibile dal cloud di Okta, con autenticazione OAuth 2.0 Bearer e le credenziali necessarie per registrarlo.

4. Un utente di test Okta da assegnare all’applicazione collegata, con i permessi necessari per il servizio downstream.

La realizzazione o il deployment del server MCP non rientrano nell’ambito di questo articolo. Puoi utilizzare un servizio hosted compatibile, come il server MCP remoto di GitHub, oppure un server che sviluppi e ospiti tu stesso.

Vantaggi di Agent Gateway

#

Perché aggiungere un Gateway tra Dust e i tuoi tool? La panoramica di Okta sulla runtime governance evidenzia il valore di inserire i controlli di identità direttamente nel percorso delle richieste.⁶

• Controllo centralizzato degli accessi: gestisci quali agenti possono raggiungere il Gateway e quali tool espone.
• Isolamento delle credenziali downstream: Dust si autentica al Gateway; Okta gestisce le credenziali downstream senza esporle a Dust.
• Attribuzione ad agente e utente: correla l’attività dei tool con l’agente e la persona per conto della quale opera.
• Un punto di integrazione condiviso: collega client MCP compatibili a un unico endpoint, con la configurazione gestita in Okta.
• Un punto centrale di contenimento: disattiva una connessione o il Gateway durante un incidente. La sezione sulla revoca d’emergenza mostra come applicare questi controlli.

Configurazione di Okta

#

Preparare i server MCP downstream

#

Se non hai ancora configurato i server MCP in Okta, inizia registrando quelli di cui vuoi utilizzare i tool in Dust, tralasciando quelli già registrati. Molte integrazioni MCP sono disponibili nel catalogo Okta Integration Network (OIN), quindi consultalo prima di inserire manualmente una configurazione.⁷ Gli screenshot utilizzano GitHub e AtkoTravel, un server MCP di esempio con tool per cercare e prenotare voli. I tuoi server possono offrire funzionalità completamente diverse.

Scegli il percorso tramite catalogo al passaggio 2 oppure la registrazione manuale al passaggio 3, poi completa i passaggi relativi alle credenziali e alla discovery. Le voci del catalogo precompilano i dettagli del server; la registrazione manuale consente di inserirli direttamente.⁷⁸

1. Nella Okta Admin Console, vai su Applications and Resources → MCP Servers.

   

2. Seleziona Add from Catalog per trovare un server MCP nel catalogo OIN. Seleziona il suo riquadro, fai clic su Add MCP Server e compila gli eventuali campi specifici della tua organizzazione. Okta precompila i metadati disponibili del server.

3. Se il tuo server non è nel catalogo, scegli Add MCP Server e segui la registrazione manuale⁸. Inserisci il nome e il base URL, poi verifica o fornisci i metadati dell’authorization server.

4. Configura le credenziali del client OAuth downstream e gli scope necessari. Per la registrazione manuale, utilizza Dynamic Client Registration quando disponibile e supportato dal provider; altrimenti registra un confidential OAuth client presso il provider e inserisci Client ID e Client Secret in Okta. Quando XAA non è supportato, per una connessione mediata da Okta STS la callback del provider ha questa forma:

   https://YOUR_OKTA_DOMAIN/oauth2/v1/sts/callback

   Utilizza la callback richiesta dall’integrazione Okta STS del tuo provider.⁹ È distinta dalla callback di Dust, che va configurata nell’applicazione OIDC Okta collegata.

5. Salva le credenziali, poi utilizza Test credentials and discover tools per verificare la connessione e individuare i tool disponibili. Completa la registrazione con Done and close. Ripeti per ogni server MCP che vuoi includere.

Registrare Dust come agente IA in Okta

#

Creare l’agente e abilitare l’accesso degli utenti

#

1. Nella Okta Admin Console, apri Directory → AI Agents → Register AI Agent → Register manually.

   

2. Assegna all’agente un nome chiaro, come Dust Agent #1, e una descrizione che ne identifichi lo scopo.

   

3. Seleziona Allow users to access this agent, poi Create a new OIDC app linked to this AI agent. Questo crea automaticamente l’applicazione utilizzata per il sign-in degli utenti.

   

4. Facoltativamente, assegna un utente o un gruppo come owner per rendere chiara la responsabilità dell’agente. Questo fornisce anche un contesto utile per i processi di governance della tua organizzazione.

   

5. Completa la registrazione. Nota che inizialmente l’agente appare nello stato STAGED. Apri i suoi dettagli per configurare l’autenticazione del client.

   

6. In Client registration, configura Client secret.

   

   Flusso OAuth e autenticazione del client

   Qui utilizziamo Client secret perché è l’unico metodo di autenticazione supportato dall’attuale implementazione Static OAuth di Dust.

   Public/private key è un metodo migliore e più sicuro, da utilizzare quando disponibile nel servizio del tuo agente.

7. Fai clic su Generate secret. Copia Client ID e Client Secret in un luogo sicuro, poi fai clic su Activate. Sono le credenziali del client che inserirai in Dust.

   

Configurare l’applicazione OIDC collegata

#

Ora abbiamo un agente IA registrato e collegato a un’applicazione OIDC. Il passaggio successivo consiste nel configurare l’applicazione per l’accesso degli utenti.

Attivare l’applicazione e assegnare gli utenti

#

1. Nella scheda User Access dell’agente, segui Application → Assignments per aprire il popup con l’applicazione OIDC collegata.

   

2. Attiva l’applicazione se è inattiva.

   

3. Assegna gli utenti o i gruppi che devono poter utilizzare questo agente.

   

Registrare gli URL di callback di Dust

#

1. Apri le impostazioni General dell’applicazione e modifica Sign-in redirect URIs.

   La callback EU che ho utilizzato è: https://eu.dust.tt/oauth/mcp_static/finalize

   

   URL di callback di Dust

   La documentazione MCP di Dust raccomanda di registrare sia la callback regionale sia quella globale.¹⁰

   Per un workspace EU, aggiungi queste due voci:

   • https://eu.dust.tt/oauth/mcp_static/finalize (regionale, EU)
   • https://app.dust.tt/oauth/mcp_static/finalize (globale)

   Per un workspace US, utilizza https://dust.tt/oauth/mcp_static/finalize come voce regionale, insieme alla stessa callback globale. Salva le impostazioni dell’applicazione.

Creare e attivare Agent Gateway

#

Ora abbiamo un agente IA registrato, collegato a un’applicazione OIDC e assegnato agli utenti. Il passaggio successivo consiste nel creare l’Agent Gateway che esporrà i tool selezionati dei server MCP.

1. Vai su Security → Agent Gateway → Create Agent Gateway.

   

2. Inserisci un nome, ad esempio Dust Gateway. Verifica l’URL generato del Gateway e personalizzane il path se necessario, poi fai clic su Create e Next.

   

3. Copia l’URL completo del Gateway. Negli esempi seguenti è:

   https://YOUR_ORG.gateway.oktapreview.com/mcp/servers/dust-gateway

   Utilizza il tuo URL esattamente come viene visualizzato. Il path non può essere modificato dopo il salvataggio.¹¹

4. Nella scheda AI Agents, fai clic su Edit, seleziona Dust Agent #1 e salva. Fai clic su Next.

   

5. In Resource connections, fai clic su Add connection nella sezione dei server MCP.

   

6. Seleziona i server MCP da esporre, poi Save e Next. Lo screenshot mostra due esempi: GitHub e AtkoTravel.

   

7. In Tool customization, fai clic su Manage tools. Seleziona i tool che il Gateway deve esporre e salva la selezione con Save. Ripeti la stessa operazione per tutti i server MCP che vuoi esporre tramite il Gateway.

   

   

   Gli screenshot mostrano una selezione ampia per questo esempio. Personalizzala in base alle attività che i tuoi utenti devono svolgere. Puoi sempre tornare in seguito per aggiungere o rimuovere tool.

8. Completa il wizard quando i tool desiderati sono abilitati.

   

9. Infine, attiva il Gateway se è ancora inattivo. Fai clic su Activate now quando disponibile, oppure seleziona Actions → Activate.

   

A questo punto, verifica tre cose: che l’autenticazione del client dell’agente sia attiva, che l’applicazione collegata sia attiva e assegnata e che anche il Gateway sia attivo.

Individuare gli endpoint OAuth corretti

#

Questo è il dettaglio della configurazione su cui vale la pena soffermarsi: utilizza l’authorization server indicato dalla risorsa del Gateway. Non dedurre l’issuer dal tuo dominio Okta e non utilizzare gli authorization server org o default.

Possiamo utilizzare gli endpoint .well-known esposti per individuare l’issuer, l’authorization endpoint e il token endpoint corretti.

1. Per un URL del Gateway che termina con /mcp/servers/dust-gateway, inserisci /.well-known/oauth-protected-resource subito dopo l’hostname, per costruire un URL come questo:

   https://YOUR_ORG.gateway.oktapreview.com/.well-known/oauth-protected-resource/mcp/servers/dust-gateway

   Puoi quindi utilizzare curl, oppure il browser, per richiedere il documento di discovery. Ad esempio:

   curl --fail --silent --show-error \
     'https://YOUR_ORG.gateway.oktapreview.com/.well-known/oauth-protected-resource/mcp/servers/dust-gateway' | jq

   Info

   Questo meccanismo di discovery basato sul path è definito nella RFC 9728, sezione 3.1.¹²

   La risposta di esempio ha questa struttura, con gli identificativi sostituiti:

   {
     "resource": "https://YOUR_ORG.gateway.oktapreview.com/mcp/servers/dust-gateway",
     "authorization_servers": [
       "https://YOUR_ORG.oktapreview.com/oauth2/ausEXAMPLE"
     ],
     "scopes_supported": ["openid", "offline_access"]
   }

2. Annota la resource, l’authorization server indicato e gli scope supportati. Utilizzeremo questi valori nei passaggi successivi.

3. Per l’issuer Okta restituito sopra, dobbiamo richiedere i metadati OIDC. Utilizza l’endpoint .well-known di quell’authorization server. Ad esempio:

   https://YOUR_ORG.oktapreview.com/oauth2/ausEXAMPLE/.well-known/openid-configuration

   Utilizza nuovamente curl (o un browser) per richiedere il documento di discovery:

   curl --fail --silent --show-error \
     'https://YOUR_ORG.oktapreview.com/oauth2/ausEXAMPLE/.well-known/openid-configuration' | jq

4. Copia authorization_endpoint e token_endpoint direttamente dalla risposta. Ecco un estratto di esempio:

   {
     "issuer": "https://YOUR_ORG.oktapreview.com/oauth2/ausEXAMPLE",
     "authorization_endpoint": "https://YOUR_ORG.oktapreview.com/oauth2/ausEXAMPLE/v1/authorize",
     "token_endpoint": "https://YOUR_ORG.oktapreview.com/oauth2/ausEXAMPLE/v1/token"
   }

Se vuoi fare più in fretta, ho creato uno script di OAuth discovery che individua la configurazione OAuth indicata da un Okta Agent Gateway. Richiede curl e jq; passa l’URL del Gateway come argomento oppure imposta GATEWAY_URL.

Ad esempio: bash discover-agent-gateway-oauth.sh 'https://YOUR_ORG.gateway.oktapreview.com/mcp/servers/dust-gateway'. Poi copia in Dust gli endpoint individuati e gli scope supportati.

Configurazione di Dust

#

Ora che abbiamo l’URL del Gateway, le credenziali del client e gli endpoint corretti dell’authorization server, possiamo configurare Dust per collegarsi a Okta Agent Gateway.

Aggiungere il Gateway a Dust

#

Creare la connessione MCP

#

1. In Dust, apri Spaces → Tools → + Add Tools.

   

2. Seleziona Add MCP Server.

   

3. Incolla il Gateway MCP URL, poi scegli Static OAuth come metodo di autenticazione.

   

4. Compila il modulo con le tue credenziali e i risultati della discovery:

   Campo Dust	Valore per questa configurazione
   URL	L’URL MCP completo del Gateway, che termina con /mcp/servers/dust-gateway
   Authentication	Static OAuth
   How do you want to connect?	Personal accounts
   OAuth Client ID	Client ID copiato dalla scheda Client registration dell’agente IA in Okta
   OAuth Client Secret	Il client secret attivo corrispondente
   OAuth Token Endpoint	token_endpoint dal documento di discovery dell’issuer del Gateway
   OAuth Authorization Endpoint	authorization_endpoint dallo stesso documento di discovery
   OAuth Scope(s)	openid offline_access, come indicato in questo esempio
   OAuth Resource / Audience	Lasciato vuoto nella configurazione testata; vedi la nota seguente
   Token Endpoint Authentication Method	Request body (client_secret_post) per la configurazione del client utilizzata qui

   Scegli Personal accounts affinché gli utenti stabiliscano le proprie connessioni. Dust documenta che gli amministratori devono comunque completare una connessione OAuth iniziale durante il setup, seguiti dai singoli utenti al primo utilizzo del tool. Vedi Personal vs Shared Credentials.

   

5. Fai clic su Setup connection e completa l’autorizzazione iniziale se richiesta. La connessione dovrebbe quindi comparire in Dust con l’autenticazione attiva.

   

   Resource, audience e scope

   Lasciare Resource / Audience vuoto ha funzionato in questa configurazione testata. Non è una regola valida per ogni integrazione OAuth e il valore resource indicato non è automaticamente intercambiabile con ogni parametro audience specifico di un provider.

   Se il tuo ambiente richiede un resource indicator esplicito, utilizza la resource del Gateway indicata nei metadati e verifica che la configurazione ne rispetti i requisiti.

   Allo stesso modo, utilizza scope supportati dall’authorization server del Gateway. Gli scope downstream, come tool:search, appartengono alla connessione downstream; non copiarli in Dust.

6. Apri Tools & Stakes per confermare che la discovery sia riuscita e verificare l’impostazione di conferma di ogni tool.

   

   Nel mio setup, i tool inizialmente apparivano come High, richiedendo una conferma a ogni esecuzione. L’interfaccia offriva anche Low, che consente di salvare la conferma dell’utente, e Never ask, che permette l’esecuzione automatica.

7. Mantieni la conferma abilitata per le operazioni con effetti rilevanti, come creare, modificare o eliminare record. Le impostazioni di conferma di Dust regolano l’interazione con l’utente; l’autorizzazione in Okta e nel servizio downstream rimane un controllo distinto.

Creare un chatbot in Dust

#

Crea un chatbot adatto ai tool MCP che hai collegato. Gli screenshot mostrano un assistente di viaggio, ma gli stessi passaggi si applicano a un assistente per repository, alla ricerca di documenti o a un altro workflow aziendale.

Creare il chatbot e definirne le istruzioni

#

1. Apri Create → From Scratch in Dust.

   

2. In Instructions, descrivi lo scopo del chatbot, i tool che deve utilizzare e l’output atteso. Lo screenshot mostra un assistente di viaggio; adatta scopo e istruzioni al tuo caso d’uso:

   

   Info

   Nell’esempio illustrato, le istruzioni specializzano il chatbot nella ricerca di voli e nella creazione, lettura, modifica e cancellazione delle prenotazioni. Sostituisci questo ambito con le funzionalità del tuo MCP. Il prompt guida il comportamento; i permessi devono comunque essere applicati dai sistemi collegati.

3. In Capabilities and knowledge, fai clic su Add Capability.

   

4. Seleziona Dust Gateway tra i tool disponibili, poi fai clic su + Add.

   

5. Conferma con Add 1 Capability.

   

6. Imposta nome, descrizione e visibilità del chatbot in base al suo scopo. TravelHelper è soltanto il nome di esempio negli screenshot. Salva l’agente.

   

7. Fai clic su Start Chat per aprire una conversazione.

   

Testare la connessione end-to-end

#

Inizia con una richiesta in sola lettura che corrisponda a un tool esposto dal tuo server MCP. Ad esempio, chiedi a un MCP per repository di elencare quelli accessibili, oppure a un MCP documentale di cercare un documento. Con il server di esempio per i voli mostrato qui, utilizzo:

Search for flights from CDG to LIN for next Thursday.

Adatta la richiesta al MCP collegato e ai permessi del tuo utente di test.

Al primo utilizzo, Dust chiede di collegare il tuo account al Gateway. Fai clic su Connect Dust gateway, poi completa il sign-in Okta e i passaggi di autorizzazione richiesti dalla tua configurazione.

Questo stabilisce la connessione OAuth dell’utente. È distinta dal semplice accesso al workspace Dust.

Una volta collegato, Dust chiama il Gateway, che raggiunge il server MCP selezionato e restituisce i risultati del tool. Qui i risultati sono opzioni di volo.

Se il tuo MCP supporta operazioni di scrittura, provane una su dati temporanei di test e verifica la richiesta di conferma. Nell’esempio dei voli, una richiesta successiva potrebbe essere:

Book the first flight, departing at 06:30.

Per un altro MCP, sostituiscila con un’azione appropriata, come creare una issue di test in GitHub.

Questa richiesta successiva ha riutilizzato la connessione esistente senza un nuovo sign-in OAuth. Questo non significa che l’accesso sia permanente: scadenza dei token, comportamento del refresh, revoca e modifiche alle policy possono richiedere una nuova connessione o causare il fallimento di una chiamata successiva.

Adatta i test successivi alle operazioni supportate dal tuo MCP. L’esempio dei voli supporta anche lettura, modifica e cancellazione delle prenotazioni; gli screenshot mostrano solo ricerca e prenotazione, non tutti i tool o tutte le integrazioni downstream.

Visibilità e applicazione delle policy

#

Tracciare l’agente e l’utente in Okta

#

La verifica finale utile consiste nel correlare la conversazione con l’attività registrata in Okta.

Apri il System Log e controlla gli eventi nell’intervallo del tuo test. La configurazione mostrata qui ha registrato le chiamate ai tool con l’event type agent_gateway.mcp.tool.call.

Ecco un estratto abbreviato e anonimizzato dell’evento di prenotazione di esempio. Il tuo server MCP produrrà nomi di tool e target diversi:

{
  "actor": {
    "id": "wlpEXAMPLE",
    "type": "Agent",
    "displayName": "Dust Agent #1"
  },
  "displayMessage": "Call MCP tool",
  "eventType": "agent_gateway.mcp.tool.call",
  "outcome": {
    "result": "SUCCESS"
  },
  "gatewayContext": {
    "capabilityName": "AtkoTravelMCP_book",
    "clientId": "wlpEXAMPLE",
    "subject": {
      "type": "User",
      "id": "00uEXAMPLE",
      "alternateId": "traveler@example.com"
    }
  },
  "target": [
    {
      "type": "VIRTUAL_MCP_SERVER",
      "displayName": "dust-gateway"
    },
    {
      "type": "TARGET_MCP_SERVER",
      "displayName": "AtkoTravel MCP"
    }
  ]
}

L’evento collega la richiesta al tool con il suo contesto di identità ed esecuzione:

• Quale agente? actor.displayName identifica Dust Agent #1.
• Per conto di chi? gatewayContext.subject identifica l’utente.
• Quale operazione? capabilityName identifica il tool di prenotazione.
• Tramite quale connessione? I target identificano il Gateway e il server MCP downstream.
• Cosa è successo? L’evento registra l’esito della chiamata.

Per una vista focalizzata sul Gateway, apri Security → Agent Gateway → Dust Gateway → Recent Activity.

La documentazione di Okta sull’attività del Gateway descrive questa vista e rimanda al System Log per gli eventi correlati di autenticazione e token exchange.¹⁴ L’esempio sopra mostra l’attribuzione e i metadati delle chiamate; non va interpretato come una garanzia che vengano registrati i payload completi di richiesta e risposta di ogni tool.

Policy di accesso ai tool

#

Una connessione funzionante è solo il punto di partenza. Decidi chi può utilizzare l’agente, quale agente può raggiungere il Gateway e quali tool espone il Gateway. Questi controlli operano insieme, mentre il servizio downstream continua ad applicare i propri permessi.

Ad esempio, un assistente documentale potrebbe aver bisogno di tool di ricerca e lettura senza poter eliminare documenti. Ecco come applicherei questo limite alla configurazione:

1. Limita l’accesso degli utenti. Assegna all’applicazione OIDC collegata solo gli utenti o i gruppi previsti. Nella scheda Sign On, verifica l’app sign-in policy assegnata e i relativi requisiti di autenticazione. Configura MFA e altre condizioni adatte ai tuoi utenti.¹⁶ Questo regola l’autenticazione dell’utente; non seleziona i singoli tool MCP.
2. Autorizza l’agente previsto. In Security → Agent Gateway → Dust Gateway → AI Agents, mantieni solo gli agenti che devono utilizzare questo endpoint. La connessione è visibile anche nella scheda Resource connections di ciascun agente.²
3. Riduci l’insieme dei tool esposti. Apri Tool customization → Manage tools per ogni server MCP collegato. Mantieni le operazioni di ricerca e lettura necessarie, deseleziona quelle di scrittura o eliminazione non necessarie e salva.¹¹ Questo modifica i tool esposti tramite il Gateway, indipendentemente dalle istruzioni del chatbot.
4. Verifica entrambi gli esiti. Aggiorna l’elenco dei tool in Dust se necessario, poi conferma che una richiesta consentita funzioni e che un tool rimosso non sia più disponibile. Ripeti con un utente di test non assegnato per verificare il limite di accesso degli utenti. Utilizza l’attività del Gateway e il System Log per analizzare risultati inattesi.

Kill Switch e revoca dell’accesso in emergenza

#

Disattivare un agente funziona già come Kill Switch: impedisce all’agente di ottenere nuovi token tramite Okta e di stabilire nuove sessioni.¹⁷¹⁸ Se un agente inizia a effettuare chiamate inattese, gli amministratori possono così contenerne l’attività centralmente sulle connessioni gestite.

Per questa configurazione, scegli il controllo adatto all’ambito dell’incidente:

1. Disattiva l’agente. Apri Directory → AI Agents → Dust Agent #1 e seleziona Actions → Deactivate.¹⁷
2. Limita il contenimento a una connessione quando opportuno. Nella scheda Resource connections dell’agente, seleziona Deactivate connection per il Gateway. Questo nega le future richieste di accesso tramite quella connessione.¹⁹ Per sospendere invece l’intero Gateway, utilizza Security → Agent Gateway → Dust Gateway → Actions → Deactivate. Questo coinvolge tutti gli agenti che utilizzano quell’endpoint.¹¹
3. Verifica il risultato e conserva le evidenze. Conferma che l’agente disattivato non possa più ottenere un nuovo token. Ripeti una richiesta innocua da una conversazione Dust esistente per verificare l’effetto sui token già emessi. Registra la modifica amministrativa e controlla l’attività successiva nel System Log e nell’attività del Gateway. Per un account utente compromesso, segui anche la procedura di gestione delle sessioni utente e di ripristino delle credenziali.
4. Ripristina l’accesso dopo l’indagine. Verifica l’account coinvolto, le credenziali dell’agente, le resource connections e la selezione dei tool. Riattiva solo i componenti necessari, poi ripeti le verifiche di accesso.

I token già emessi possono rimanere utilizzabili fino alla loro scadenza effettiva.²⁰ L’estensione prevista del Kill Switch ad Agent Gateway renderà il contenimento più efficace, aggiungendo la revoca dei token attivi e la terminazione delle sessioni in corso.¹⁸

Il Gateway è un punto utile per applicare questi controlli perché si trova nel percorso delle richieste verso più servizi MCP. Mantieni le procedure di risposta lato provider per le credenziali o le connessioni dirette esterne a quel percorso; interrompere l’accesso non può annullare un’operazione già completata downstream.

Come proseguire

#

Ora abbiamo un’integrazione concreta: Dust offre l’esperienza conversazionale, i tuoi server MCP forniscono i tool e Okta Agent Gateway si inserisce nel percorso di accesso con un agente identificabile, il contesto dell’utente e un’attività dei tool osservabile.

Quello che apprezzo di questo esempio è quanto poco codice personalizzato richieda la connessione. Una volta pronto il server MCP, il lavoro è soprattutto di configurazione: registrare l’agente, assegnare l’accesso, selezionare i tool e collegare Dust utilizzando i metadati OAuth corretti.

Nei prossimi giorni approfondirò Okta Agent Gateway in un articolo separato, includendo la sua architettura e come lo stesso approccio si applica ad altre piattaforme di agenti.

Utilizzi già Dust con tool aziendali? Quale integrazione MCP metteresti per prima dietro un Gateway?

Condividi la tua esperienza o le tue domande nei commenti.