Dust + Okta Agent Gateway: Connect MCP Tools Securely

From the Blueprint Alliance to a concrete integration

#

In my previous article on the Blueprint Alliance, I highlighted the importance of placing identity and policy controls in the path of AI agents’ tool calls. Okta Agent Gateway is one way to put that principle into practice. Let’s now look at a concrete configuration example.

Dust is attracting a lot of interest here in France, so it seemed like a useful platform to start with. We will connect Dust to some example MCP servers through Okta Agent Gateway, then check how requests are associated with the agent and the user behind them.

In the next few days, I will publish a more general article on Okta Agent Gateway, its architecture, and its role in enterprise AI access. Here, the focus is the configuration you need to get a Dust chatbot connected.

By the end of this guide, you will have:

• An AI agent registered in Okta and linked to an OIDC application.
• An active Gateway exposing selected tools from your MCP servers.
• A Dust connection using Static OAuth and Personal accounts.
• A working test conversation and the corresponding activity in Okta.

What we are connecting

#

Okta Agent Gateway brings tools from multiple remote MCP servers behind an Okta-secured endpoint. Dust connects to that endpoint, and the Gateway handles access to the configured downstream servers.²

The same setup can expose tools from one or several MCP servers. Choose the services that fit your use case, such as searching documents, reading repository information, or updating a business record.

There are two separate connections to configure:

We first prepare the downstream MCP connections, then configure Dust to use the Gateway. Each downstream provider may also require the user to sign in and grant consent before its tools can be used.

The component view shows the configured connections. The sequence below focuses on a request to an MCP tool, including the personal account connection when one is needed.

sequenceDiagram
    actor User as User
    participant Dust as Dust
    participant Okta as Okta Authorization Server
    participant Gateway as Okta Agent Gateway
    participant MCP as Remote MCP Server
    User->>Dust: Request an action using an MCP tool
    opt Personal account connection required
    Dust-->>User: Request personal account connection
    User->>Okta: Sign in and authorize access as required
    Okta-->>Dust: Authorization code via registered callback
    Dust->>Okta: Exchange code using registered client credentials
    Okta-->>Dust: Access token and refresh token when granted
    end
    Dust->>Gateway: Discover or call tools with access token
    Gateway->>Gateway: Validate access and apply configured controls
    Gateway->>MCP: Call selected tool using downstream connection
    MCP-->>Gateway: Tool result
    Gateway-->>Dust: Tool result
    Dust-->>User: Present the tool result

The Dust integration used here does not offer Cross App Access (XAA) for this connection, so we use an OAuth authorization code flow with a registered client and client secret. When Dust adds compatible XAA support, it will be my preferred option for delegated authentication, with centrally managed access and fewer separate user consent steps. The migration will depend on Dust’s integration and should preserve the Gateway controls and visibility you need. For the delegation model, see the XAA configuration guide³ and my access patterns deep dive.

Prerequisites

#

Before starting, make sure you have:

1. An Okta tenant with AI Agents and Agent Gateway enabled, plus permission to manage them.

   Okta Preview

   I used an Okta Preview tenant to try the features available in this configuration. Preview tenants receive releases before production, but availability also depends on feature enablement and licensing. Confirm these requirements for your tenant.⁴

2. A Dust workspace with administrator access to add MCP servers and create agents.

   Dust Free Tier

   Dust currently offers a Free seat with 500 lifetime credits under its Business plan, useful for trying the configuration. These credits do not renew monthly; check the current pricing and plan limits before starting.⁵

3. At least one remote MCP server reachable from Okta’s cloud, with OAuth 2.0 Bearer authentication and the credentials needed to register it.

4. An Okta test user you can assign to the linked application, plus the required access to the downstream service.

Building or deploying the MCP server is outside the scope of this article. You can use a compatible hosted service, such as GitHub’s remote MCP server, or one you build and host yourself.

Agent Gateway Advantages

#

Why add a Gateway between Dust and your tools? Okta’s runtime governance overview highlights the value of putting identity controls directly in the request path.⁶

