System architecture & execution flow.
Every agent action crosses a single control layer before it reaches a model, service, or database. This is what that layer is made of and what happens inside it. It is the enforcement core of runtime security for AI agents.
The execution path.
Traffic enters from any runtime, resolves through the core, and only reaches an output once a verdict allows it. This is the execution path our AI agent security model enforces.
Cirvix Control Plane
Five decisions,
in this order.
Each stage can refuse. A stage that refuses does not fall through to the next one.
Identity — who is asking
Resolve the agent and the org from the credential, not from a field in the request body. An agent cannot claim a different org_id than the one it authenticated as.
Scope — what it is allowed to reach
Tenant scoping is applied in routing. A query that is not scoped does not become scoped later; it is refused.
Policy — what the rules say
The rule set resolves to exactly one verdict. Explicit deny is terminal, no match means deny, and audit_only never authorizes.
Evidence — what gets recorded
The decision is written into the hash-linked chain before the action is released. The record does not depend on the action succeeding.
Release — what actually runs
Only an allowed action proceeds, carrying the scope it was granted and nothing wider.
Delegation → Effective Action → Consequence → Proof
Security capabilities cannot remain separate dashboards that humans visit after a breach. CIRVIX operates as an agent-callable enforcement primitive embedded directly in the execution flow: Agent → CIRVIX Decision (<1.2ms design target) → Tool Invocation → Real-World Side Effect → Hash-Chained Evidence Record (optionally Ed25519-signed). Enforcement is protocol-agnostic, spanning MCP, REST APIs, CLI commands, browser automation, sub-agent swarms, and local OS calls.
Proxy enforcement today. Kernel work is a prototype.
Enterprise security diligence requires clarity on where controls actually bind. Cirvix enforces in userspace today: protocol proxy inspection over stdio / MCP / UDS. OS kernel enforcement is a Linux-only prototype (see prototypes/ebpf/) — it is not shipped, not installed by the installer, and nothing in the product depends on it.
| Layer | Linux | macOS | Windows | Enforcement Capabilities |
|---|---|---|---|---|
Layer 1: Protocol Proxy (shipped)stdio / MCP / UDS | Unix Domain Socket (/var/run/cirvix/ipc.sock) | Unix Domain Socket (/var/run/cirvix/ipc.sock) | Named Pipes (\\.\pipe\cirvix-ipc) | Inspects tool payloads, validates schemas, constrains injected agents' tool calls, runs secret DLP scanning, and enforces authorization before execution. |
| Layer 2: OS Kernel Traps (Linux prototype only — not shipped, nothing depends on it) System Call Containment | Prototype: eBPF + seccomp-bpf Hooks sys_enter_execve, sys_enter_connect, and LSM hooks | Not built No EndpointSecurity client ships | Not built No WFP / ETW / Minifilter driver ships | Prototype only. Out-of-band containment below is a research direction, not an enforcement promise: the shipped product contains what the proxy sees. |
Kernel Syscall Interception (not shipped)
There is a Linux-only research prototype at prototypes/ebpf/: compiled eBPF bytecode attached to tracepoints and LSM hooks. It is Linux-only, needs CAP_SYS_ADMIN, and is not the enforcement foundation — nothing in the product depends on it, and the installer does not install it.
Synchronous Auth Events (not built)
No Apple EndpointSecurity client ships with Cirvix. macOS enforcement runs through the same userspace proxy (stdio / MCP / UDS) as every other platform. An ES client may be built later; until it is, any claim otherwise is false.
Filtering Platform & Driver Callouts (not built)
No WFP callout, ETW consumer, or minifilter driver ships with Cirvix. Windows enforcement runs through the userspace proxy (Named Pipe broker). Kernel-level Windows enforcement is not on the shipped path.
What crosses
the boundary.
The control plane needs the shape of a request to decide about it. It does not need to keep the contents.
- evaluated
- agent_id, org_id, action, resource, policy set
- recorded
- decision, rule id, reason, block hash, prev hash
- discarded
- payload contents not approved for retention
- never stored
- CIRVIX_MASTER_KEY — customer managed, no escrow path
Encryption is AES-256-GCM envelope encryption. The master key stays on your side of the boundary; Cirvix holds no escrowed copy and therefore cannot decrypt on your behalf.
What happens
when it breaks.
A control plane that fails open is not a control plane. These are the states it is designed to hold.
| Condition | Behaviour | Recorded |
|---|---|---|
| Policy engine unreachable | Actions are denied. There is no pass-through mode. | Denial recorded with cause |
| Audit store unavailable | Actions are denied — a decision that cannot be recorded is not released. | Recorded on recovery |
| Rule set fails to parse | The previous valid rule set stays active; the broken one is rejected at load. | Load failure recorded |
| Unknown action | Denied as unmatched. Absence of a rule is not permission. | Unmatched decision recorded |
Run it inside your own boundary
Docker Compose, Helm, or bare Node — wherever the trust boundary already is.
Bring every agent
under control.
Set durable policy, preserve a verifiable record, and give teams a safer way to put intelligent systems to work.
Contact Enterprise Sales
Discuss custom VPC deployments, policy requirements, or dedicated enterprise support.
Prefer to talk? Book a 30-minute call