Security
Most remote-management security is a promise about who holds the keys. Xenon is built so the dangerous capability doesn’t exist in the first place — and where the two editions differ, this page says so plainly.
Xenon cannot run arbitrary commands. Every action the AI can take comes from a reviewed catalog with strict parameter validation — pattern-matched, typed, and bounded. There is no payload-shaped input, and an approval covers exactly one machine: no fleet-wide fan-out exists to abuse. True in both editions, by construction.
Read-only diagnostics run unattended. Everything else waits for a person. Everyday fixes are yours to approve right in the app; in the hosted edition being built, that yes will extend up the ladder, with a firmer confirmation the bigger the action. In the Enterprise Edition, service-level changes need an admin and critical operations need two distinct approvers — enforced server-side, not in the UI.
Every prompt, tool call, proposed action, approval, denial, sign-in, failed sign-in (with the reason the generic error deliberately hides), password reset, and role change is recorded. Reading the trail requires a tier above the admins it reports on.
The agent is a small Rust process holding no API keys and no playbook knowledge. It connects outbound only — there's no inbound port to scan, and a stolen laptop yields a revocable enrollment token, not your infrastructure.
In the Enterprise Edition: OIDC single sign-on with per-org enforcement, revocable sessions with idle timeout, forced password resets that actually revoke other sessions, and login flows hardened against account enumeration and credential spraying. The hosted edition will sign in with Google — that flow is being built now.
An investigation in progress can be halted mid-turn — from the assistant on the machine, or in the Enterprise Edition from the admin Console. The turn ends immediately, and anything already proposed still waits in the queue it was always going to wait in.
The Enterprise Edition is self-hosted: your organization runs its own Controller on its own server, and nothing about your fleet lives in a Xenon-run cloud. That has always been true of this edition, and it stays true. The hosted edition is different, and we won’t pretend otherwise: it runs on infrastructure Xenon operates. So the honest claim there is narrower — each person’s data is isolated per tenant, with the isolation enforced in the data layer rather than by convention, and tested adversarially before launch. That work is a launch gate, not a polish item: the hosted edition does not open until it holds.
The Controller never fully trusts the client. Agent identity is scoped to the authenticated connection — one machine can never act on another's behalf by guessing an id. Conversation history is replayed from the server's own records, never from what a client sends. Approval rules are checked server-side against the requester. And when a connection is superseded or revoked, the old one is closed loudly, not left to linger.
Runaway AI spend is an outage of a different kind. Every model call is token-accounted and attributed to the person who spent it, with monthly allowances. When a cap bites, the person gets a real answer — what's paused, what still works, when it resets — and machine investigations are never refused. A support tool that switches itself off when something is broken has failed at its one job.
Ask directly. Xenon is built by one person, and he answers the security questions himself — support@xenon.solutions reaches him.