Technical Reference · In-VPC Control Plane

What is Sabrix?

Sabrix is the execution control plane for enterprise AI agents. It governs which actions agents can take in production, binds approvals to exact operations, and manages failures and uncertain downstream outcomes.

Ship agents that can take action in production—with enforced limits, exact approvals, and clear handling of failed or uncertain operations.

Standard prompt filters and token guardrails inspect text after generation. Once agents invoke tools, connect to APIs, and execute SQL statements, text filters fail. On configured execution paths, Sabrix acts as an in-VPC gatekeeper to validate execution policy before a requested mutation dispatches to downstream systems.

CENTRAL RUNTIME INVARIANT: NO POLICY AUTHORIZATION → NO DISPATCH

On configured execution paths, side-effecting actions only dispatch after policy limits, required approvals, and durable ledger claims clear affirmatively. If an operation exceeds policy without an approval grant, it pauses until authorized.

IN-VPC PRE-EXECUTION PIPELINE CONFIGURED RUNTIME ENFORCEMENT
STAGE 01 Normalization Extracts action, target endpoint, and parameters from HTTP, MCP, or SQL requests.
STAGE 02 Policy Gate Evaluates declarative threshold limits (auto-execute vs human approval required).
STAGE 03 Digest Binding Verifies canonical SHA-256 parameter digest against authenticated approval grant. Any altered parameter immediately voids authorization.
STAGE 04 In-VPC Secrets Injects destination credentials at dispatch. Keys never touch agent code or prompts.
STAGE 05 Durable Ledger Persists execution record via atomic replacement and directory sync. If network times out, recorded as AmbiguousInFlight.
STAGE 06 Reconciliation Probes destination status or alerts operators before permitting retry. Zero blind replays.

Why Execution Control Matters

How an execution control plane fundamentally differs from passive post-hoc chatbots and passive observability proxies:

Execution Risk Post-Hoc Chatbot Logging Sabrix Execution Control Plane
Irreversible Side Effects Logs actions after the database mutation or financial transfer commits. Pre-Execution Gating: Evaluates policy and holds high-risk operations before dispatch.
Altered Approvals Approval granted for one parameter applies broadly to subsequent actions. Exact Operation Binding: Approval binds to exact parameters; modifications require a new decision.
Downstream Timeouts Network disconnect triggers blind retries, causing duplicate mutations or charges. Timeout Preservation: Marks ambiguous in-flight state; checks destination evidence before retry.
Credential Sprawl Agent runtimes store raw third-party API keys and database credentials. In-VPC Credential Control: Keys remain isolated in-VPC; injected only at authorized dispatch.
Verified Integration INTEGRATION PREREQUISITES

Execution Control Integration & Prerequisites

Deploy Sabrix as an in-VPC Layer 7 execution control plane adjacent to agent workloads. Evaluates policy rules, blocks unauthorized tool side-effects, and issues durable execution claims before actions dispatch.

Explore Air-Gapped Browser Sandbox ↗
IN-VPC EXECUTION CONTROL PLANE CONTAINER CONFIGURED RUNTIME ENFORCEMENT

Run Sabrix inside your private VPC or Kubernetes cluster adjacent to your agent runtimes with persistent record storage:

# Run in-VPC standalone execution control plane with persistent execution storage
docker run -d --name sabrix-control-plane \
  -p 127.0.0.1:8080:8080 \
  -p 127.0.0.1:8090:8090 \
  -p 127.0.0.1:9090:9090 \
  -v $(pwd)/sabrix-records:/var/lib/sabrix/records \
  -e ADMIN_API_KEY="${ADMIN_API_KEY:?Set ADMIN_API_KEY}" \
  -e UPSTREAM_ADDR="https://api.openai.com" \
  -e SABRIX_FAILURE_MODE=closed \
  ghcr.io/sabrix-ai-inc/sabrix-proxy:latest

# Configure supported tool clients to route outbound action traffic through Action Forward Proxy (:8090)
export HTTP_PROXY="http://127.0.0.1:8090"
export HTTPS_PROXY="http://127.0.0.1:8090"

Security note: Binding ports to 127.0.0.1 restricts access to the local host. Publishing -p 9090:9090 without an interface address exposes the administration API to all host network interfaces. In production, keep administration (:9090) on an isolated management network or loopback. Forward proxy (:8090) requires explicit tool client proxy configuration, identity headers, and CA certificates for TLS inspection.

