Arbiter Substrate: OS-Level Governance for Autonomous AI Agents

Transparent System Call Interposition with Cryptographic Policy Enforcement

Abstract

AI agents require unrestricted system access to perform tasks: reading files, executing commands, modifying configurations. This creates a fundamental security problem: autonomous systems with root-equivalent permissions and no runtime governance.

Arbiter Substrate introduces an OS-level shim that intercepts system calls before execution, transforms them into semantic intent, and validates against policy through an API-based governance layer. Implementation uses platform-specific interposition mechanisms: LD_PRELOAD on Linux, DYLD_INSERT_LIBRARIES on macOS, and DLL injection on Windows. The system operates transparently. Agents execute normally, unaware of interception.

Each command is evaluated by ArbiterService, a remote governance engine that applies rule packs (policy rules, LLM pricing databases, and side effect definitions) to return cryptographically signed allow/deny/redact decisions. Rule packs are signed with Ed25519 and distributed to Substrate instances for local caching. The system provides complete auditability, real-time policy enforcement, and semantic understanding of agent actions without requiring agent modification.

Substrate instances authenticate via a PKI model: initial registration with an access token (or OAuth 2.1 client credentials) produces a platform-signed X.509 certificate, and all subsequent communication uses mutual TLS through Conduit, an open-source MCP client SDK. This establishes a cryptographic identity chain from the operating system shim through to the governance engine – and because Conduit speaks standard MCP, every agent running on Arbiter Substrate automatically gains access to the full DataGrout platform (semantic discovery, symbolic memory, type transformations, workflow orchestration) as native primitives with bidirectional event delivery.

Arbiter Substrate establishes a “reality substrate” between agents and the operating system: a governed, observable, semantically-aware execution environment that prevents catastrophic actions while simultaneously exposing the full intelligence layer to agents that choose to use it.

Key characteristics: <10ms overhead per syscall, zero agent-side code changes, 100% audit coverage, semantic intent extraction, cryptographically signed decisions, mTLS-authenticated policy communication, and full DataGrout platform access through the same Conduit connection.

Problem Landscape

The Agent Permission Problem

Production AI agents require system access:

os.listdir("/home/user/documents")           # Read files
subprocess.run(["git", "clone", repo])       # Execute commands
open("/etc/nginx.conf").write(config)        # Modify system

Current state: Agents run with full user permissions.

Risks:

Accidental data deletion (rm -rf /)
Credential exposure (cat ~/.ssh/id_rsa)
Privilege escalation (sudo chmod 777 /etc)
Resource exhaustion (fork bombs, infinite loops)
Unintended modifications (config file corruption)

Traditional solutions fail:

Approach	Problem
Restricted user	Too restrictive (blocks legitimate operations)
Containerization	Overhead, complexity, limited filesystem access
Manual review	Breaks autonomy, doesn’t scale
Agent prompting	LLMs ignore safety instructions when focused on task

The Observability Problem

Agent actions are opaque. Questions you cannot answer:

What commands is the agent running?
Why did it choose this action?
What data is being accessed/modified?
How much is this costing (API calls, compute)?

Log files are insufficient: after-the-fact, no semantic understanding, no policy enforcement.

The Trust Problem

Security teams cannot approve agent deployments without runtime governance. Questions like “can this agent access customer data?” and “will it expose credentials?” have no verifiable answers without infrastructure-level observability and enforcement.

Arbiter Substrate Architecture

Arbiter Substrate operates as a transparent OS shim between agent and kernel:

Agent Process (Python, Node.js, etc.)
                  |
  os.system("rm /tmp/cache")
                  |
Substrate Shim (LD_PRELOAD / DYLD / DLL)  <- Intercepts here
  1. Capture syscall
  2. Extract semantic intent
  3. mTLS call to ArbiterService
  4. Receive signed decision
  5. Execute / block / redact
                  |
Operating System (if allowed)

Interposition Mechanisms

Linux (LD_PRELOAD):

export LD_PRELOAD=/usr/lib/arbiter.so
./agent

Arbiter library intercepts libc functions: execve(), open(), socket(), fork(), etc.

macOS (DYLD_INSERT_LIBRARIES) and Windows (DLL Injection) use similar mechanisms.

