There is nothing hosted to report.
Cirvix runs on your machine or inside your own boundary. There is no multi-tenant hosted control plane in general availability, so there is no shared uptime for this page to publish — and a green dot claiming otherwise would be the first thing worth distrusting on a security vendor's site. What this page can tell you: the current release, the latency the engine is designed against, and how to read the state of your own deployment.
Check your own deployment.
Every component below runs where you put it, which means we cannot observe it and should not claim to. Each row is the command that answers the question for your install. A component that cannot record is not healthy, because the control plane denies rather than passing traffic through unrecorded.
Rule resolution and verdicts
cirvix policy checkHash-linked decision records
cirvix audit verifyThe control socket your agents call
cirvix statusSelf-hosted, if you run one
GET /healthOnly mounted when a master key is set
GET /v1/secrets@cirvix_ai/agent-control — latest published 0.3.1; release line verified
cirvix — latest published 0.3.1; release line verified
Served by Vercel from the main branch of this repository
We publish no unverified SLA claims, and no availability history — there is no hosted service to have one. This page reports the release and the design targets. A contractual availability commitment is agreed per Enterprise deployment, against the infrastructure that deployment actually runs on.
This website itself has no uptime history to publish either: it is a static deployment on Vercel, rebuilt automatically from this repository's default branch, so a push is usually serving within a minute. Assets are content-hashed and served immutable, which is why a stale page never outlives a deploy. Registry rows above report the latest published version, not the tagged release — npx @cirvix_ai/[email protected] scan runs the latest published scanner without installing anything.
The measured figure above is P99 0.3376ms across 100,000 decisions against 42 rules, audit append excluded, on an Intel Core Ultra 5 225U with 15 GB of memory. Reproduce it with node benchmarks/decision.mjs. It is quoted with the machine attached on purpose: a latency number with no machine under it is not a measurement, and the 1.2ms alongside it is a design target rather than an observation.
The budget
each stage runs against.
These are architecture targets, not a measured availability history.
Metric Definitions, Scope & Enforcement Boundaries
- <1.2ms — Latency Target
- Design target for in-memory policy evaluation per decision stage. Separately measured on Intel Core Ultra 5 225U at P50 0.06ms, P99 0.34ms (
benchmarks/decision.mjs). Not an SLA guarantee across variable hardware or disk I/O. - 0 — External Cloud Payload Retention
- The local engine ships zero telemetry by default and has no unsolicited phone-home. Arguments and tool payloads are never transmitted to CIRVIX. In Node, telemetry shipping is supported only when explicitly configured with an API endpoint and key; Python has no telemetry shipping capability.
- 100% — Governed Tool-Call Evaluation
- Applies exclusively to tool calls explicitly wrapped via
guard.wrap()or routed through the MCP gateway. Does not intercept unwrapped tools, native OS processes, or unrouted traffic.
Running it yourself?
Self-hosted is the only way Cirvix runs today, so your deployment is the only thing with a state to report. The deployment docs cover Docker Compose, Helm and bare Node.
Bring every agent
under control.
Set durable policy, preserve a verifiable record, and give teams a safer way to put intelligent systems to work.