CirvixArchitectureHow It Works

How Cirvix works & how to implement it.

Every AI agent action—whether a tool call, file modification, SQL query, shell fork, or external API mutation—crosses an unbypassable control checkpoint before it executes. This guide details how the engine operates under the hood and provides complete, copy-pasteable implementation blueprints for production systems. For the category framing, read AI-agent security.

1.2mstarget policy evaluation latency
0uninspected side effects
2-Layerprotocol proxy + OS kernel traps
SHA-256 + Ed25519hash-chained, optionally signed (0.1.3+)
01 / Core Engineering Thesis

Capability is not authority.

Traditional security architectures assume that if an entity holds a valid credential and an authorized API key, its actions are inherently authorized. With autonomous AI agents, that assumption fails completely.

thesis-statement.mdFUNDAMENTAL SHIFT

“Valid identity. Valid credential. Valid tool. Unauthorized consequence → CIRVIX blocks it.”

An agent can hold valid OAuth tokens for GitHub, a Slack bot credential, and full write permission to a Jira workspace. Under standard IAM, any action executed with those credentials succeeds. But if the agent attempts an unauthorized side effect—such as mass-posting 18,000 comments across an external coordination channel, dumping environment variables, or executing schema drops—traditional infrastructure is blind. CIRVIX evaluates the effective consequence before letting the byte stream leave the runtime.

Problem: The Authorization Void

Why IAM & Firewalls Fail

API gateways inspect HTTP routes, IP addresses, and Bearer tokens. They cannot discern whether an agent invoking fs.write is refactoring code or writing a persistent reverse shell. Cirvix operates inside the execution loop, parsing semantic intent, file targets, SQL ASTs, and sub-agent delegations.

Solution: Pre-Execution Gate

Machine-Speed Enforcement

Post-execution logging (SIEM, LangSmith, DataDog) only records damage after the breach has happened. In autonomous agent workflows, damage cascades in milliseconds. Cirvix is designed to evaluate policy in <1.2ms (design target; measured runs with hardware context on benchmarks), issuing an authoritative verdict prior to tool release.

Recorded Evidence: Hash-Chained Log

Cryptographic Evidence

Every decision is appended to a linear SHA-256 hash chain and, since 0.1.3, can be Ed25519-signed: each record's hash carries a signature, so a forged chain with every hash recomputed fails on the signature. A holder of an earlier head can still recompute hashes to detect later alteration — the chain shows tampering, it does not prevent deletion, and no KMS anchoring is claimed. The honest limit: signing proves attribution to the key, not to a third party. See the audit chain for the exact limits.

02 / Deep Dive Mechanics

How Cirvix works under the hood.

Cirvix enforces a two-layer defense-in-depth model: high-level semantic protocol proxying paired with low-level OS kernel system call trapping.

01 / Trapping Layer
MCP Stdio / SSE ProxyModel Context Protocol Gate
UDS / Named Pipe ShimLocal IPC Socket Intercept
OS Kernel TrapseBPF / ES / WFP Driver
02 / Decision Engine
CIRVIX CORE ACTIVE

Decision Core (<1.2ms design target)

Secret & DLP Normalizer
Deterministic Policy Evaluator
Hash-Chain Entry (SHA-256, optionally Ed25519-signed)
03 / Controlled Targets
Filesystem & ProcessesSandboxed OS primitives
External APIs & ToolsSanctioned egress traffic
Production DBsTenant-scoped queries
Two-Layer Containment

Protocol Proxy vs. OS Kernel Trapping

Where controls actually bind across platforms. No agent can bypass the gate by spawning child processes or initiating raw socket connections.

Enforcement Tier Linux (Cloud / K8s) macOS (Darwin) Windows Server / Client Capabilities & Guarantees
Tier 1: Protocol Proxy
Semantic Interception
Unix Domain Socket
/var/run/cirvix/ipc.sock
Unix Domain Socket
/var/run/cirvix/ipc.sock
Named Pipes
\\.\pipe\cirvix-ipc
Inspects JSON-RPC/MCP payloads, parses tool parameters, runs high-speed regex DLP for API keys, checks SQL AST, and constrains what an injected agent can do — injection of the model itself is not prevented, the resulting tool call is still evaluated.
Tier 2: Kernel Syscall Traps
Out-of-Band Containment
eBPF + LSM Hooks
sys_enter_execve
sys_enter_connect
Apple EndpointSecurity
Synchronous auth events
ES_EVENT_TYPE_AUTH_EXEC
WFP + ETW Driver
Windows Filtering Platform
Minifilter driver
Guarantees that even if an agent process executes arbitrary shellcode or invokes raw binaries via /bin/bash, the kernel drops unauthorized network sockets and terminates forbidden sub-processes.
03 / The Execution Pipeline

