We’ll stand it up with you on one 30-minute call.
One VM. One compose file. Your agents keep doing what they do – RAXE starts writing down what that actually is, from coding-agent sessions to agent activity in your AWS accounts, with the first agent sessions visible in the console the same day. Self-hosted in your environment, observe-first: nothing about your agents’ behaviour changes – requests flow exactly as before.
Prefer to run it yourself? The compose bundle ships through early-access onboarding, and the docs are open at docs.raxe.ai.
What runs where
Six containers in one Docker Compose stack – gateway, scoring, collector, and a three-container console (the Lens UI, its projection pump, and ClickHouse) – plus an optional host sensor where your agents run and an optional AWS reader watching your cloud account. No managed control plane, no vendor cloud – every container is yours.
Gateway – records what agents claim
An LLM traffic proxy. Point your apps at it with a base-URL change; it records what each agent says it’s doing – prompts, tool calls, responses – and passes traffic through. This is the “Gateway Claim” side of the story.
Scoring – the detection engine
Five signals – ATLAS + ASI-mapped rules, an ML text scorer, structured tool-call risk analysis, the agent behaviour graph, and an opt-in advisory LLM judge – produce one explainable verdict. All of it runs locally, on CPU.
Collector – evidence intake
Receives signed events and evidence from every producer, and seals sensitive fields by default before anything is stored. No sensitive field lands in the console unsealed.
Console UI – RAXE Lineage Lens
The RAXE console: one triage queue for every agent surface. Cross-source timelines, sealed evidence with audited reveal, and the hash-chained audit ledger you can verify on demand.
Projection pump – feeds the console
Moves sealed events from the collector into the console’s datastore, keeping the triage queue and timelines current.
Console datastore – local ClickHouse
The console’s own database, on your disk: events, timelines, the agent behaviour graph, and the hash-chained audit ledger all live here – nowhere else.
Host sensor – records what agents actually do
Optional, and the reason to bother: a kernel-level eBPF sensor, installed as a systemd
unit on hosts where agents run. It catches in-process file and secret access –
an agent reading /etc/passwd, say – invisible to proxies and logs,
pinned to the exact agent session. This is “Kernel Reality”.
AWS reader – watches your cloud account
Optional: a read-only role over your CloudTrail, running inside your boundary – your cloud logs are never shipped to RAXE. Agent activity in AWS – an agent role reading a secret, say – raises detections in the same queue, correlated to agent sessions (correlation, not exact attribution). Bedrock AgentCore telemetry joins the same timeline. Early access – see Agents on AWS.
Day one: observe and log. Nothing breaks.
RAXE deploys observe-and-log. It records and detects; requests flow exactly as before. That makes the rollout boring – which is the point.
Stand up the stack
docker compose up -d on one VM. Six containers come up; the console
mints its own access token and TLS certificate. No agent, app, or pipeline needs to
know it exists yet.
Point one producer at it
A base-URL change for the gateway, one import for the Python SDK – or point the CloudTrail reader at one AWS account, read-only, from inside your environment. Coding-agent sessions from Claude Code and OpenCode appear automatically, each pinned to its session. Your first real detections land in the console the same day.
Triage what you see
The console fills with what your agents are actually doing – gateway claims, SDK events, and, where the host sensor runs, kernel reality. Every would-block decision is logged with evidence, so you see what would have been stopped without anything being stopped.
Connect your cloud
Grant the AWS reader a read-only role over CloudTrail in one account. Cloud detections – an agent role reading a secret becomes a data-exfiltration alert – land in the same queue, correlated to agent sessions and labelled as correlation, not exact attribution. Early access – see Agents on AWS.
Widen the aperture
Add the host sensor to more machines and put sealed evidence in front of your security review. Today it lets you see it. Next, it lets you stop it.
What you need
One Linux VM
Docker and Docker Compose. The core stack is a handful of containers and runs on CPU – no GPU required. A modest VM is enough to evaluate with real traffic.
Honest sizing
We don’t publish sizing numbers we haven’t earned. For your traffic profile, we’ll size it with you on a walkthrough call rather than hand you a table we made up.
Local latency
Fast rules answer in single-digit milliseconds; the full multi-signal verdict in ~150 ms – all local. No round-trip to anyone’s cloud.
Host sensor (optional)
A modern Linux kernel with eBPF support and systemd on the hosts you want kernel-level visibility from. Installed as a systemd unit; removed the same way. Rolling out to a fleet is the same unit repeated – ship it with the configuration management you already use.
AWS cloud (optional)
A read-only IAM role over CloudTrail in the accounts you want watched. The reader runs inside your boundary alongside the rest of the stack – your cloud logs are never shipped to RAXE. Early access – Agents on AWS.
Your boundary. Your evidence.
Self-hosted in your environment
VPC or on-prem – the whole stack runs inside your boundary. There is no vendor scanning cloud: prompts and detections stay with you.
Evidence sealed by default
Sensitive fields are sealed before storage and stay sealed until an analyst supplies a purpose and clicks Reveal. Each reveal writes its own audit row – actor, field, outcome.
Tamper-evident audit ledger
Every reveal and access lands in a hash-chained ledger. Verify the whole chain on demand and the console answers with one word: Intact.
Absolutes deserve footnotes: the metadata telemetry the platform emits is documented, in full, on our trust page.
What you won’t get yet
You’re going to ask anyway. Here’s the list up front.
No blocking today
RAXE deploys observe-and-log. It records and detects; it does not block. Every would-block decision is logged with evidence, so the record of what an intervention would have caught builds from day one. Today it lets you see it. Next, it lets you stop it.
Codex attribution is inferred
Claude Code and OpenCode are watched live with explicit session attribution. Codex sessions arrive via ingest and are labelled INFERRED in the console – we don’t dress that up as something it isn’t.
AWS is correlation, not exact attribution
CloudTrail detection ties cloud activity – an agent role reading a secret, for instance – to agent sessions by correlation. The console labels it that way.
Kubernetes is roadmap
Docker Compose + systemd + Python SDK are the validated shapes today. DaemonSet and sidecar deployment for K8s clusters are on the roadmap, not on this page.
The advisory judge never decides
The opt-in LLM judge is evidence, never authority – it never changes the verdict. If you want a second opinion on borderline text, turn it on; if you want a different decision, it can’t give you one.
The uninstall path
A tool you can’t remove cleanly is a tool you shouldn’t install. This is the whole procedure.
docker compose down -v # removes containers and named volumes – evidence, ledger, state
sudo systemctl disable --now raxe-sensor # only if you installed the host sensor
The named volumes hold your sealed evidence and the audit ledger – export anything
you need to keep before running down -v. Beyond that: no residue, no
phone-home, nothing left running. Done.
And if you stay, the same deployment grows with you – more host sensors, a connected AWS account, more producers – without a reinstall or a migration.
Deploy it with us on a call.
Thirty minutes, your stack, a screen share. We’ll stand it up together and you keep the deployment – whether or not you keep us.