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.
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.
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.
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.
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.
Sabrix intercepts MCP JSON-RPC messages, strips untrusted parameters, validates tool names against tenant RBAC policies, and attenuates privileges to prevent Confused Deputy exploits.
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.
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())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:latestKubernetes 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:
- Send a permitted request and confirm the expected upstream response.
- Send a request prohibited by your configured policy and confirm rejection before the downstream action executes.
- 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 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.
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' }]
});