Integration Aspect Configuration & Mechanism Behavioral Contract
Intercepted Action Path Configure tool clients to route tool calls, HTTP APIs, and MCP requests through Sabrix Action Forward Proxy (:8090). Pointing model URLs (:8080) intercepts LLM tokens only; tool calls executed by application code must route through the execution forward proxy.
Policy Configuration Declared via YAML policy rules or the Admin API (/admin/policy). Defines allowed destinations, auto-execute thresholds (e.g. max $500), and operations requiring approval.
Authority & Approvals High-risk operations pause with RequiresApproval until an approval grant is submitted on port :9090. Grants bind cryptographically to the canonical SHA-256 parameter digest. Altered parameters require a new approval decision.
Credential Control Agents call Sabrix without destination credentials. Sabrix injects keys at dispatch. Downstream API keys and DB secrets remain isolated inside the VPC boundary and are never exposed to LLM prompts.
Unresolved Outcomes Timed-out operations enter AmbiguousInFlight in the durable execution store. No blind retries. Supported destination status checks or operator investigation verify evidence before any retry.
Port Interface Role Default Listener Traffic Path & Access Controls
:8080 Model Ingress Reverse Proxy 0.0.0.0:8080 Reverse proxy for model completions and prompt inspection. Evaluates caller x-sabrix-* context headers.
:8090 Action Forward Proxy 127.0.0.1:8090 Forward proxy for tool calls, REST APIs, and MCP mutations. Evaluates policies, binds approvals to parameter digests, and injects destination credentials.
:9090 Administration & Ledger API 127.0.0.1:9090 Management interface for policy rules (/admin/policy), ledger records (/admin/ledger/records), and metrics. Authenticates via Authorization: Bearer $ADMIN_API_KEY.

Listener addresses are configurable via environment variables (LISTEN_ADDR, FORWARD_LISTEN_ADDR, ADMIN_LISTEN_ADDR). VPC placement does not replace ingress authentication or egress firewall controls.

Storage Semantics: Execution state is persisted through atomic record replacement with file and directory synchronization. Atomic replacement guarantees readers observe complete old or new records and survive node restarts. Long-term historical audit trails, tamper evidence, and compliance retention require replication to immutable external storage.
Decoupled Deployment: Supported tool clients can route action traffic through Sabrix while retaining their existing model gateway. Deployment requires explicit client routing, identity configuration, and controls that prevent bypass.

Architecture Overview & State Demarcation

Internal layer state boundaries and crash-resilient failure semantics:

Layer State Semantics Mechanism Failure Behavior
AST Scanner Stateless SIMD pattern matching in safe Rust. Local, zero-dependency. Survives partitions.
Synthetic Vault In-Process Ephemeral In-memory synthetic token vault replaces sensitive secrets with zero-leak tokens. Deterministic per-tenant memory caps with LRU eviction.
Trajectory Integrity Session Bound Sequential cryptographic continuation tokens. Rejects out-of-order or tampered hops.
Durable Authority Authoritative Atomic record replacement with file and directory synchronization. Crash recovery scans pending claims; fails closed on corrupt records.
Distributed Authority Consensus Linearizable consensus with monotonic fencing tokens. CP system. Quorum loss fails closed.

Core Security Model & Tool Governance

1. Tool Authority

Validates JSON-RPC schemas, AST bounds, and role-based permissions before dispatch.

2. Data Authority

In-memory bidirectional synthetic token vault replaces PII and secrets with reversible tokens.

3. Delegated Authority

Enforces capability attenuation across swarms, preventing sub-agent privilege escalation.

4. Execution Authority

Establishes durable claims (ExecutionId) and monotonic fencing tokens before actuator commit.

MODEL CONTEXT PROTOCOL (MCP) TOOL GOVERNANCE IN-LINE AST INTERCEPTION

Sabrix intercepts MCP JSON-RPC messages, strips untrusted parameters, validates tool names against tenant RBAC policies, and attenuates privileges to prevent Confused Deputy exploits.

Execution Authority & Durable Claims

DURABLE EXECUTION CLAIM GUARANTEE IDEMPOTENT DISPATCH

Configured authority paths bind supported actions to execution identifiers. Downstream idempotency or fencing determines how retries and superseded requests affect external systems.

Crash recovery reconciles outstanding execution claims upon gateway restart according to the configured execution path and authority provider, rejecting uncommitted dispatches when configured in fail-closed mode.