Key property: Agent process is unmodified. Interception is transparent.

Coverage boundary: Interposition coverage varies by binary linkage model. Dynamically linked binaries are fully intercepted. Statically linked binaries, direct syscall invocations, and runtimes with custom syscall wrappers require fallback mechanisms. The architecture includes supplementary interception strategies for these cases.

Substrate Identity (PKI)

Each Substrate instance has a cryptographic identity managed through a certificate lifecycle backed by the platform’s own Certificate Authority. The CA uses ECDSA P-256 for certificate signing. In production, the CA private key resides in an AWS KMS HSM (FIPS 140-2 Level 2 validated); the key material never leaves the hardware boundary. A development/CI fallback uses a local PEM key for the same signing operations.

Registration: The instance authenticates with any valid access token (or OAuth 2.1 client credentials) and generates an ECDSA P-256 key pair locally via the Conduit SDK. It submits only the public key. The platform signs an X.509 certificate against the CA, returning the signed cert with a subject CN of conduit-{name} and a Subject Alternative Name encoding the instance’s fingerprint (URI:urn:datagrout:substrate:{fingerprint}). The instance is assigned a unique identifier (prefixed sub_). Certificates are short-lived (30-day default validity), eliminating the need for CRL or OCSP revocation infrastructure.
Authentication: All subsequent communication between the Substrate shim and ArbiterService uses mutual TLS. The platform verifies the client certificate against its CA chain, and the Substrate verifies the server certificate. No tokens or secrets are transmitted after initial registration.
Rotation: When a certificate approaches expiration, the instance authenticates with its current certificate (via mTLS) and submits a new public key. The platform issues a fresh certificate and revokes the old one. The short validity window means rotation is a routine operation rather than an exceptional one.
Revocation: Compromised or decommissioned instances have their certificates revoked immediately. The ETS-backed identity registry provides O(1) fingerprint lookups for authentication decisions.

The CA certificate is public and available at a well-known endpoint (/ca.pem) for independent verification. It is also embedded in Conduit SDK builds at release time, enabling zero-download trust establishment for new instances.

This PKI model means every policy decision request is cryptographically authenticated. ArbiterService knows exactly which Substrate instance is asking, and the Substrate can verify that the decision came from the legitimate governance engine. The same CA that anchors Substrate identity also anchors the trust chain for Cognitive Trust Certificates (see Cognitive Trust Certificates: Verifiable Execution Proofs for Autonomous Systems), creating a unified root of trust for both client identity and workflow integrity.

Conduit Transport Layer

The mTLS identity and communication layer is provided by Conduit, an open-source MCP client SDK available in Rust, Python, and TypeScript. Conduit handles certificate bootstrap, auto-discovery (environment variables, ~/.conduit/ directory), rotation, and all transport-level concerns. The Substrate shim uses Conduit internally for its connection to ArbiterService.

This has a significant architectural consequence: because the Substrate shim connects through Conduit, every agent running on Arbiter Substrate is automatically exposed to the full DataGrout platform as native primitives. Conduit speaks standard MCP protocol, so the connection that delivers governance decisions also delivers:

All configured integrations – every MCP server and connector the user has configured in their hub is available through the gateway. If the user has connected Salesforce, GitHub, Slack, a database, or any other integration, the Substrate agent can call those tools directly through the same Conduit connection. No additional integration work on the agent side.
Semantic discovery – agents can search for tools by intent rather than by name, across all integrated systems
Guided workflows – stateful, step-by-step workflow navigation where the platform presents options and the agent chooses
Logic Cell – per-agent symbolic memory (Prolog fact storage) for zero-token retrieval of learned knowledge
Prism type transformations – semantic type conversion between tools (e.g., crm.lead@1 to billing.customer@1) with automatic adapter discovery
Flow orchestration – multi-step workflow execution with CTC validation and optional human approval gates
Credit tracking – every operation returns an itemized receipt with cost breakdown

Communication is bidirectional. Conduit maintains a persistent connection (via SSE or long-lived HTTP) through which the platform can push events back to the agent: file change notifications, webhook deliveries, cron triggers, process state updates, and any other percepts that the Governor module or the platform itself generates. An agent does not need to poll for events – they arrive through the same Conduit connection that handles governance.