• Centralized access control: manage which agents can reach the Gateway and which tools it exposes.
• Downstream credential isolation: Dust authenticates to the Gateway; Okta handles the downstream credentials without exposing them to Dust.
• Agent and user attribution: correlate tool activity with the agent and the person on whose behalf it acts.
• A shared integration point: connect compatible MCP clients to one endpoint, with configuration managed in Okta.
• A central containment point: disable a connection or the Gateway during an incident. The emergency revocation section shows how to apply these controls.

Okta Configuration

#

Prepare the downstream MCP servers

#

If you don’t have an MCP server already configured in Okta, start by registering the MCP servers whose tools you want Dust to use, unless they are already registered in Okta. Many MCP integrations are available through the Okta Integration Network (OIN) catalog, so check it before entering a configuration manually.⁷ The screenshots use GitHub and AtkoTravel, an example MCP server with flight search and booking tools. Your own servers can provide entirely different capabilities.

Choose either the catalog route in step 2 or manual registration in step 3, then complete the credentials and discovery steps. Catalog entries prepopulate server details; manual registration lets you supply them yourself.⁷⁸

1. In the Okta Admin Console, go to Applications and Resources → MCP Servers.

   

2. Select Add from Catalog to find an MCP server in the OIN catalog. Select its tile, click Add MCP Server, and complete any organization-specific fields. Okta prepopulates the available server metadata.

3. If your server is not in the catalog, choose Add MCP Server and follow the manual registration⁸. Enter its name and base URL, then review or supply the authorization server metadata.

4. Configure the downstream OAuth client credentials and required scopes. For manual registration, use Dynamic Client Registration when offered and supported by the provider; otherwise register a confidential OAuth client with the provider and enter its Client ID and Client Secret in Okta. When XAA is not supported, for a connection brokered through Okta STS, the provider callback has this form:

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

   Use the callback required by your provider’s Okta STS integration.⁹ This is separate from Dust’s callback, which belongs in the linked Okta OIDC application.

5. Save the credentials, then use Test credentials and discover tools to validate the connection and discover available tools. Complete registration with Done and close. Repeat for each MCP server you want to include.

Register Dust as an AI agent in Okta

#

Create the agent and enable user access

#

1. In the Okta Admin Console, open Directory → AI Agents → Register AI Agent → Register manually.

   

2. Give the agent a clear name, such as Dust Agent #1, and a description that identifies its purpose.

   

3. Select Allow users to access this agent, then Create a new OIDC app linked to this AI agent. This automatically creates the application used for user sign-in.

   

4. Optionally assign a user or group as the owner so responsibility for the agent is clear. This also provides useful context for your organization’s governance processes.

   

5. Finish registration. Note that the agent initially appears as STAGED. Open its details to configure client authentication.

   

6. In Client registration, configure Client secret.

   

   OAuth flow and client authentication

   We are using Client secret here because it’s the only supported authentication method for Dust’s current Static OAuth implementation.

   Public/private key is a better and more secure method and should be used when it’s available in your agent service.

7. Click Generate secret. Copy the Client ID and Client Secret to a secure location, then click Activate. These are the client credentials you will enter in Dust.

   

Configure the linked OIDC application

#

We now have an AI agent registered and linked to an OIDC application. The next step is to configure the application for user access.

Activate the application and assign users

#

1. In the agent’s User Access tab, follow Application → Assignments to open the popup with the linked OIDC application.

   

2. Activate the application if it is inactive.

   

3. Assign the users or groups who should be allowed to use this agent.

   

Register Dust’s callback URLs

#

1. Open the application’s General settings and edit Sign-in redirect URIs.

   The EU callback I used is: https://eu.dust.tt/oauth/mcp_static/finalize

   

   Dust’s callback URL

   Dust’s MCP documentation recommends registering both the regional and global callbacks.¹⁰

   For an EU workspace, add these two entries:

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

   For a US workspace, use https://dust.tt/oauth/mcp_static/finalize as the regional entry, plus the same global callback. Save the application settings.

Create and activate the Agent Gateway

#