Five deterministic stages,
every single execution.

Every tool invocation, API request, and database write is evaluated sequentially. If any stage issues a denial, evaluation halts immediately. There is no pass-through fallback.

01

Identity & Context Resolution

Resolve the invoking agent identity, tenant ID, and parent session from cryptographic credentials, never from self-reported payload fields. An agent executing on behalf of org_492 cannot assert org_admin privileges.

02

Payload Normalization & DLP Scrubbing

The request payload passes through streaming DLP analyzers that detect leaked AWS secrets, private SSH keys, OAuth tokens, and PII. SQL statements are tokenized into ASTs so destructive mutations matched by policy are denied before reaching production databases.

03

Deterministic Policy Evaluation

The compiled policy engine evaluates applicable organizational rules. Three strict rules govern evaluation: (1) An explicit forbid/deny rule is terminal and irreversible; (2) Absence of an allow rule defaults to deny; (3) audit_only records telemetry but never grants authorization.

04

Hash-Chained Evidence Recording

Before releasing an action or returning an error, a new entry is written to the linear SHA-256 hash chain (optionally Ed25519-signed since 0.1.3). The entry seals the request hash, timestamp, verdict, and the previous block hash. Execution cannot proceed until the ledger confirms receipt — if the audit store is unavailable, the action is denied.

05

Controlled Release or Human Escalation

Permitted calls are forwarded to the target tool or downstream service with tenant headers strictly bound. If a rule specifies "effect": "hold", the request is paused and routed to designated human approvers via webhook or Slack.

04 / Cryptographic Evidence

Tamper-evident record,
with stated limits.

Logs written to disk or sent to cloud aggregators can be deleted, truncated, or modified by compromised processes. Cirvix seals every decision in a linear SHA-256 hash-linked structure (unsigned) — it shows alteration to a holder of an earlier head; it does not prevent deletion.

Each audit entry records: the agent fingerprint, timestamp, normalized tool call parameters, policy rule triggered, and the cryptographic hash of the prior block. Changing even a single character in block #12 invalidates the hashes of blocks #13 through #10,000.

audit-chain-entry.jsonHASH-CHAINED LOG (UNSIGNED)
{
  "block_index": 48201,
  "timestamp": "2026-09-07T00:52:14.912Z",
  "agent_id": "agt_claude_eng_prod",
  "tenant_id": "org_acme_cloud",
  "action": "fs.read",
  "resource": "/etc/shadow",
  "verdict": "DENY",
  "policy_rule": "deny-system-critical-files",
  "latency_ms": 1.18,
  "prev_block_hash": "9e2f41c...d88a",
  "block_hash": "a7b3104...c41e"
}
05 / Implementation Playbook

How to implement Cirvix
in your systems.

Cirvix is designed for zero-friction adoption. From a 10-second developer CLI setup to an enterprise Kubernetes fleet sidecar, select the implementation blueprint that fits your architecture.

Tier A: 10-Second Dev Setup

Single-Binary CLI

Install the standalone Go/Rust daemon on Linux, macOS, or Windows. Zero system dependencies. Instant local protection.

See CLI Setup ↓
Tier B: IDE & MCP Workflows

Claude Code & Cursor

One-command integration with Claude Code, Cursor, and VS Code. Intercept all Model Context Protocol (MCP) server calls.

See IDE Setup ↓
Tier C: Application SDK

Python & Node.js

One-line wrapping for LangChain, LlamaIndex, CrewAI, AutoGen, and native OpenAI/Anthropic tool callers.

See SDK Code ↓
Tier D: Production Fleet

Kubernetes Sidecar

Drop-in sidecar container for microservice agent pods. Shared Unix domain socket. Zero cloud egress latency.

See K8s Spec ↓
Step 1 / Fast Installation

1. Single-Binary Distribution & Daemon Setup

Deploy the pre-compiled Cirvix daemon. The installer detects your OS (Linux, macOS, Windows) and CPU architecture (x86_64, arm64) automatically.

terminalBASH / POWERSHELL
# macOS & Linux (Homebrew)
brew tap cirvix/tap && brew install cirvix

# macOS & Linux (curl standalone binary installer)
curl -sSL https://cirvix.com/install.sh | bash

# Windows (PowerShell standalone binary installer)
irm https://cirvix.com/install.ps1 | iex

# Start the Cirvix control plane daemon in the background
cirvix daemon start --policy-dir=/etc/cirvix/policies

# Verify daemon health and audit chain status
cirvix status
Step 2 / Developer Tooling

2. 10-Second Setup for Claude Code, Cursor & MCP

