Integrating with Your Environment
Stealthium is built to be a piece of your security stack, not a replacement for it. It does one thing deeply — turn GPU and host telemetry into security findings and fleet metrics — and then hands that signal off to the systems where your team already lives: the SIEM your SOC watches, the SOAR playbooks that drive response, the observability platform your SREs trust, the chat channel your on-call sees first.
This page explains how Stealthium plugs into the rest of that picture, the shape of the data it sends, and how to think about wiring it in so its signal lands where your team will actually act on it.
The philosophy: be a good source, not another silo
Every tool a security team adds is another console to watch, another set of credentials, another place an alert can sit unread. Stealthium is designed to avoid that tax. Rather than asking your team to come to Stealthium, Stealthium comes to them — it exports its output into the tooling you've already standardized on.
That means Stealthium should slot into workflows you already have:
- Detection and triage happen wherever you already correlate signals — your SIEM or security data lake. Stealthium becomes one more high-signal source feeding it.
- Response and orchestration stay in your SOAR / ticketing / on-call tooling. A Stealthium finding can open an incident, page a responder, or kick off a playbook the same way any other source does.
- Operations and capacity live in your observability stack. Stealthium's fleet metrics flow alongside the GPU and host metrics your infrastructure team is already graphing.
Stealthium still provides its own API and views for when you want to look at the source of truth directly (see the API Reference) — but it never requires you to, because the signal is mirrored into your environment.
Meeting AI-driven workflows where they are
Security work is increasingly done with an AI assistant in the loop — triaging an alert, asking "how many criticals on this fleet in the last day?", or pulling the context around a finding without hand-writing an API call. Stealthium meets those workflows directly through a Model Context Protocol (MCP) server.
MCP is an open standard for connecting AI assistants and agents to external systems. Stealthium's MCP server exposes its findings as a small set of tools that any MCP-compatible client — an IDE assistant, a chat agent, or a custom autonomous workflow — can call in natural language:
- List the scopes you can see (customers, workspaces, API keys) so a query can be aimed at the right fleet.
- Browse and filter alerts by severity, type, state, host, text, and time window.
- Summarize alerts into counts by severity, type, and state for "how many" and breakdown questions.
- Pull the full detail of a single alert — its resource context, correlated alerts, and optional process-level event timeline.
The result is that the same findings your SOC sees in its SIEM are also directly queryable by the AI tooling your team is starting to build investigations and runbooks around — without scraping a UI or gluing together bespoke API calls.
Two streams of signal
Stealthium emits two distinct kinds of output, and they're meant for two different parts of your organization. Keeping them separate is deliberate: it lets security routing and operational routing evolve independently.
| Stream | What it is | Who consumes it | Typical destination |
|---|---|---|---|
| Alerts | Discrete security and fault findings raised by the detectors — each with a stable type, severity, and the context behind it. | SOC analysts, threat hunters, incident responders. | SIEM, security data lake, SOAR, ticketing. |
| Metrics | Numeric GPU-fleet and host measurements, sampled on a rolling ~15-second cadence. | SREs, platform and infrastructure teams. | Observability / metrics platform, dashboards, infra alerting. |
For the full catalog of what flows through each stream, see the Alert Types Reference and the Metrics Reference.
Built on open standards
Stealthium connects to the rest of your environment over the protocols those tools already speak — not bespoke connectors that lock you to one vendor. The core transports are open and widely supported:
- OpenTelemetry (OTLP) — metrics over HTTP or gRPC to any OTLP-compatible endpoint, including an OpenTelemetry Collector you run yourself. If your observability platform can receive OTLP, it can receive Stealthium's metrics.
- Prometheus — metrics pushed to a Prometheus Pushgateway, so anything in the Prometheus ecosystem can scrape and store them.
- HTTP event ingest — alerts delivered as structured events to log- and event-ingest endpoints.
Because the foundation is standards-based, integrating is less about a specific product and more about a shared protocol: if your platform speaks OTLP, Prometheus, or HTTP event ingest, Stealthium can feed it. If your stack relies on a standard we don't cover yet, let us know — the protocols we support are driven by what teams ask for, and we're always looking to add the ones that help Stealthium fit in more places.
Metrics are exported with a consistent, vendor-neutral schema: every series is
named stealthium_<domain>_<name> and carries per-host and per-GPU labels, so it
lands as first-class data in whatever system receives it. The details are in the
Metrics Reference.
Supported destinations
The destinations below are the ones Stealthium can target out of the box today. This list is a reflection of which protocols and ingest APIs we've built first — not an endorsement or recommendation of any product. Pick whatever your team already runs; if it speaks one of the standards above, Stealthium can feed it.
| Destination | Stream | How it connects |
|---|---|---|
| OpenTelemetry endpoint / Collector | Metrics | OTLP over HTTP or gRPC |
| Prometheus Pushgateway | Metrics | Prometheus push (Basic Auth optional) |
| Splunk | Alerts | HTTP event ingest |
| Microsoft Sentinel | Alerts | Log ingestion API |
| Axiom | Alerts & Metrics | Event ingest / OTLP |
If the platform you want to send to isn't listed but speaks OTLP, Prometheus, or a generic HTTP event-ingest API, reach out — adding a destination is usually a matter of mapping to a protocol we already support rather than building from scratch.
How routing works
Export configuration is built around the workspace. An exporter is a configured destination — a type (which protocol to speak) plus the credentials and endpoint for one place to send data. Exporters belong to a workspace: any member can manage and reuse them, and their lifetime is tied to the workspace rather than to the individual who created them.
A workspace's exporters receive the output of the fleets in that workspace. When telemetry from the workspace's agents produces alerts and metrics, that output is routed to the workspace's exporters by stream — alerts to the alert destinations, metrics to the metric destinations. A workspace can have several exporters, so the same findings can fan out to more than one place at once (a SIEM and a chat channel, say).
Because routing follows the workspace boundary, you separate destinations by organizing fleets into workspaces. A business unit that needs its own findings in its own SIEM gets its own workspace and its own exporter; a workspace that spans your whole fleet can forward everything to a single shared observability platform.
Setting up a destination
Wiring in a new destination follows the same path regardless of type:
- Create the exporter in the workspace you want to forward from, choosing its type and supplying the endpoint and credentials it needs. Credentials are validated on creation and stored encrypted.
- Test the connection. Stealthium can send a sample payload to confirm the endpoint and credentials work before real findings depend on it — so a typo'd token surfaces immediately, not during an incident.
- Activate or pause it. An exporter has an active/inactive state. Once active, the workspace's alerts and metrics route to it automatically; pause it to temporarily stop forwarding (for maintenance on the receiving side, say) without deleting the configuration.
All of this is managed through the API; see the API Reference for the exporter endpoints.
Where Stealthium fits in the team
A few common shapes for how the two streams land in a security organization:
- The SOC subscribes to Stealthium's alert stream in the SIEM, where it sits alongside endpoint, network, and identity signals. Stealthium's stable alert types and split security/observability severities (detailed in the Alert Types Reference) make it straightforward to build correlation rules and route by severity.
- Incident response treats a high-severity Stealthium finding like any other trigger: it opens a ticket or pages on-call through the same SOAR / orchestration path the rest of the stack uses. Nothing about Stealthium's response workflow is special — that's the point.
- Threat hunting queries Stealthium findings in the data lake or SIEM next to raw telemetry, pivoting on host, GPU, and time to chase a hypothesis across sources.
- Platform and SRE teams graph Stealthium's fleet metrics in the same dashboards as their existing GPU and host telemetry, and wire the operational (health/fault) findings into their infrastructure alerting — so a failing GPU shows up where the team already watches for capacity and reliability problems.
The throughline: Stealthium contributes a high-quality, GPU-native signal to the systems your team already trusts, and gets out of the way of the workflows you've already built around them.