Skip to content

XTM Suite integration

XTM One is the AI layer of the Filigran XTM Suite. This page covers the technical wiring that connects XTM One to the other Suite products — OpenCTI, OpenAEV, and OpenGRC — from a deployment and operations point of view.

For the end-user experience of these features, see XTM One in the XTM Suite. For connecting external MCP clients, see Platform MCP servers.

How the products connect

Each Suite platform registers itself with XTM One. Once registered, the platform can surface the embedded "Ask AI" experience, and XTM One can call back into the platform on behalf of the requesting user.

flowchart LR
    subgraph suite["Other XTM Suite products"]
        direction TB
        octi["OpenCTI"]
        oaev["OpenAEV"]
        ogrc["OpenGRC"]
    end

    xtmone["XTM One"]
    client["External MCP client<br/>Cursor, Claude, ..."]

    suite -->|"1 · Registers"| xtmone
    suite -->|"2 · Embeds assistant"| xtmone
    xtmone -->|"3 · Reads &amp; updates data"| suite
    client -->|"4 · Uses tools via MCP"| xtmone

The diagram shows four ways XTM One and the Suite products work together:

  1. Registration — each platform registers with XTM One at POST /api/v1/platform/register, authorized by the shared PLATFORM_REGISTRATION_TOKEN (see below). This one-time handshake enables everything else.
  2. Embedded AI assistant — once registered, OpenCTI, OpenAEV, and OpenGRC surface an in-product AI assistant. The platform streams each request to XTM One over HTTP with Server-Sent Events (/api/v1/platform/chat).
  3. Reads & updates platform data — to answer, XTM One calls the platform's own GraphQL / REST API. Every call runs as the signed-in user: XTM One signs a short-lived per-user token that the platform verifies against XTM One's public keys at GET /xtm/auth/jwks, so each user's permissions and audit trail apply exactly as if they acted directly (see Acting as the user).
  4. Platform tools over MCP — connecting a platform also exposes its native tools to external MCP clients (Cursor, Claude, custom agents) through XTM One at /mcp/opencti, /mcp/openaev, and /mcp/opengrc. This is a separate capability from the in-product assistant — see Platform MCP servers.

Registration is authorized by a shared token:

Variable Where it is set Purpose
PLATFORM_REGISTRATION_TOKEN XTM One and each Suite platform Shared secret authorizing a platform to register. Must be identical across all services.

Use the same token everywhere

Every product that registers with XTM One must use the exact same PLATFORM_REGISTRATION_TOKEN. The default value in .env.sample is a placeholder — set a strong shared secret before connecting production instances.

Once a platform is registered, its native capabilities become available automatically — including the platform MCP servers (/mcp/opencti, /mcp/openaev, /mcp/opengrc), which activate as soon as the corresponding platform is connected.

Under construction

The exact registration procedure on the OpenCTI / OpenAEV / OpenGRC side (which settings to fill, in which UI or configuration file, and how to verify a successful registration from XTM One) is being documented and will be added here.

Network reachability

XTM One calls the registered platform's API when an agent works with its data. By default it uses the public platform_url supplied during registration.

For deployments where XTM One and the platforms share an internal network, you can override the API URL XTM One calls:

Variable Effect
OPENCTI_API_URL Call the OpenCTI API on this internal URL instead of the registered public URL
OPENAEV_API_URL Same, for OpenAEV
OPENGRC_API_URL Same, for OpenGRC

Deep links follow the API URL

When an internal API URL override is active, the "Open in …" deep links XTM One generates are currently built from the same URL, so they point at the internal host. If your users rely on deep links, prefer making the public URL reachable from XTM One instead of setting an override.

Acting as the user

When a Suite platform calls XTM One (or when a request from XTM One calls back into a platform), the action runs as the requesting user, not as a shared service account.

XTM One signs a short-lived, per-user token that the platform verifies. Users are matched by email between the two products, so each user's platform permissions, data markings, and audit trail apply exactly as if they acted directly. Platform API tokens are never stored in or proxied through XTM One.

The public keys used to verify these tokens are served from XTM One:

Endpoint Purpose
GET /xtm/auth/jwks Public JWKS keys for verifying XTM One's cross-platform tokens (unauthenticated, public)

Under construction

The cross-platform token verification setup on the platform side — including how each platform is configured to trust XTM One's JWKS endpoint and how key rotation is handled — is being documented and will be added here.

Verifying the integration

After registering a platform, confirm the connection from XTM One:

  • The platform MCP server for that product reports Connected in My Profile → MCP Endpoint (and in Settings → MCP Endpoint for admins).
  • The embedded "Ask AI" experience appears inside the registered product.

If a platform shows as not connected, see the platform MCP troubleshooting table and the general Troubleshooting page.

Next step

Review Data flow to understand how cross-product requests are processed, and AI governance for what is shared with AI providers.