# NVIDIA DSX Exchange

> Source: https://aiwiki.ai/wiki/nvidia_dsx_exchange
> Updated: 2026-10-31
> Fact-checked: 2026-10-31
> Categories: AI Agents, AI Infrastructure, Data Centers, NVIDIA
> License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) - attribute to "AI Wiki (aiwiki.ai)"
> Cite as: AI Wiki. "NVIDIA DSX Exchange." aiwiki.ai, 31 Oct 2026. https://aiwiki.ai/wiki/nvidia_dsx_exchange
> From AI Wiki (https://aiwiki.ai), the free encyclopedia of artificial intelligence. Reuse freely with attribution.

**NVIDIA DSX Exchange** is an open-source software platform from [NVIDIA](https://aiwiki.ai/wiki/nvidia) for passing operational signals between the systems that run large AI [data centers](https://aiwiki.ai/wiki/data_center), which NVIDIA calls AI factories. It is one of the named software components of the [NVIDIA DSX](https://aiwiki.ai/wiki/nvidia_dsx) platform. NVIDIA's documentation says DSX Exchange includes three parts: the DSX Event Bus, a NATS-based message bus that speaks MQTT 3.1.1 to power, building management, cooling, grid and compute systems; AsyncAPI schemas that define the topics and payloads those systems exchange; and DSX Agent Gateway, an authenticated routing layer for [Model Context Protocol](https://aiwiki.ai/wiki/model_context_protocol) (MCP) traffic between [AI agents](https://aiwiki.ai/wiki/ai_agents) and the tools that operate the facility.[1] The code is published on GitHub under the Apache License 2.0.[2] As of 1 November 2026, NVIDIA's documentation labels DSX Exchange a developer preview and warns that its "APIs and behavior may change without notice"; NVIDIA announced DSX Agent Gateway as a developer preview on 30 October 2026.[1][3]

## Key facts

| Attribute | Detail |
| --- | --- |
| Developer | [NVIDIA](https://aiwiki.ai/wiki/nvidia) |
| Part of | [NVIDIA DSX](https://aiwiki.ai/wiki/nvidia_dsx), alongside DSX Reference Design, DSX Sim, [DSX MaxLPS](https://aiwiki.ai/wiki/nvidia_dsx_maxlps), DSX Flex and DSX OS[4] |
| First named | 28 October 2025, as one of three "pillars" of Omniverse DSX at GTC Washington, D.C.[5] |
| First open-source release | v2.5.11, which the project changelog dates 29 May 2026 and calls the initial open-source release (GitHub also lists earlier tags back to v0.0.1-rc1 of 20 May 2026)[6][7] |
| Latest release (as of 1 November 2026) | v2.11.0, published 31 October 2026 (UTC)[7] |
| License | Apache License 2.0[2] |
| Repository | github.com/dsx-ai-factory/dsx-exchange (28 stars and 18 forks as of 1 November 2026)[2] |
| Messaging core | NATS with MQTT 3.1.1, JetStream persistence and leaf-node federation[1] |
| Agent interface | DSX Agent Gateway, an MCP endpoint at `/mcp` using the Streamable HTTP transport[8][9] |
| Deployment | Helm charts on [Kubernetes](https://aiwiki.ai/wiki/kubernetes)[1] |
| Status | Developer preview; APIs and behavior may change without notice[1] |

## History

NVIDIA first used the name when it introduced the Omniverse DSX blueprint at its GTC Washington, D.C. keynote on 28 October 2025. The company's blog listed DSX Exchange, subtitled "Unified IT/OT Integration," as one of three pillars of DSX alongside DSX Flex and DSX Boost, and described it as the "secure data and control fabric" linking operational systems for power, cooling and safety with NVIDIA's software stack and [Omniverse](https://aiwiki.ai/wiki/nvidia_omniverse) [digital twins](https://aiwiki.ai/wiki/digital_twin) through real-time application programming interfaces and partner integrations.[5]

At GTC on 16 March 2026, NVIDIA's announcement of the Vera Rubin DSX AI Factory reference design listed DSX Exchange among the software libraries for partners to build on, saying it "enables scalable and secure integration of compute, network, energy, power and cooling plant signals between IT, operational technology and operations agents."[10] The press release for the unified DSX platform, dated 31 May 2026 and tied to GTC Taipei, repeated that description and listed DSX Exchange among NVIDIA's trademarks.[11] In a technical blog post published with that announcement, Warren Barkley, NVIDIA's vice president of product management for DSX, described DSX Exchange as "an MQTT-based IT/OT communication hub" that makes facility signals such as grid events, thermal data and power anomalies visible to the software managing the rest of the AI factory. He added that DSX OS components would provide [MCP servers](https://aiwiki.ai/wiki/mcp_server) so that AI agents could "discover the entire operational surface of the factory as a unified tool catalog."[12]

| Date | Event |
| --- | --- |
| 28 October 2025 | DSX Exchange named as one of three pillars of Omniverse DSX at GTC Washington, D.C.[5] |
| 16 March 2026 | Listed among the Vera Rubin DSX software libraries at GTC[10] |
| 29 May 2026 | Initial open-source release, v2.5.11, according to the project changelog[6] |
| 31 May 2026 | NVIDIA announces the DSX platform, with DSX Exchange as a named component[11] |
| 1 June 2026 | Synadia, the company behind the NATS messaging system, publishes an analysis noting that NVIDIA built the DSX Event Bus on NATS[13] |
| 2 October 2026 | Release v2.10.0 adds a weather forecast contract (v0.1.0)[7] |
| By 20 October 2026 | Release notes for NVIDIA Dynamic Power Software 0.10, a release candidate, say it adds DSX Exchange integration, including DSX Flex integration via DSX Exchange[14] |
| 30 October 2026 | NVIDIA announces DSX Agent Gateway in developer preview[3] |
| 31 October 2026 | Release v2.11.0 adds opt-in promotion of QA-approved release candidates[7] |

The project's CHANGELOG.md file has not been updated since v2.5.11 and still lists the DSX Agent Gateway bridge, Helm chart, local deployment and end-to-end validation under "Unreleased";[6] later changes are recorded in GitHub release notes, and the Agent Gateway chart has been included in tagged releases since v2.7.0 (30 July 2026).[7] Some of NVIDIA's documentation and the Agent Gateway chart metadata still point to github.com/NVIDIA/dsx-exchange; as of 1 November 2026 that address redirects to the repository in the dsx-ai-factory GitHub organization.[31][15][2]

## Design: a stateless, asynchronous bus

NVIDIA's documentation argues that polling breaks down at gigawatt scale, because every application cannot ask every other application for updates every second. DSX Exchange instead uses a push model in which a producer publishes a signal once and every interested consumer receives it. The documentation lists four principles: push rather than poll, publish once and fan out to many consumers, decouple producers from consumers, and converge on current state.[16]

Leak detection is NVIDIA's main example. When a liquid-cooled rack leaks, host management, workload migration, facility response, alerting and analysis may all need to react, and waiting for a one-minute or five-minute poll is too slow. In the bus model the building management system (BMS) publishes the leak state once when it changes, and the bus delivers it to every subscriber.[16]

The bus is "stateless by default." Messages carry current values rather than deltas (a temperature message says the temperature is 24, not that it rose by 2), sources republish current state periodically even when nothing changed, and consumers apply messages idempotently. NVIDIA presents this as a way to get eventual consistency and self-healing: a missed message, a stale cache or a consumer bug is corrected by the next publication.[16] The integrator guide states that DSX integration contracts use MQTT QoS 0, and that QoS 1 and QoS 2 remain available for MQTT clients that need them, but QoS 1, QoS 2 and retained messages "must not be required for correctness."[17] Retained messages are meant only to help new consumers start up with slow-changing context such as BMS metadata, and the documentation tells integrators to assume retained data can eventually be lost.[16]

Requests that would normally be synchronous are modeled as published intent. A requester publishes the value it wants, and the owner of that state applies its own rules and publishes the result on its normal state stream, so the requester confirms the outcome by reading the same stream as every other consumer. In NVIDIA's coolant distribution unit (CDU) example, an integration publishes a requested liquid temperature setpoint; the BMS may apply it, ignore it, clamp it to a configured range or fall back to a local default, and the BMS-published target setpoint shows what it actually chose. NVIDIA recommends direct APIs instead of the bus when a caller needs an immediate answer from one known owner, such as provisioning a machine, rebooting a known host or creating a virtual private cloud.[16]

## DSX Event Bus architecture

### Components

| Component | Description in NVIDIA's documentation |
| --- | --- |
| DSX Event Bus | NATS with MQTT 3.1.1, high-availability clustering and leaf-node federation[1] |
| DSX Agent Gateway | Authenticated MCP routing to local and remote MCP servers[1] |
| DSX Agent Gateway Bridge | Stateless cross-shard MCP routing through the DSX Event Bus[1] |
| AsyncAPI Schema | Formal topic definitions and payload contracts per service team[1] |
| Auth-Callout Service | OAuth2, mTLS and NKey authentication with topic-level access control lists[1] |

The event bus supports a three-node high-availability cluster with automatic failover, JetStream-backed persistent messaging, multi-cluster federation through leaf-node connections and declarative deployment with Helm charts that are compatible with ArgoCD.[1] The repository README describes the bus itself as schema agnostic: the schemas document externally visible contracts, while NATS and the auth-callout service enforce routing, federation and authorization.[2]

NVIDIA says it chose MQTT 3.1.1 rather than MQTT 5 because a major integration surface is building management and industrial operational technology (OT), where the industry "overwhelmingly ships MQTT 3.1.1 clients," and because NATS implements MQTT 3.1.1 only.[1] Synadia's analysis made the same point and noted that the auth-callout service is NVIDIA's own Go service built on the standard NATS Auth Callout hook.[13]

### Cluster topology and topic spaces

An AI factory deployment has one Common Services Cluster (CSC) and one or more Control Plane Clusters (CPCs). Each is a separate Kubernetes cluster running its own NATS event bus, and the CPCs federate to the CSC over NATS leaf-node connections through a controller compatible with the Kubernetes Gateway API. The reference deployment uses Envoy Gateway, though NVIDIA says any conformant controller works.[1] The default components per cluster are three main NATS replicas, one optional mTLS NATS instance, one auth-callout instance, one NACK controller for declarative JetStream stream management and one Surveyor Prometheus exporter.[1]

There are two kinds of topic space. The CSC topic space is a unified namespace visible in every cluster, with CPC prefixes in topic paths (for example `cpc.1.telemetry.temp`); each CPC also has a local namespace with unprefixed names. Three Helm configuration lists (`cpcExports`, `cscExports` and `cscPrefixedExports`) control which topics are copied between layers. The documentation warns that a subject pattern appearing in more than one list creates cyclic NATS imports that crash the NATS pod with no error at install time.[1]

MQTT topic separators (`/`) are mapped to NATS subject tokens (`.`), so the MQTT topic `telemetry/temp` becomes the NATS subject `telemetry.temp`.[1]

| Port | Protocol | Use |
| --- | --- | --- |
| 1883 | MQTT | Standard MQTT 3.1.1, with TLS terminated at Envoy[1] |
| 4222 | NATS | NATS client connections[1] |
| 7422 | NATS | Leaf-node connections for cross-cluster federation[1] |
| 8883 | MQTT | mTLS MQTT 3.1.1, with TLS passed through to the NATS pod[1] |

### Authentication

Every client connection is authenticated by the auth-callout service, a NATS Auth Callout that issues topic-level publish and subscribe permissions at connect time.[18]

| Mode | Intended clients | How identity is matched |
| --- | --- | --- |
| OAuth2 (JWT) | Software integrations, agents and MCP interfaces | Username `oauthtoken` with an access token as the password; the token is validated against the identity provider's JWKS endpoint and its `azp` or `subject` claim is matched to a permissions entry[18][17] |
| mTLS | BMS, OT and device integrations | The client certificate's Common Name, presented on port 8883[18] |
| NKey | Internal components such as leaf nodes, NACK and Surveyor; partner integrations without certificate infrastructure | NATS NKey public key[18] |
| NoAuth | Development and debugging only | Anonymous fallback permissions; NVIDIA says it should not be enabled in production[18] |

Each permissions entry places a client into a NATS account and lists the subjects it may publish and subscribe to. The service needs three NKey seeds, supplied as Kubernetes Secrets, for connecting to NATS, signing user JWTs and optionally encrypting callout responses.[18] Metrics come from Surveyor and the auth-callout service in Prometheus format, traces go through [OpenTelemetry](https://aiwiki.ai/wiki/opentelemetry) to Tempo, and dashboards use Grafana.[1]

### Signal paths NVIDIA describes

The architecture page lists four signal paths that NVIDIA says the bus enables:[1]

- BMS to Dynamic Power Software (DPS): real-time power telemetry so that DPS can close the DSX MaxLPS dynamic power allocation loop, which NVIDIA says recovers "up to 40% stranded capacity."
- BMS to the NVIDIA Infra Controller (NICo)[12]: coolant leak events so that NICo can cordon nodes and migrate workloads "in seconds, not minutes."
- Grid to DSX Flex to the scheduler: demand-response curtailment signals so that the factory can shed load within seconds.
- GPU telemetry to thermal optimization agents: real-time thermal data so that predictive agents can adjust cooling setpoints before temperature spikes.

NVIDIA's MaxLPS documentation says DSX Exchange "carries the signals" between the grid, DSX Flex, facility systems and MaxLPS, but that Exchange and Flex integration is not a prerequisite for deploying MaxLPS; for a new site it recommends planning all three together.[19] The DPS 0.10 release candidate added support for DSX Exchange integration, DSX Flex integration through DSX Exchange, and OAuth2 client-credentials authentication for the DSX Agent's MQTT connection to DSX Exchange.[14]

## Schemas and BMS integration

### AsyncAPI contracts

| Schema | Version (as of 1 November 2026) | Scope |
| --- | --- | --- |
| BMS Event Bus | 1.0.0 | Telemetry and control catalog for building management systems over MQTT, with point values and point metadata[20] |
| DSX Flex | 1.7.0 | Real-time power management and emergency control for grid events; messages use the CloudEvents 1.0.2 MQTT protocol binding in structured mode, with a JWS-signed data field[21] |
| NICo Managed Host State Event Bus | 1.0.0 | Managed host state transitions published on `NICO/v1/machine/{machineId}/state`[22] |
| Weather forecast | 0.1.0 | Added in release v2.10.0[7] |

### The BMS integration guide

NVIDIA's companion guide for system integrators and BMS contractors calls DSX Exchange "NVIDIA's IT/OT integration layer within the NVIDIA DSX Software Suite," connecting BMS data to NVIDIA software such as the cluster manager, break-fix, power capping and optimization tools, digital twins and agentic AI applications.[23] The guide's central point is that DSX Exchange defines the data contract at the MQTT layer rather than inside the BMS. The BMS can be any SCADA, PLC, DDC or controls platform suitable for a critical environment and can use any internal point naming, as long as what it publishes follows the AsyncAPI topic structure and payload format. The BMS does not have to run the broker.[23]

Every point has two message types. A Value message carries the live reading as a numeric value, a Unix timestamp in milliseconds and a quality flag; it is published on change and republished every 100 seconds, uses QoS 0 and should not be retained. A Metadata message describes the point, including engineering units, the object it belongs to and its relationships; it is published at startup and then every 100 seconds, and the broker may retain it to speed up subscriber startup. Consumers must process metadata before they can interpret values.[23] The last topic segment, `{tagPath}`, is vendor-defined and must be unique for each point; NVIDIA sets no format requirement for it.[23]

| Channel pattern | Publisher | Purpose |
| --- | --- | --- |
| `BMS/v1/PUB/Value/{objectType}/{pointType}/{tagPath}` | BMS | Live readings, status values and position feedback[23] |
| `BMS/v1/PUB/Metadata/{objectType}/{pointType}/{tagPath}` | BMS | Point descriptions: units, IDs and relationships[23] |
| `BMS/v1/{integration}/Value/{objectType}/{pointType}/{tagPath}` | IT integration | Setpoint requests, control signals or other data written back to the BMS[23] |

The BMS publishes all metadata, including metadata for points whose values are written by IT integrations, and the guide says these rules are intended to be enforced through access control lists on the bus. In the guide's example, an AI agent called MEPAI computes an optimal CDU supply temperature and publishes a setpoint request on a topic derived from the BMS-published metadata. The guide says the BMS "is always the authority" on whether to apply such a request, recommends validating it against safety guardrails such as minimum and maximum limits and rate-of-change limits, and recommends reverting to a safe default if the integration stops publishing or sends an out-of-range value.[23]

The guide defines 23 object types: Rack, PowerMeter, CDU, CoolingTower, HX (heat exchangers, including dry coolers), CRAH, CRAC, AHU, Chiller, Tank, Valve, Pump, Fan, Damper, Sensor, BESS, UPS, ATS, Generator, Shunt, Breaker, System and GenericObject. It calls Rack the most important, with standardized point types for rack liquid and power conditions such as supply and return temperature, flow, differential pressure, power, leak detection and isolation status. Two Rack point types, RackLiquidIsolationRequest and RackElectricalIsolationRequest, are actionable requests from IT systems that the BMS is expected to act on according to the NVIDIA Controls and Monitoring Reference Design.[23] The guide treats that reference design plus the guide as covering about "99%" of a BMS publication, with the rest coming from specifications for each active integration on a deployment.[23]

## Deployment and validation

The DSX Event Bus is deployed per Kubernetes cluster with Helm, CSC first and then the CPCs. For evaluation, a `make test` target creates a local Kind cluster with a working event bus in about 10 minutes;[24] NVIDIA estimates that the production path, including the secrets pipeline and certificates, takes 4 to 6 hours for a first-time deployment across one CSC and two CPCs.[25] Production prerequisites include Kubernetes 1.27 or later, Envoy Gateway 1.5 or later (or a compatible Gateway API controller), MetalLB 0.13 or later (or a cloud load balancer), cert-manager, the Prometheus Operator, an OIDC provider such as Keycloak if OAuth2 is used, and a secrets pipeline that produces Kubernetes Secrets.[24] The auth-callout container image is not published to a public registry, so operators build it from source and push it to their own registry.[25] Release candidates of the charts and images are published to NVIDIA's NGC registry.[26]

The repository's functional test suites cover MQTT 3.1.1 compliance, QoS 0, 1 and 2 delivery, retained and will messages, failover, CPC-to-CSC federation, OAuth2, mTLS and NKey authentication, and topic-based access control. The local environment also includes MQTT benchmark tooling; NVIDIA says these runs report the observed behavior of a given deployment and "do not define product targets."[27]

## DSX Agent Gateway

DSX Agent Gateway provides a single authenticated, tenant-aware `/mcp` endpoint through which MCP clients discover and call approved MCP servers.[8] NVIDIA's documentation lists its uses as offering one endpoint for many MCP servers, deriving tenant identity from verified JSON Web Token (JWT) claims, limiting each tenant to an approved set of targets, applying per-tenant request limits, discovering MCP servers from Kubernetes Services or static HTTP endpoints, routing selected requests to remote gateway shards, and monitoring the whole path. The gateway does not replace authorization inside an MCP server: it forwards the caller's bearer token so that the server can enforce its own policy.[8] Operators deploy the gateway; operators can reach every MCP server, while tenants reach the subset their policy allows.[8]

Agent Gateway can be deployed without the DSX Event Bus when the gateway can reach every MCP target. The event bus becomes a runtime dependency only when the optional bridge is enabled.[8]

### Components

| Component | Responsibility |
| --- | --- |
| Operator-owned edge | Terminates external TLS and routes HTTP traffic to the gateway Service[28] |
| Agent Gateway controller | Programs gateway resources from Kubernetes Gateway API and Agent Gateway custom resources[28] |
| Agent Gateway dataplane | Accepts `/mcp` traffic and applies authentication, authorization, rate limiting and target routing[28] |
| Rate-limit service | Evaluates request limits with counters keyed by the verified tenant ID[28] |
| Valkey | Stores counters for the bundled rate-limit service[28] |
| MCP target | Serves MCP through a discovered Kubernetes Service or a configured static endpoint[28] |
| Bridge hub | Exposes reachable shards and routes selected MCP requests through NATS[28] |
| Bridge leaf | Receives work for one shard and forwards it through that shard's local gateway[28] |
| DSX Event Bus | Provides NATS request-reply transport for the optional bridge[28] |

By default the chart runs three dataplane replicas, two rate-limit replicas, two replicas of an enabled bridge, one controller and a bundled Valkey with one primary and two replicas.[29]

### Request flow and tenant isolation

For a direct request, the edge forwards the HTTP request to the gateway's `/mcp` route. The dataplane verifies the JWT's issuer, audience, signature and validity against a configured provider, and a Common Expression Language (CEL) expression derives a nonempty tenant ID from the verified claims. The rate-limit service then applies that tenant's request budget, MCP authorization lets the operator tenant use all targets and limits every other tenant to configured target names, and the dataplane forwards the caller's original bearer token to the selected server, which applies its own authorization.[28]

The chart rejects a tenant expression that reads request headers or does not reference verified `jwt.*` claims, so caller-supplied identity headers cannot set the tenant used for authorization or rate limiting. At least one JWT provider is required, each with a unique issuer, one or more allowed audiences, a JWKS URL and its own tenant expression.[28] The gateway also strips caller-supplied internal identity and rate-limit headers, filters catalogs by tenant, and does not show target names to unauthenticated requests.[30]

The default rate limit is 30 requests per second per tenant, with per-tenant overrides or unlimited tenants available. The default failure mode is `FailOpen`: if the rate-limit service or Valkey fails, requests continue without limit enforcement until the dependency recovers. Operators can choose `FailClosed` instead.[31][30]

### Target discovery

A selector target discovers Kubernetes Services by namespace and labels; each selected Service exposes a named port with `appProtocol: agentgateway.dev/mcp`, and the target name is formed from the Service name and port name (for example `inventory-mcp`). A static target points to a configured HTTP or HTTPS MCP endpoint and may use the Streamable HTTP transport or legacy Server-Sent Events (SSE).[32][31] When the gateway aggregates several targets, tool and prompt names are published as `<target>_<name>`, and resource identifiers carry the target before the URI, as in `inventory-mcp+inventory://servers/42`. An unavailable target is omitted from catalogs while healthy targets stay available.[30]

### Bridge routing across shards

A shard is a deployment domain with its own Agent Gateway and MCP servers, typically a Kubernetes cluster or a logical site. With the optional bridge, an entry gateway routes to a bridge hub, and bridge leaves in each remote shard forward requests through their local gateway, using NATS request-reply traffic on the DSX Event Bus.[8] Clients can call a bridge-provided `dsx_bridge_list_shards` tool to find reachable shards; the hub adds a required `shard_id` input to bridged tools and prompts and removes it before publishing the call to the chosen shard. The gateway in that shard repeats JWT verification, tenant derivation, authorization and rate limiting, and the bridge preserves the caller's `Authorization` header.[28]

Bridged requests are stateless. The hub and leaves remove the `Mcp-Session-Id` header, the hub handles `initialize` and `ping` itself, and methods that need server-side MCP session state, client state or resource-path routing are unavailable.[28] The bridge supports JSON and streamed SSE responses, and it does not retry an initial invocation after an ambiguous missing reply, which NVIDIA says prevents automatic replay of tool calls with side effects.[30]

| MCP capability | Direct target | Bridge target |
| --- | --- | --- |
| `initialize`, `ping` | Supported | Handled by the hub[30] |
| `tools/list`, `tools/call` | Supported, with tenant filtering and target-qualified names | Supported, with an explicit `shard_id`[30] |
| `prompts/list`, `prompts/get`, prompt completion | Supported (completion when the target advertises it) | Supported, with an explicit `shard_id`[30] |
| `resources/list`, `resources/templates/list`, `resources/read` | Supported when the target advertises resources | Not supported[30] |
| Stateful resource methods | Not in the supported profile | Not supported[30] |

### Network boundary and deployment

The chart creates a Kubernetes Gateway listener on plaintext HTTP port 80, with a `ClusterIP` Service by default and `NodePort` as the only other option. It does not create external certificates, cert-manager resources or a `LoadBalancer` Service: the operator owns the external edge, TLS termination and public address. Selector targets and bridge leaf-to-gateway traffic use HTTP inside the cluster, while HTTPS static targets get TLS from the gateway.[28] Installation requires Kubernetes Gateway API v1.5.1 custom resource definitions and Agent Gateway v1.4.1 custom resource definitions, a reachable JWKS endpoint for each JWT provider, and an external edge that can route HTTPS to the gateway Service.[33]

DSX Agent Gateway is built on the open-source Agentgateway project: its controller and dataplane come from the upstream `agentgateway` chart, which NVIDIA's chart wraps. The `dsx-agent-gateway` Helm chart (version 0.3.0 as of 1 November 2026) describes itself as an "Agentgateway deployment chart with optional dsx-agentgateway-bridge routing, rate limiting, observability, and defaults." It pins the `agentgateway` chart v1.4.1 from the cr.agentgateway.dev registry and the Valkey chart 0.9.4 as dependencies.[15] The repository README says "Upstream Agentgateway routes authenticated MCP requests to local MCP servers," while NVIDIA's own `dsx-agentgateway-bridge` adds remote discovery and request routing over the DSX Event Bus.[2]

For clients, NVIDIA's quickstart uses the Streamable HTTP transport at `/mcp` with a bearer token from a configured JWT provider, and suggests MCP Inspector for interactive testing.[9] The supported observability profile includes health endpoints, Prometheus metrics, structured logs, OpenTelemetry trace propagation and optional alert rules.[30]

## Limitations and caveats

- **Preview status.** DSX Exchange is a developer preview, and NVIDIA says its APIs and behavior may change without notice.[1] NVIDIA's DSX press release also says many of the products and features it describes "will be offered on a when-and-if-available basis."[11]
- **Rate limits can lapse.** With the default `FailOpen` setting, tenant limits go unenforced while the rate-limit service or Valkey is down.[30]
- **Authorization is shared.** The gateway authorizes access to MCP targets, but the selected MCP server remains responsible for operation-level authorization.[30]
- **The bridge is a subset of MCP.** Resource methods and anything that depends on server-side session state are unavailable on bridged requests.[30]
- **Delivery guarantees.** Integrations are expected to use QoS 0 and periodic republishing; higher QoS levels and retained messages are not meant to guarantee correctness.[17]
- **Configuration hazards.** Overlapping cross-layer export lists crash the NATS pod without an install-time error, and missing JWKS settings on a cluster cause its auth-callout to reject all OAuth2 connections silently.[1][18]

## See also

- [NVIDIA DSX](https://aiwiki.ai/wiki/nvidia_dsx)
- [NVIDIA DSX MaxLPS](https://aiwiki.ai/wiki/nvidia_dsx_maxlps)
- [NVIDIA DSX POD](https://aiwiki.ai/wiki/nvidia_dsx_pod)
- [Model Context Protocol](https://aiwiki.ai/wiki/model_context_protocol)
- [MCP server](https://aiwiki.ai/wiki/mcp_server)
- [Kubernetes](https://aiwiki.ai/wiki/kubernetes)
- [NVIDIA Omniverse](https://aiwiki.ai/wiki/nvidia_omniverse)

## References

1. NVIDIA. "Architecture." DSX Exchange documentation (developer preview). Accessed November 1, 2026. https://docs.nvidia.com/dsx-exchange/architecture
2. NVIDIA (dsx-ai-factory). "dsx-exchange" GitHub repository and README. Accessed November 1, 2026. https://github.com/dsx-ai-factory/dsx-exchange
3. NVIDIA AI Infrastructure (@NVIDIAAIInfra). Post announcing DSX Agent Gateway. X, October 30, 2026. https://x.com/NVIDIAAIInfra/status/2116225660246986976
4. NVIDIA. "NVIDIA DSX Platform." Product page. Accessed November 1, 2026. https://www.nvidia.com/en-us/data-center/products/dsx/
5. James Mills. "NVIDIA Launches Omniverse DSX Blueprint, Enabling Global AI Infrastructure Ecosystem to Build Gigawatt-Scale AI Factories." NVIDIA Blog, October 28, 2025. https://blogs.nvidia.com/blog/omniverse-dsx-blueprint/
6. NVIDIA (dsx-ai-factory). "CHANGELOG.md." dsx-exchange repository. Accessed November 1, 2026. https://github.com/dsx-ai-factory/dsx-exchange/blob/main/CHANGELOG.md
7. NVIDIA (dsx-ai-factory). "Releases." dsx-exchange repository (v2.10.0, October 2, 2026; v2.11.0, October 31, 2026). Accessed November 1, 2026. https://github.com/dsx-ai-factory/dsx-exchange/releases
8. NVIDIA. "DSX Agent Gateway Overview." DSX Exchange documentation. Accessed November 1, 2026. https://docs.nvidia.com/dsx-exchange/agent-gateway
9. NVIDIA. "MCP Client Quickstart." DSX Exchange documentation. Accessed November 1, 2026. https://docs.nvidia.com/dsx-exchange/agent-gateway/client-quickstart
10. NVIDIA Newsroom. "NVIDIA Releases Vera Rubin DSX AI Factory Reference Design and Omniverse DSX Digital Twin Blueprint With Broad Industry Support." March 16, 2026. https://nvidianews.nvidia.com/news/nvidia-releases-vera-rubin-dsx-ai-factory-reference-design-and-omniverse-dsx-digital-twin-blueprint-with-broad-industry-support
11. NVIDIA Newsroom. "NVIDIA DSX Gives Infrastructure Builders the Playbook for AI Factories." May 31, 2026. https://nvidianews.nvidia.com/news/dsx-infrastructure-ai-factory
12. Warren Barkley. "NVIDIA DSX OS Delivers Open, Modular Software for Operating AI Factories at Scale." NVIDIA Technical Blog, May 31, 2026. https://developer.nvidia.com/blog/nvidia-dsx-os-delivers-open-modular-software-for-operating-ai-factories-at-scale/
13. Andrew Connolly. "NVIDIA Built Its AI Factory Event Bus on NATS." Synadia blog, June 1, 2026. https://www.synadia.com/blog/nvidia-built-its-ai-factory-event-bus-on-nats
14. NVIDIA. "DPS 0.10 Release Notes." NVIDIA Dynamic Power Software documentation. Last updated October 20, 2026. https://docs.nvidia.com/datacenter/dps/versions/0.10/release-notes/0.10.x/index.html
15. NVIDIA (dsx-ai-factory). "deploy/dsx-agent-gateway/Chart.yaml." dsx-exchange repository. Accessed November 1, 2026. https://github.com/dsx-ai-factory/dsx-exchange/blob/main/deploy/dsx-agent-gateway/Chart.yaml
16. NVIDIA. "Why a Message Bus - Stateless Async." DSX Exchange documentation. Accessed November 1, 2026. https://docs.nvidia.com/dsx-exchange/stateless-async-bus
17. NVIDIA. "Integrator Quickstart." DSX Exchange documentation. Accessed November 1, 2026. https://docs.nvidia.com/dsx-exchange/integrator-quickstart
18. NVIDIA. "Authentication." DSX Exchange documentation. Accessed November 1, 2026. https://docs.nvidia.com/dsx-exchange/authentication
19. NVIDIA. "NVIDIA DSX MaxLPS Overview." NVIDIA DSX documentation. Accessed November 1, 2026. https://docs.nvidia.com/dsx/maxlps/overview
20. NVIDIA. "BMS Event Bus 1.0.0" (AsyncAPI schema overview). DSX Exchange documentation. Accessed November 1, 2026. https://docs.nvidia.com/dsx-exchange/schema/bms-event-bus/overview
21. NVIDIA. "DSX Flex 1.7.0" (AsyncAPI schema overview). DSX Exchange documentation. Accessed November 1, 2026. https://docs.nvidia.com/dsx-exchange/schema/dsx-flex/overview
22. NVIDIA. "NICo Managed Host State Event Bus 1.0.0" (AsyncAPI schema overview). DSX Exchange documentation. Accessed November 1, 2026. https://docs.nvidia.com/dsx-exchange/schema/nico/overview
23. NVIDIA. "BMS Integration Companion Guide." DSX Exchange documentation. Accessed November 1, 2026. https://docs.nvidia.com/dsx-exchange/bms-integration
24. NVIDIA. "Deployment." DSX Exchange documentation. Accessed November 1, 2026. https://docs.nvidia.com/dsx-exchange/deployment
25. NVIDIA. "Pre-Deployment." DSX Exchange documentation. Accessed November 1, 2026. https://docs.nvidia.com/dsx-exchange/pre-deployment
26. NVIDIA. "Deploying Release Candidates." DSX Exchange documentation. Accessed November 1, 2026. https://docs.nvidia.com/dsx-exchange/release-candidates
27. NVIDIA. "Validation." DSX Exchange documentation. Accessed November 1, 2026. https://docs.nvidia.com/dsx-exchange/validated-capabilities
28. NVIDIA. "DSX Agent Gateway Architecture." DSX Exchange documentation. Accessed November 1, 2026. https://docs.nvidia.com/dsx-exchange/agent-gateway/architecture
29. NVIDIA. "Operate DSX Agent Gateway." DSX Exchange documentation. Accessed November 1, 2026. https://docs.nvidia.com/dsx-exchange/agent-gateway/operations
30. NVIDIA. "Supported Capabilities." DSX Agent Gateway documentation. Accessed November 1, 2026. https://docs.nvidia.com/dsx-exchange/agent-gateway/supported-capabilities
31. NVIDIA. "Configuration Reference." DSX Agent Gateway documentation. Accessed November 1, 2026. https://docs.nvidia.com/dsx-exchange/agent-gateway/configuration-reference
32. NVIDIA. "Publish an MCP Server." DSX Agent Gateway documentation. Accessed November 1, 2026. https://docs.nvidia.com/dsx-exchange/agent-gateway/publish-mcp-server
33. NVIDIA. "Deploy DSX Agent Gateway." DSX Agent Gateway documentation. Accessed November 1, 2026. https://docs.nvidia.com/dsx-exchange/agent-gateway/deployment