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.
OS-Level Trapping vs. Proxy Enforcement.
Enterprise security diligence requires clarity on where controls actually bind. Cirvix operates a two-layer defense-in-depth model: high-level semantic proxy inspection plus OS-native kernel enforcement across Linux, macOS, and Windows.
| Layer | Linux | macOS | Windows | Enforcement Capabilities |
|---|---|---|---|---|
Layer 1: Protocol Proxystdio / 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 System Call Containment | eBPF + seccomp-bpf Hooks sys_enter_execve, sys_enter_connect, and LSM hooks | EndpointSecurity (ES) Kernel client daemon ( ES_EVENT_TYPE_AUTH_EXEC, AUTH_OPEN) | WFP + ETW / Minifilter Windows Filtering Platform network callouts + ETW process tracing | Contains out-of-band calls outside policy. Even if an agent process is compromised to run raw shell forks or bypass userspace shims, kernel traps deny unauthorized sockets, files, and child processes. |
Kernel Syscall Interception
On Linux hosts and containers, the Cirvix daemon loads compiled eBPF bytecode attached to tracepoints and Linux Security Module (LSM) hooks. Any unbrokered attempt by an agent or spawned child to initiate raw TCP connections or call execve outside declared policy boundaries is dropped directly in the kernel ring before execution.
Synchronous Auth Events
On macOS, Cirvix utilizes Apple's EndpointSecurity framework (replacing legacy dtrace). The daemon subscribes to synchronous AUTH_EXEC and AUTH_OPEN events, holding process execution until the Cirvix policy engine computes a verdict. Binaries outside policy are killed immediately.
Filtering Platform & Driver Callouts
On Windows workstations and servers, Cirvix binds to the Windows Filtering Platform (WFP) to enforce packet- and connection-level network barriers on agent processes, while Event Tracing for Windows (ETW) and filesystem minifilter drivers provide deterministic audit trails and file tampering locks.
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