AI agent coding assistants like Claude Code and Cursor execute shell commands, read files, and call MCP tools. Cirvix acts as the trusted gatekeeper without changing developer workflows.

claude-code-setup.shTERMINAL
# Option A: Register Cirvix as the global MCP enforcement layer in Claude Code
claude mcp add cirvix -- cirvix mcp-proxy

# Option B: Run Claude Code under active Cirvix execution containment
cirvix wrap -- claude

For Cursor and VS Code, add the Cirvix stdio proxy to your claude_desktop_config.json or Cursor MCP settings:

~/.config/Cursor/mcp_servers.jsonJSON
{
  "mcpServers": {
    "filesystem-controlled": {
      "command": "cirvix",
      "args": ["proxy", "--tool", "@modelcontextprotocol/server-filesystem", "--", "/workspace"]
    },
    "postgres-controlled": {
      "command": "cirvix",
      "args": ["proxy", "--tool", "@modelcontextprotocol/server-postgres", "--", "postgresql://localhost/prod"]
    }
  }
}
Step 3 / Application Middleware

3. Python & Node.js Agent Code Wrapping

Wrap existing agent frameworks (LangChain, LlamaIndex, CrewAI, AutoGen) with a single line of middleware. All tool executions are intercepted synchronously.

python_agent.py (LangChain / CrewAI / LlamaIndex)PYTHON
from cirvix import Guard, CirvixDeniedError, CirvixHeldError
from langchain.agents import initialize_agent, Tool

# Raw, powerful tools that need strict governance
raw_tools = [execute_sql_query, read_local_file, invoke_external_webhook]

# 1-Line Cirvix Guard Wrapping
guarded_tools = [
    Guard.wrap(tool, agent_id="support-agent-v2", tenant_id="org_enterprise")
    for tool in raw_tools
]

agent = initialize_agent(guarded_tools, llm, agent="zero-shot-react-description")

try:
    response = agent.run("Find customer transaction 902 and update their tier.")
except CirvixDeniedError as err:
    # Terminal denial: Agent requested an action forbidden by organizational policy
    print(f"Action blocked by Cirvix: {err.reason} (Rule: {err.rule_id})")
except CirvixHeldError as held:
    # Held for Human-in-the-Loop (HITL) approval
    print(f"Action held pending approval from: {held.approvers}. Approval ticket: {held.ticket_id}")
agent_control.ts (Node.js / TypeScript)TYPESCRIPT
import { guard, CirvixDenied, CirvixHeld } from "@cirvix_ai/agent-control";

const safeTools = guard.wrap(myAgentTools, {
  agent:       "pr-automation-bot",
  environment: process.env.CIRVIX_ENV ?? "production",
  socketPath:  "/var/run/cirvix/ipc.sock"
});

try {
  await agentRunner.execute({ tools: safeTools });
} catch (err) {
  if (err instanceof CirvixDenied) {
    console.error("Blocked by policy [" + err.ruleId + "]: " + err.message);
  }
}
Step 4 / Production Container Fleets

4. Kubernetes & Docker Sidecar Architecture

For large-scale microservice agent fleets, Cirvix runs as a lightweight sidecar proxy inside each Pod. The agent and sidecar share a high-performance Unix domain socket via a memory-backed emptyDir volume.

k8s-agent-pod-sidecar.yamlYAML
apiVersion: apps/v1
kind: Deployment
metadata:
  name: autonomous-agent-fleet
  labels:
    app: agent-worker
spec:
  replicas: 5
  template:
    metadata:
      labels:
        app: agent-worker
    spec:
      volumes:
        # Shared ultra-low latency Unix socket
        - name: cirvix-socket
          emptyDir:
            medium: Memory
        # Read-only policy configuration
        - name: cirvix-policies
          configMap:
            name: production-agent-policies
      containers:
        # 1. Primary AI Agent Container
        - name: agent-app
          image: internal-registry.company.com/agent-app:2.4.0
          env:
            - name: CIRVIX_SOCKET
              value: "/var/run/cirvix/ipc.sock"
          volumeMounts:
            - name: cirvix-socket
              mountPath: /var/run/cirvix

        # 2. Cirvix AgentControl Sidecar
        - name: cirvix-guard-sidecar
          image: cirvix/proxy:1.0
          securityContext:
            readOnlyRootFilesystem: true
            allowPrivilegeEscalation: false
          env:
            - name: CIRVIX_MASTER_KEY
              valueFrom:
                secretKeyRef:
                  name: cirvix-kms-credentials
                  key: master-key
          resources:
            limits:
              cpu: "250m"
              memory: "128Mi"
          volumeMounts:
            - name: cirvix-socket
              mountPath: /var/run/cirvix
            - name: cirvix-policies
              mountPath: /etc/cirvix/policies
              readOnly: true