Distributed Authority & Consensus

  1. Agent requestIdentity and requested action
  2. Configured policyEvaluate before dispatch
  3. Connected systemOutcome and audit evidence

Distributed authority requires a configured quorum. Safe retries depend on the connected system's idempotency or fencing contract.

Boundary Limitations: Opaque actuators lacking native idempotency or fencing cannot physically prevent socket completion if authority is superseded mid-flight. Deploy fence-aware endpoints for high assurance.

Multi-Language Code Matrix

Layer 7 controls over standard HTTP sockets. SDK types and tools remain 100% standard:


      

Header Requirement Scope & Actual Behavior
x-sabrix-tenant Required for multi-tenant Selects tenant policy context. Defaults to global policy when omitted.
x-sabrix-agent-id Required for RBAC Identifies calling agent entity for policy evaluations. Missing header resolves to unassigned.
x-sabrix-agent-role Optional (viewer default) Recognized roles: viewer, researcher, analyst, executor, admin.
x-sabrix-session-id Recommended Preserves multi-turn conversation and drift guard integrity. Derived if omitted.
x-sabrix-parent-agent-id Optional Carries parent agent identity for swarm delegation tracking and capability attenuation.

These headers carry routing and agent context. Configure authenticated ingress before trusting caller-supplied values.

Multi-Agent Swarms

LangGraph Multi-Agent Integration

Configure per-client routing headers for supervisor and delegated worker nodes to carry agent identity and lineage:

import os
from langgraph.graph import StateGraph, END
from langchain_openai import ChatOpenAI

supervisor_llm = ChatOpenAI(
    model="gpt-4o",
    base_url=os.environ.get("OPENAI_BASE_URL", "http://127.0.0.1:8080/v1"),
    default_headers={"x-sabrix-tenant": "acme", "x-sabrix-agent-id": "supervisor", "x-sabrix-agent-role": "admin"}
)
worker_llm = ChatOpenAI(
    model="gpt-4o",
    base_url=os.environ.get("OPENAI_BASE_URL", "http://127.0.0.1:8080/v1"),
    default_headers={"x-sabrix-tenant": "acme", "x-sabrix-agent-id": "worker-1", "x-sabrix-parent-agent-id": "supervisor"}
)

Microsoft AutoGen Integration

Route AutoGen model requests through Sabrix (does not intercept tools executed locally by AutoGen):

# Requires: python3 -m pip install autogen-agentchat "autogen-ext[openai]"
import asyncio, os
from uuid import uuid4
from autogen_agentchat.agents import AssistantAgent
from autogen_ext.models.openai import OpenAIChatCompletionClient

async def main():
    client = OpenAIChatCompletionClient(
        model="gpt-4o",
        api_key=os.environ.get("OPENAI_API_KEY", "${OPENAI_API_KEY:?Set OPENAI_API_KEY}"),
        base_url=os.environ.get("OPENAI_BASE_URL", "http://127.0.0.1:8080/v1"),
        default_headers={
            "x-sabrix-tenant": "acme",
            "x-sabrix-agent-id": "autogen-assistant",
            "x-sabrix-agent-role": "viewer",
            "x-sabrix-session-id": str(uuid4()),
        },
    )
    try:
        assistant = AssistantAgent("analyst", model_client=client)
        result = await assistant.run(task="Reply with a short greeting.")
        print(result.messages[-1].content)
    finally:
        await client.close()

if __name__ == "__main__":
    asyncio.run(main())
Production Packaging

Docker Standalone Deployment

Deploy Sabrix as an In-VPC container adjacent to your application workloads with persistent state storage:

docker run -d --name sabrix-control-plane \
  -p 127.0.0.1:8080:8080 \
  -p 127.0.0.1:8090:8090 \
  -p 127.0.0.1:9090:9090 \
  -v /var/run/sabrix/records:/var/lib/sabrix/records \
  -e ADMIN_API_KEY="${ADMIN_API_KEY:?Set ADMIN_API_KEY}" \
  -e UPSTREAM_ADDR="${UPSTREAM_ADDR:-https://api.openai.com}" \
  -e SABRIX_FAILURE_MODE=closed \
  ghcr.io/sabrix-ai-inc/sabrix-proxy:latest

Kubernetes Sidecar & DaemonSet Topologies

Sidecar container adjacent to agent pods with bounded resource requests (32Mi request / 64Mi limit):