We now have an AI agent registered, linked to an OIDC application, and assigned to users. The next step is to create the Agent Gateway that will expose the selected tools from the MCP servers.

1. Go to Security → Agent Gateway → Create Agent Gateway.

   

2. Enter a name such as Dust Gateway. Review the generated Gateway URL and customize its path if needed, then click Create and Next.

   

3. Copy the complete Gateway URL. In the examples below it’s:

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

   Use your own URL exactly as displayed. The path cannot be changed after saving.¹¹

4. On the AI Agents tab, click Edit, select Dust Agent #1, and save. Click Next.

   

5. Under Resource connections, click Add connection in the MCP servers section.

   

6. Select the MCP servers you want to expose, then Save and Next. The screenshot shows two examples: GitHub and AtkoTravel.

   

7. Under Tool customization, click Manage tools. Select the tools the Gateway should expose and Save your selection. Repeat the same operation for all the MCP servers you want to expose through the Gateway.

   

   

   The screenshots show a broad selection for this example. Customize it based on what your users need to do. You can always return later to add or remove tools.

8. Finish the wizard once the intended tools are enabled.

   

9. Finally, activate the Gateway if it is still inactive. Click Activate now when offered, or select Actions → Activate.

   

At this point, check three things: the agent’s client authentication is activated, its linked application is active and assigned, and the Gateway itself is active.

Discover the correct OAuth endpoints

#

This is the configuration detail worth slowing down for: use the authorization server advertised by your Gateway resource. Do not guess an issuer from your Okta domain or use the org or default authorization servers.

We can use the exposed .well-known endpoints to discover the correct issuer, authorization endpoint, and token endpoint.