Step 5 / Declarative Governance

5. Writing Production Policy Rules

Policies are declarative JSON definitions stored in version control. Below are four battle-tested policy templates used in enterprise production environments.

Policy 01: Secret DLP

Prevent Environment Leaks

Blocks reading of .env files, SSH keys, or cloud credential directories. Remediates by instructing the agent to use brokered secret handles.

{
  "name": "deny-dotenv-read",
  "effect": "forbid",
  "actions": ["fs.read"],
  "resources": ["**/.env*", "~/.aws/**", "~/.ssh/**"],
  "reason": "Direct secret file reading is prohibited"
}
Policy 02: Human-in-the-Loop

Destructive DB Protection

Automatically holds any DROP, TRUNCATE, or batch UPDATE queries for platform engineering approval before execution.

{
  "name": "hold-destructive-sql",
  "effect": "hold",
  "actions": ["sql.mutate"],
  "patterns": ["(?i)\\b(DROP|TRUNCATE|DELETE\\s+FROM)\\b"],
  "approvers": ["[email protected]"]
}
Policy 03: External Consequence

Prevent Coordination Leaks

Prevents agents from posting unintended state mutations to public wikis, external forums, or third-party webhooks without verified rate gates.

{
  "name": "block-unauthorized-external-post",
  "effect": "forbid",
  "actions": ["http.post", "wiki.mutate"],
  "resources": ["!https://api.internal.acme.com/**"],
  "reason": "External egress mutation denied"
}
Policy 04: Swarm Containment

Sub-Agent Authority Cap

Ensures that any child agents spawned by a primary planner inherit strictly narrower authority and cannot perform external network requests.

{
  "name": "cap-subagent-authority",
  "effect": "forbid",
  "when": { "caller.is_subagent": true },
  "actions": ["net.egress", "agent.spawn"],
  "reason": "Sub-agents cannot spawn or access external net"
}
Step 6 / CI/CD Integration

6. Automated Policy Auditing in GitHub Actions

Catch unconstrained agent tools and policy syntax errors in pull requests before deployment to production staging.

.github/workflows/cirvix-agent-check.ymlYAML
name: Cirvix Agent Security Scan
on: [pull_request]

jobs:
  policy-audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Cirvix CLI
        run: curl -sSL https://cirvix.com/install.sh | bash
      - name: Validate Policies and Agent Tool Schemas
        run: cirvix scan --policy-dir=./policies --tools=./src/agent/tools.json --fail-on-warnings
06 / Technical Comparison

Why Cirvix is different.

How Cirvix AgentControl compares to legacy API gateways, runtime monitors, and post-execution LLM observability tools.

Category Definition

AI agents don't need more permissions. They need enforceable authority.

Traditional security architectures were engineered for human users and static services. Cirvix replaces coarse API permissions with cryptographic agent identities, declared mission boundaries, and action receipts.

Traditional Security Cirvix
User identityAgent identity (Cryptographic Agent Passport)
API permissionIntent + authority (Mission-aware boundary)
Static policyStateful policy (Session chain detection)
Tool allowlistMission-aware authorization (Dynamic context)
LogsCryptographic receipts (Tamper-evident Ed25519)
Kill processKill authority (Multi-scope kill switch)
Network firewallAgent action firewall (Tool & payload gate)
Feature / Requirement API Gateways (Kong, Envoy) Observability (LangSmith, DataDog) Cirvix AgentControl
Enforcement Timing Pre-request (HTTP boundary only) Post-execution (Asynchronous logs) Pre-execution (synchronous gate, <1.2ms design target)
Inspection Scope Headers, IP, JWT, HTTP paths Model prompt/response tokens Full tool payloads, SQL AST, shell args, files
OS-Level Containment None None eBPF (Linux), EndpointSecurity (macOS), WFP (Win)
Sub-Agent Inheritance Blind to child processes Disconnected trace spans Cryptographically bound parent-child delegation
Audit Evidence Standard mutable database logs Third-party SaaS storage Linear SHA-256 hash chain (unsigned) + customer-managed keys
Fail-Closed Design Configurable (often fails open) N/A (Passive monitoring) Strictly fails closed: Unreachable = Denied

Ready to implement Cirvix in your fleet?

Our solutions engineering team assists enterprise teams with custom VPC sidecar architectures, policy reviews, and security compliance.

Launch Control Plane Book Architectural Review
Govern what ships

Bring every agent under control.

Enforce machine-speed policy, protect enterprise data boundaries, and preserve an unassailable record of agent activity.

Copied to clipboard