The result is that governance and capability are unified through a single transport. An agent connecting to Arbiter Substrate for command-level policy enforcement simultaneously gains access to the entire DataGrout intelligence layer with no additional integration work. The Substrate shim intercepts system calls and routes them through Conduit for governance decisions; the agent’s own code can use the same Conduit connection (or a separate Conduit client instance) to discover tools, store symbolic facts, execute workflows, and receive events.

Semantic Intent Extraction

Raw syscalls lack context. The Substrate shim enriches them:

Example:

// Agent calls:
unlink("/home/user/project/temp_data.csv")

// Substrate intercepts and enriches:
{
  "syscall": "unlink",
  "path": "/home/user/project/temp_data.csv",
  "process": "python3",
  "pid": 12345,
  "intent": "cleanup",           // Extracted via heuristics
  "risk_level": "medium",
  "context": {
    "cwd": "/home/user/project",
    "recent_commands": ["read temp_data.csv", "process data", "write results.json"]
  }
}

Intent extraction strategies:

Call stack analysis (what function triggered this?)
Path analysis (tmp, config, data?)
Pattern matching (known operation types)
History correlation (recent commands suggest purpose)

API-Based Governance

The Substrate shim sends the enriched request to ArbiterService over mTLS, including the agent identity, the command details (type, arguments, extracted intent, risk level), and the execution context.

ArbiterService evaluates the command against its rule packs and responds with a cryptographically signed decision containing: the verdict (allow, deny, or redact), the reasoning (which rule or phase produced the decision), a confidence score, detected side effects, any output redaction rules to apply, and an Ed25519 signature covering the entire decision payload.

The Substrate shim verifies the signature before acting on the decision. This prevents tampering with policy decisions in transit and creates a non-repudiable audit trail.

Transparent Execution

Agent sees normal syscall semantics:

Allow decision:

os.remove("/tmp/cache/file.txt")  # Returns success
# Behind scenes: Substrate -> ArbiterService -> "allow" -> executes

Deny decision:

os.remove("/etc/passwd")  # Raises PermissionError
# Behind scenes: Substrate -> ArbiterService -> "deny" -> blocked -> EACCES

Agent cannot distinguish Arbiter blocking from OS permission denial.

Output Redaction

The Substrate shim filters sensitive data from outputs before the agent sees them.

Example:

# Agent executes:
cat ~/.aws/credentials