1. For a Gateway URL ending in /mcp/servers/dust-gateway, insert /.well-known/oauth-protected-resource immediately after the hostname, to construct a URL like this:

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

   You can then use curl, or your browser, to request the discovery document. For example:

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

   Info

   This path-based discovery mechanism is defined in RFC 9728, Section 3.1.¹²

   The example response has this structure, with identifiers replaced here:

   {
     "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. Record the resource, the advertised authorization server, and the supported scopes. We will use these values in the next steps.

3. For the Okta issuer returned above, we need to request its OIDC metadata. Use the .well-known endpoint for that authorization server. For example:

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

   Again, use curl (or a browser) to request the discovery document:

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

4. Copy authorization_endpoint and token_endpoint directly from the response. An illustrative excerpt is:

   {
     "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"
   }

If you want to go faster, I created an OAuth discovery script that discovers the OAuth configuration advertised by an Okta Agent Gateway. It requires curl and jq; pass the Gateway URL as an argument or set GATEWAY_URL.

For example: bash discover-agent-gateway-oauth.sh 'https://YOUR_ORG.gateway.oktapreview.com/mcp/servers/dust-gateway'. Then copy the discovered endpoints and supported scopes into Dust.

Dust Configuration

#

Now that we have the Gateway URL, the client credentials, and the correct authorization server endpoints, we can configure Dust to connect to Okta Agent Gateway.

Add the Gateway to Dust

#

Create the MCP connection

#

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

   

2. Select Add MCP Server.

   

3. Paste the Gateway MCP URL, then choose Static OAuth as the authentication method.

   

4. Complete the form using your own credentials and discovery results:

   Dust field	Value for this configuration
   URL	The full Gateway MCP URL, ending in /mcp/servers/dust-gateway
   Authentication	Static OAuth
   How do you want to connect?	Personal accounts
   OAuth Client ID	Client ID copied from the Okta AI agent’s Client registration tab
   OAuth Client Secret	The corresponding active client secret
   OAuth Token Endpoint	token_endpoint from the Gateway issuer’s discovery document
   OAuth Authorization Endpoint	authorization_endpoint from the same discovery document
   OAuth Scope(s)	openid offline_access, as advertised in this example
   OAuth Resource / Audience	Left empty in the tested configuration; see the note below
   Token Endpoint Authentication Method	Request body (client_secret_post) for the client configuration used here

   Choose Personal accounts so users establish their own connections. Dust documents that administrators still complete an initial OAuth connection during setup, followed by individual users when they first use the tool. See Personal vs Shared Credentials.

   

5. Click Setup connection and complete the initial authorization if prompted. The connection should then appear in Dust with authentication active.

   

   Resource, audience, and scopes

   Leaving Resource / Audience empty worked in this tested configuration. This is not a rule for every OAuth integration, and the advertised resource value is not automatically interchangeable with every provider-specific audience parameter.

   If your environment requires an explicit resource indicator, use the Gateway resource advertised in metadata and validate the configuration against its requirements.

   Likewise, use scopes supported by the Gateway’s authorization server. Downstream scopes such as tool:search belong to the downstream connection; do not copy them into Dust.

6. Open Tools & Stakes to confirm discovery succeeded and review the confirmation setting for each tool.

   

   In my setup, tools initially appeared as High, requiring confirmation for each execution. The UI also offered Low, which allows saved user confirmation, and Never ask, which permits automatic execution.

7. Keep confirmation enabled for consequential operations, such as creating, modifying, or deleting records. Dust’s confirmation settings control the user interaction; authorization in Okta and the downstream service remains a separate control.

Build a chatbot in Dust

#

Create a chatbot suited to the MCP tools you connected. The screenshots show a travel assistant, but the same steps apply to a repository assistant, document search, or another business workflow.

Create the chatbot and define its instructions

#

1. Open Create → From Scratch in Dust.

   

2. In Instructions, describe the chatbot’s purpose, the tools it should use, and the expected output. The screenshot shows a travel assistant; adapt its purpose and instructions to your use case:

   

   Info

   In the illustrated example, the instructions specialize the chatbot for flight search, booking, reading, modification, and cancellation. Replace that scope with your MCP’s capabilities. The prompt guides behavior; permissions must still be enforced by the connected systems.

3. Under Capabilities and knowledge, click Add Capability.

   

4. Select Dust Gateway from the available tools, then click + Add.

   

5. Confirm with Add 1 Capability.

   

6. Set the chatbot’s name, description, and visibility to match its purpose. TravelHelper is only the example name in the screenshots. Save the agent.

   

7. Click Start Chat to open a conversation.

   

Test the connection end to end

#

Start with a read-only request that matches a tool exposed by your MCP server. For example, ask a repository MCP to list accessible repositories or a document MCP to search for a document. With the example flight server shown here, I use:

Search for flights from CDG to LIN for next Thursday.

Adapt the request to your connected MCP and the permissions of your test user.

On first use, Dust asks you to connect your account to the Gateway. Click Connect Dust gateway, then complete the Okta sign-in and authorization steps required by your configuration.

This establishes the user’s OAuth connection. It is separate from simply being signed in to the Dust workspace.

Once connected, Dust calls the Gateway, which reaches the selected MCP server and returns the tool results. Here, those results are flight options.

If your MCP supports write operations, test one against disposable data and review the confirmation prompt. In the flight example, a follow-up could be:

Book the first flight, departing at 06:30.

For a different MCP, substitute an appropriate action, such as creating a test issue in GitHub.

This follow-up reused the established connection without another OAuth sign-in. That does not mean access is permanent: token expiry, refresh behavior, revocation, and policy changes can require a new connection or cause a later call to fail.

Adapt subsequent tests to your MCP’s supported operations. The flight example also supports reading, modifying, and cancelling bookings; the screenshots demonstrate only search and booking, not every tool or downstream integration.

Visibility and policy enforcement

#

Trace the agent and user in Okta

#

The useful final check is to correlate the conversation with the activity recorded in Okta.

Open the System Log and inspect events around the time of your test. The configuration shown here recorded tool calls with the event type agent_gateway.mcp.tool.call.

Here is a shortened, sanitized excerpt from the example booking event. Your MCP server will produce different tool and target names:

{
  "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"
    }
  ]
}

The event connects the tool request to its identity and execution context:

• Which agent? actor.displayName identifies Dust Agent #1.
• On behalf of whom? gatewayContext.subject identifies the user.
• Which operation? capabilityName identifies the booking tool.
• Through which connection? The targets identify the Gateway and downstream MCP server.
• What happened? The event records the outcome of the call.

For a Gateway-focused view, open Security → Agent Gateway → Dust Gateway → Recent Activity.

Okta’s Gateway activity documentation describes this view and directs administrators to the System Log for related authentication and token exchange events.¹⁴ The example above demonstrates attribution and call metadata; it should not be read as a guarantee that every tool’s complete request and response payload is logged.

Tool access policies

#

A working connection is only the starting point. Decide who can use the agent, which agent can reach the Gateway, and which tools the Gateway exposes. These controls work together, while the downstream service still enforces its own permissions.

For example, a document assistant may need search and read tools without any ability to delete documents. Here is how I would apply that boundary to this configuration:

1. Restrict user access. Assign only the intended users or groups to the linked OIDC application. On its Sign On tab, review the assigned app sign-in policy and its authentication requirements. Configure MFA and other conditions appropriate to your users.¹⁶ This governs user authentication; it does not select individual MCP tools.
2. Authorize the intended agent. In Security → Agent Gateway → Dust Gateway → AI Agents, keep only the agents that should use this endpoint. The connection is also visible under each agent’s Resource connections tab.²
3. Reduce the exposed tool set. Open Tool customization → Manage tools for each connected MCP server. Keep the required search and read operations, deselect unnecessary write or delete operations, and save.¹¹ This changes the tools exposed through the Gateway, independently of the chatbot’s instructions.
4. Test both outcomes. Refresh the tool list in Dust if needed, then confirm that an allowed request works and a removed tool is no longer available. Repeat with an unassigned test user to check the user-access boundary. Use Gateway activity and the System Log to investigate unexpected results.

Kill Switch and emergency access revocation

#

Deactivating an agent already acts as a Kill Switch: it prevents the agent from obtaining new tokens through Okta and establishing new sessions.¹⁷¹⁸ If an agent starts making unexpected calls, this gives administrators a central way to contain it across its managed connections.

For this configuration, choose the control that matches the scope of the incident:

1. Deactivate the agent. Open Directory → AI Agents → Dust Agent #1 and select Actions → Deactivate.¹⁷
2. Limit containment to one connection when appropriate. In the agent’s Resource connections tab, select Deactivate connection for the Gateway. This denies future access requests through that connection.¹⁹ To suspend the entire Gateway instead, use Security → Agent Gateway → Dust Gateway → Actions → Deactivate. This affects all agents using that endpoint.¹¹
3. Verify the result and preserve evidence. Confirm that the deactivated agent can no longer obtain a new token. Retry a harmless request from an existing Dust conversation to check the effect on already-issued tokens. Record the administrative change and review subsequent activity in the System Log and Gateway activity. For a compromised user account, also follow your user-session and credential-recovery procedure.
4. Restore access after investigation. Review the affected account, agent credentials, resource connections, and tool selection. Reactivate only the required components, then repeat the access checks.

Already-issued tokens may remain usable until their effective expiry.²⁰ The planned extension of the Kill Switch to Agent Gateway will make containment more effective by adding revocation of active tokens and termination of sessions in flight.¹⁸

The Gateway is a useful enforcement point because it sits in the path of requests to several MCP services. Keep provider-side response procedures for credentials or direct connections outside that path; stopping access cannot undo an operation already completed downstream.

Where to go from here

#

We now have a practical integration: Dust provides the conversational experience, your MCP servers provide the tools, and Okta Agent Gateway sits in the access path with an identifiable agent, user context, and observable tool activity.

What I like about this example is how little custom code the connection needs. Once the MCP server is ready, the work is mostly configuration: register the agent, assign access, select tools, and connect Dust using the correct OAuth metadata.

In the next few days, I will take a broader look at Okta Agent Gateway in a separate article, including its architecture and how the same approach applies to other agent platforms.

Are you already using Dust with enterprise tools? Which MCP integration would you put behind a Gateway first?

Share your experience or questions in the comments.