Provision secret: kubectl create secret generic sabrix-secrets --from-literal=admin-api-key="${ADMIN_API_KEY:?Set generated ADMIN_API_KEY}"

apiVersion: apps/v1
kind: Deployment
metadata: { name: agent-worker-deployment }
spec:
  replicas: 5
  selector:
    matchLabels: { app: agent-worker }
  template:
    metadata:
      labels: { app: agent-worker }
    spec:
      containers:
        - name: agent-worker
          image: internal-registry.io/agent:v2.1
          env: [{ name: OPENAI_BASE_URL, value: "http://127.0.0.1:8080/v1" }]
        - name: sabrix-sidecar
          image: ghcr.io/sabrix-ai-inc/sabrix-proxy:latest
          env:
            - name: ADMIN_API_KEY
              valueFrom: { secretKeyRef: { name: sabrix-secrets, key: admin-api-key } }
            - name: UPSTREAM_ADDR
              value: "https://api.openai.com"
            - name: SABRIX_FAILURE_MODE
              value: "closed"
          resources: { requests: { memory: "32Mi", cpu: "50m" }, limits: { memory: "64Mi", cpu: "500m" } }

Enterprise Sidecar & Helm Patterns

Deploy via standard Helm charts with native Kubernetes health probes (:9090/healthz) and Horizontal Pod Autoscaling (HPA). Supports Async Worker Egress Interception, Realtime Voice AI over WebSocket, and CSI Secrets Store Key Custody.

Observability: OpenTelemetry & Prometheus

W3C OpenTelemetry spans and Prometheus metrics on data plane (:8080) and authenticated admin port (:9090). Counter definitions:

  • plenum_requests_total: Requests counted by this proxy instance’s gateway processing path.
  • sabrix_wal_dropped_total: Recorded WAL audit-event drops, including queue saturation, queue closure, and rotation-capacity failures. Investigate any increase.
  • sabrix_durability_rejections_total: Requests rejected because durability preconditions failed.
set -o pipefail
curl -fsS -H "Authorization: Bearer ${ADMIN_API_KEY:?Set ADMIN_API_KEY}" \
  http://127.0.0.1:9090/metrics | grep -E '^(sabrix_wal_dropped_total|sabrix_durability_rejections_total|plenum_requests_total)(\{|[[:space:]])'

Resilience, Failover & Flags

Flag Values Behavior
SABRIX_FAILURE_MODE closed | open Explicit opt-in setting: closed rejects dispatches on health failure; defaults to BestEffort.
SABRIX_MODE enforce | observe enforce blocks unauthorized actions; observe records telemetry without blocking.

Verify your integration

Validate the configured gateway with a representative workflow before connecting production agents:

  1. Send a permitted request and confirm the expected upstream response.
  2. Send a request prohibited by your configured policy and confirm rejection before the downstream action executes.
  3. Inspect the resulting audit records and operational metrics.

For distributed deployments, also verify quorum-loss behavior and the downstream system's retry and fencing contract.

Optional Utility CLIENT-SIDE CONTEXT PRUNING

Optional Utility: Client-Side Context Compaction

Sabrix primarily operates as an In-VPC Layer 7 execution control plane for governing tool actions, external API mutations, and durable state. As a separate and optional optimization utility, Sabrix provides standalone client-side compaction libraries (sabrix_compactor.py and @sabrix/compactor) for agent runtimes that experience heavy token consumption from repetitive tool outputs.

ARCHITECTURAL BOUNDARY: COMPACTION VS. EXECUTION CONTROL

Client-side compaction operates purely in-memory before tokens are sent to model endpoints. It does not inspect external API side effects, evaluate action policies, or manage approvals. Consequential tool calls and API mutations require routing through the In-VPC execution control plane.

Python In-Process Compactor

Zero-dependency wrapper that deduplicates repeated tool responses and applies sliding-window head-truncation.

from sabrix_compactor import wrap_client
from openai import OpenAI

# Wraps standard client in-process
client = wrap_client(OpenAI())
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Analyze logs"}]
)

TypeScript / Node Compactor

Native in-memory compactor for Node.js agent loops prunes identical tool results before model dispatch.

import { wrapClient } from '@sabrix/compactor';
import OpenAI from 'openai';

// Wraps standard OpenAI client in-process
const openai = wrapClient(new OpenAI());
const res = await openai.chat.completions.create({
  model: 'gpt-4o',
  messages: [{ role: 'user', content: 'Audit spend' }]
});