# Without Arbiter Substrate:
[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

# With Arbiter Substrate (redacted):
[default]
aws_access_key_id = [REDACTED]
aws_secret_access_key = [REDACTED]

Redaction patterns: API keys, private keys, passwords, tokens, PII (emails, SSNs).

Field-Level Redaction

Beyond simple pattern matching, the redaction engine supports policy-driven field-level redaction. Operators configure per-field redaction strategies in their server or integration policy, and the engine walks every structured output recursively, applying the specified strategy to matching fields.

Available strategies include:

mask_email – preserves the first character of each part while masking the rest (e.g., j*****@e******.com)
mask_phone – replaces all digits with asterisks while preserving formatting
mask_all – replaces the entire value with asterisks
scramble – replaces the value with a deterministic fake that preserves the data format. Uses HMAC-SHA256 with a deployment-specific salt so that the same input always produces the same fake (linked records stay consistent across redacted outputs). The scrambler detects value type by field name and content pattern, then generates contextually appropriate fakes: realistic email addresses, phone numbers, names drawn from a corpus, street addresses, company names, dates, SSNs, URLs, and free-text descriptions
apron – reveals a configurable number of characters at the start and end while masking the middle (e.g., ab******om with apron size 2)
fixed_length – replaces any value with a fixed-width mask regardless of original length

Field matching uses smart detection: beyond exact field name matches, the engine infers email-related fields via word-boundary analysis (e.g., a policy on "to" also covers "reply_to" and "to_address" but not "total" or "factory"), and values containing email patterns are matched even when the field name is ambiguous. Canonical tool references (e.g., salesforce@1/get_leads@1) are never redacted, even when they contain @.

When the server policy forbids PII (pii_allowed: false) and a tool is annotated as PII-producing (pii: true), the engine applies automatic heuristic masking to any output value that matches email or phone patterns, regardless of whether a specific field redaction policy exists.

Pre-Execution Semantic Guards

Redaction governs what agents see in outputs. Semantic guards govern what agents are allowed to execute in the first place. Before any tool call reaches the underlying system, a multi-layer guard evaluates the request against the active policy:

Integration allowlisting – restricts which integrations (e.g., Salesforce, GitHub) an agent can access. An agent attempting to call a tool from a disallowed integration receives a structured error.
Side effect classification – each tool is annotated with its side effect type (none, read, write, delete, etc.). The policy specifies which side effect categories are permitted. A read-only policy blocks all write and delete operations at the guard level, before execution begins.
Destructive operation gating – tools annotated as destructive are blocked unless the policy explicitly allows destructive operations.
Scope validation – if a tool requires specific OAuth scopes, the guard verifies that those scopes are present in the session’s granted scope set. Missing scopes produce a structured error listing exactly which scopes are needed.
PII flag enforcement – tools annotated as PII-producing are blocked when the policy forbids PII.
Dynamic argument scanning – even when a tool is not annotated as PII-producing, the guard scans the request arguments for obvious PII patterns (email addresses, SSN formats) and blocks execution if the policy forbids PII. This catches cases where an agent passes sensitive data into a tool that was not expected to handle it.

These guards run before the tool executes, before any network call or side effect occurs. The combination of pre-execution guards and post-execution redaction creates a two-sided enforcement boundary: agents cannot invoke operations they are not allowed to perform, and they cannot see data they are not allowed to access in the results of operations they are allowed to perform.

Security Model

Threat Model

What Arbiter Substrate prevents:

Accidental file deletion (rm -rf /)
Credential leakage (cat ~/.ssh/id_rsa)
Unauthorized network access
Privilege escalation (sudo without policy)
Resource attacks (fork bombs, disk fill)

What Arbiter Substrate does not prevent:

Malicious agent code (assumes cooperative agent)
Kernel exploits (operates at syscall layer, not kernel)
Hardware attacks, side-channel attacks

Assumption: Agent is not intentionally malicious, but may make mistakes or be exploited.

Policy Enforcement Layers

Policy evaluation cascades through layers of increasing cost and latency:

Layer 1: Local safe-list (no network call)

Read-only, zero-risk commands (ls, pwd, whoami, date, echo) execute immediately without contacting ArbiterService.

Layer 2: Rule pack evaluation (Prolog, <10ms)

Commands are evaluated against signed rule packs using symbolic pattern matching. Rule packs classify commands by type (file operations, git operations, network calls, LLM API calls, dangerous commands) and cross-reference against side effect definitions and the active policy configuration.

Layer 3: LLM evaluation (2-5s)

Commands that match no rule pack pattern fall through to full agentic reasoning. ArbiterService uses LLM inference to evaluate intent and risk for novel or ambiguous commands.

Layer 4: Human approval (manual)

High-risk operations that cannot be resolved symbolically or by LLM are queued for human review.

In practice, the vast majority of commands resolve at Layer 1 or Layer 2, keeping average decision latency well under 10ms.

Rule Packs

ArbiterService distributes three types of signed rule packs:

Policy Rules: Pattern-based command classifications. Safe read-only commands are allowed. Git read operations (status, log, diff) are allowed; git write operations (commit, push, merge) are allowed only when the policy permits write side effects. Dangerous commands (rm, mkfs, fdisk, dd) are always denied. LLM API calls to known providers are allowed with cost tracking.

LLM Pricing Database: Comprehensive model pricing for major providers (OpenAI, Anthropic, Google) with per-million-token input/output rates. This enables cost tracking and budget enforcement at the command level – the Substrate can estimate the cost of an LLM call before it executes.

Side Effect Definitions: A taxonomy of side effect categories (network, filesystem write, filesystem delete, process spawn, etc.) with risk levels and command-to-side-effect mappings. Policies reference these categories to control what operations agents are permitted to perform.

All rule packs are signed with the platform’s Ed25519 signing key — the same key used to sign CTCs, policy decisions, and machine-client JWTs (see Cognitive Trust Certificates: Verifiable Execution Proofs for Autonomous Systems for the key separation model). Substrate instances cache rule packs locally and verify signatures against the platform’s published Ed25519 public key before use, ensuring that rule packs cannot be tampered with after distribution. Because the signing key is distinct from the ECDSA P-256 CA key used for X.509 identity certificates, compromise of one does not affect the other.

Governance Hub

Rule packs are not static. The Governance Hub provides a community-driven process for evolving the rule set:

Submission: Users submit rule proposals specifying the command or tool being governed, the decision (allow, deny, or require approval), resource characteristics (idempotent, paid, estimated cost, side effects), and data handling properties (PII types, redaction requirements).

Voting: Submitted rules enter community review. Community members can upvote or downvote proposals. Admin votes carry 10x weight. When a rule’s vote score crosses the threshold, it advances to automated review.

Gatekeeper: An AI-powered Gatekeeper agent evaluates rules that reach the voting threshold. The Gatekeeper assesses security implications, metadata accuracy, abuse potential, and overall quality. It returns an approve or reject decision with a confidence score and reasoning. This is conservative by design – ambiguous submissions are rejected with suggestions for improvement.

Distribution: Approved rules are incorporated into rule packs, signed with the platform’s Ed25519 key, and distributed to Substrate instances through the Hub API. Clients fetch updated packs over their existing mTLS connection (authenticated by the CA-issued certificate), verify the Ed25519 signature on the pack contents, and cache locally. The distribution channel is thus doubly authenticated: the transport is verified by the CA certificate chain, and the payload is verified by the signing key.

This creates a feedback loop: operators encounter new commands or tools in production, submit governance rules based on operational experience, and the community collectively refines the policy surface. The Gatekeeper ensures quality control without requiring manual review of every submission, while the voting mechanism surfaces the rules that the community finds most useful.

Execution Tracking and Pattern Learning

ArbiterService maintains a WorldModel that tracks agent behavior over time. After each command execution, the Substrate reports the outcome (success/failure, cost, duration). The WorldModel accumulates per-agent statistics: total commands executed, success rates, cost consumption, and behavioral patterns.

This execution history serves two purposes: it provides the data foundation for the optional Governor module’s Reflection cycle (see below), and it enables ArbiterService to compute risk scores for individual agents based on their track record.

Audit Trail

Every command produces an immutable audit record containing the command details, the signed policy decision, and the execution outcome.

Compliance features:

Immutable logs (append-only, signed)
Retention policies (configurable)
Export formats (JSON, CSV, SIEM)
Real-time alerting

Supports SOC2, GDPR, HIPAA compliance requirements.

Reality Substrate Concept

Arbiter Substrate provides more than security. It establishes a reality substrate: a governed, semantically-aware execution layer.

Stable World Model

Agent perception of system state is mediated:

Without Arbiter Substrate:

Agent: ls /data
OS: [file1, file2, SECRET_KEY.txt, file3]
Agent: (sees SECRET_KEY.txt)

With Arbiter Substrate:

Agent: ls /data
Substrate intercepts: readdir(/data)
  -> ArbiterService: "Redact SECRET_KEY.txt from listing"
Agent receives: [file1, file2, file3]
Agent: (SECRET_KEY.txt is invisible)

Agent operates in a filtered reality where dangerous operations don’t exist.

Semantic Command Layer

Commands gain meaning beyond raw syscalls. ArbiterService can reason about intent (“Agent is cleaning up logs. Disk usage is 85%, so this is appropriate. Allow and log.”) rather than just evaluating paths.

Percept Integration

Command execution generates structured percepts that update the WorldModel. These percepts track patterns: file operations, network activity, resource consumption, and behavioral trends.

These percepts are also available to the optional Governor module (see Governor: Neuro-Symbolic Runtime for Token-Efficient Agent Cognition), which uses them to maintain a continuously updated world model for long-running autonomous agents.

Integration with Governor

Governor is an optional paid module that plugs into the Arbiter Substrate, adding continuous cognition for agents that need to operate autonomously over extended periods.

Where Arbiter Substrate governs what an agent is allowed to do (command-level policy), Governor governs what an agent chooses to do and when (cognitive scheduling). Governor’s Reflex cycle evaluates triggers against the WorldModel’s fact database every ~30 seconds at zero token cost. When triggers match, the Reflection cycle provides full agentic reasoning to analyze patterns and install new percepts.

Governor’s Reflection cycle accesses the execution history accumulated by ArbiterService’s WorldModel, enabling it to detect patterns like polling (repeated identical commands), excessive retries, or cost-inefficient command sequences. Learnings from Reflection are persisted to the agent’s Logic Cell as durable Prolog facts, creating a feedback loop where the agent becomes progressively more efficient.

See Governor: Neuro-Symbolic Runtime for Token-Efficient Agent Cognition for the full architecture.

Integration with Agentsmith

Arbiter Substrate agents can participate in the Agentsmith multi-agent coordination system as first-class workspace members.

From Governed to Coordinated

When a Substrate instance registers its identity via Conduit, it obtains cryptographic authentication for policy decisions. That same identity can be linked to an Agentsmith agent record, bridging the OS-level governance layer with the workspace coordination layer.

The flow:

Identity registration: The Substrate instance bootstraps via Conduit, receiving a DG-signed X.509 certificate (standard Substrate registration).
Agent registration: The instance registers as an Agentsmith agent, providing a persona (name, mission, capabilities). This creates an Agent record linked to the Substrate identity.
Workspace participation: The agent joins one or more workspaces. From this point, it appears in the workspace’s agent pool alongside internal agents.
Task assignment: When a task arrives in a workspace, the Prolog-based bidding system evaluates all agents (internal and Substrate-connected) across fit, capability, cost, risk, load, and confidence dimensions. Substrate agents compete on equal terms.
External execution: If a Substrate agent wins a bid, the task is not executed locally. Instead, it is held in “in_progress” status and delivered to the external agent through the Conduit connection. The agent executes the task using its own compute, tools, and reasoning, then reports the result back.
Completion: Task results flow back through the same API, updating the workspace and notifying other participants via PubSub.

What This Means

An external agent connected through Arbiter Substrate is simultaneously governed (every command checked against policy), capable (full DataGrout platform access through Conduit), and coordinated (participating in workspace task assignment alongside internal agents). These are not three separate integrations – they are three aspects of the same Conduit connection.

This unification matters because it means external agents operating on user machines are not second-class citizens. They bid for tasks using the same Prolog scoring as internal agents, their execution history feeds the same WorldModel, and their results are subject to the same audit trail and credit accounting. The workspace doesn’t need to know whether the winning agent runs locally or on a user’s laptop halfway around the world.

Cost and Performance Analysis

Latency Impact

Baseline (no Arbiter Substrate): 0.1-1.0 us With Arbiter Substrate: ~10ms

Is this acceptable?

Yes, because:

Syscalls are not latency-critical (agent thinks in seconds)
Bulk of agent time is LLM calls (1-3 seconds)
Security and observability have value

Agent perspective:

Agent workflow:
1. LLM reasoning (2000ms)
2. Execute command via Substrate (10ms)
3. LLM processes result (1500ms)

Total: 3510ms
Substrate overhead: 10ms (0.3% of total)

Negligible in practice.

Network and API Costs

API calls:

Request/response: ~800 bytes per command
100 commands: 80 KB, <$0.01 bandwidth

ArbiterService cost:

Rule pack decisions (Layer 2): $0 (symbolic, no tokens)
LLM evaluation (Layer 3): $1-6 per decision

Agent with 90% rule pack, 10% LLM:

100 commands: 90 at Layer 2 ($0) + 10 at Layer 3 ($1-6 each) = $10-60
vs. Pure LLM evaluation: $100-600
Savings: 90% (symbolic evaluation handles the majority at zero marginal cost)

Resource Requirements

Substrate shim:

Memory: ~5MB per agent process
CPU: <1% (syscall interception)
Disk: ~10MB (library + cached rule packs)

ArbiterService: Scales horizontally with agent count.

Comparison with Existing Approaches

vs. Containers/VMs

Aspect	Container	Arbiter Substrate
Overhead	High (100-500MB)	Low (5MB)
Setup	Complex	Simple (LD_PRELOAD)
Filesystem access	Restricted	Full (filtered)
Observability	Logs only	Full semantic audit

vs. SELinux/AppArmor

Aspect	SELinux	Arbiter Substrate
Policy language	Complex	Readable rules
Runtime learning	None (static)	Execution tracking, pattern learning
Semantic understanding	None	Yes (intent extraction)
Remote governance	None (local only)	API-based (centralized, mTLS)

vs. Prompt-Based Safety

Aspect	Prompt Safety	Arbiter Substrate
Enforcement	Best-effort	Guaranteed (syscall level)
Latency	High (LLM every command)	Low (rule pack evaluation)
Reliability	Probabilistic	Deterministic (rule packs)
Auditability	None	Complete (signed decisions)

Arbiter Substrate provides enforceable, auditable, deterministic safety vs. probabilistic prompting.

Enterprise Features

Multi-Tenant Isolation

Each organization has isolated policies and rule packs. Substrate instances authenticate to their organization’s ArbiterService endpoint via mTLS, ensuring cryptographic tenant isolation.

Dashboard and Reporting

Real-time monitoring:

Commands executed/blocked
Redactions applied
Average latency
Top blocked commands
Cost savings (rule pack vs. LLM evaluation)
Per-agent behavioral analytics

Incident Response

When agent misbehaves, real-time intervention: pause agent, investigate recent commands via the audit trail, update policy, resume. Substrate certificate revocation provides an immediate kill switch.

Conclusion

AI agents require unrestricted system access but cannot be trusted with root-equivalent permissions. Traditional security mechanisms are insufficient: too restrictive, too complex, or unreliable.

Arbiter Substrate solves this through OS-level interposition: syscalls are intercepted, transformed into semantic intent, validated against policy via mTLS-authenticated API calls, and executed or blocked transparently. Zero agent code changes required. Every decision is cryptographically signed with Ed25519, creating a non-repudiable audit trail.

Policy evaluation uses a tiered approach: safe commands execute locally, pattern-based rules resolve via Prolog in under 10ms, and novel commands fall through to LLM evaluation. Three types of signed rule packs (policy rules, LLM pricing, side effect definitions) are distributed to Substrate instances for local caching, enabling fast offline-capable decisions. The Governance Hub provides a community-driven process for evolving rule packs through submission, voting, and AI-powered gatekeeper review.

Substrate instances authenticate via a PKI model with platform-signed X.509 certificates, managed through the Conduit transport layer. Certificate lifecycle management (registration, rotation, revocation) provides enterprise-grade identity governance. Because Conduit speaks standard MCP protocol, the same connection that delivers governance decisions also exposes the full DataGrout platform – semantic discovery, symbolic memory, type transformations, workflow orchestration, and bidirectional event delivery – as native primitives to every governed agent.

For agents requiring continuous autonomous operation, the optional Governor module (see Governor: Neuro-Symbolic Runtime for Token-Efficient Agent Cognition) plugs into the Arbiter Substrate, adding persistent world-model maintenance and trigger-based cognition cycles on top of command-level policy enforcement. Governor percepts and events flow through the same Conduit connection, enabling governed agents to receive real-time notifications without polling.

Key results:

10ms average overhead (0.3% of agent workflow)
100% audit coverage (every syscall logged, every decision signed)
Policy-based redaction (field-level strategies, deterministic scrambling, automatic PII heuristics)
Pre-execution semantic guards (side effects, destructive ops, PII, scopes, integration allowlists)
90% cost reduction vs. pure LLM governance
mTLS-authenticated, cryptographically signed decision chain
Full DataGrout platform access through the governance connection
First-class multi-agent workspace participation for external agents

The architecture establishes a “reality substrate”: agents operate in a governed, semantically-aware execution environment where dangerous operations are invisible, routine operations are instant, the full intelligence layer is available through the same connection, and external agents participate as equal members in coordinated workspaces.

This document describes the Arbiter Substrate architecture for OS-level agent governance. Implementation details for policy evaluation, rule pack distribution, and certificate management are withheld to protect operational security.