Self-hosted AI agent control plane: how to build one, with Prismor open source

self-hosted-ai-agent-control-plane.md

Self-Hosted AI Agent Control Plane: How to Build One (with Prismor Open Source)

A self-hosted AI agent control plane intercepts every tool call an AI agent makes and enforces policy before execution, running entirely on your own infrastructure.

Source: https://github.com/PrismorSec/prismor

What a self-hosted AI agent control plane is

A control plane for AI agents sits between an agent's reasoning loop and the tools it executes: shell, filesystem, HTTP, and MCP servers. It evaluates each tool call against a policy, then allows it, blocks it, or routes it to a human for approval. "Self-hosted" means the enforcement runtime and the audit log stay on infrastructure you control, with no tool-call data sent to a vendor SaaS.

This is not content filtering. A prompt firewall reads what an agent says. A control plane governs what an agent does: the shell command it runs, the package it installs, the API it calls. An agent can pass every prompt-injection check and still run DROP TABLE. The control plane is the layer that stops the action.

Prismor is an open-source, Apache-2.0 implementation of exactly this. It self-describes as a "self-hosted runtime control plane for AI agents," is written in Python, has 275 GitHub stars, and governs Claude Code, Codex, Cursor, and GitHub Copilot without an agent rewrite.

Three layers of the agent stack: build, run, govern

Before building a control plane, locate it in the stack. The govern layer is orthogonal to the framework that wrote the agent and the platform that runs it.

Layer	Job	Examples
Build	Write the agent's reasoning and tool logic	LangChain, CrewAI, OpenAI Agents SDK, Pydantic AI
Run	Host the agent, give it memory, connectors, isolation	agent runtimes, internal platforms
Govern	Intercept tool calls, apply policy, audit, enforce compliance across any agent	the control plane you are building

A control plane you build once governs agents from any framework and any runtime. That is the reason to treat it as its own layer instead of a feature bolted onto one agent.

Architecture: the five components of a control plane

A self-hosted control plane needs five parts. Build each, or adopt an implementation that ships them.

1. Interception point. The hook where a tool call is captured before it runs. This is the single most important design choice. See the next section.
2. Policy engine. The evaluator that scores a captured call against rules and returns a verdict: allow, block, human-in-the-loop approval, or modify.
3. Enforcement modes. A switch between observe (log only) and enforce (block before execution), so teams can roll out safely.
4. Audit log. An append-only, tamper-evident record of every evaluated call, its arguments, and its verdict. Sign entries so the trail is non-repudiable.
5. Secret handling and egress control. Keep credentials out of model context, and hold a network egress allowlist as the failsafe under the policy engine.

Where to intercept: local runtime hook vs reverse proxy

A control plane can capture tool calls at four boundaries. The choice determines what it can see.

Interception layer	What it sees	What it misses
Reverse-proxy gateway	Network and MCP calls that cross the wire	Local shell, filesystem writes, stdio MCP
Local runtime hook	Every tool call in-process: shell, files, HTTP, MCP	Nothing at the tool boundary; runs per agent
Endpoint kernel agent	Host-level syscalls	Higher-level tool intent and arguments
Out-of-band SaaS	Post-hoc logs	Real-time blocking; the action already ran

A local runtime hook is the right default for a self-hosted control plane. It runs in-process, so it sees a file write that never touches the network, and it adds no proxy round-trip. A reverse proxy is blind to local shell and filesystem activity, which is where agent damage usually happens. Prismor runs as a local hook and reports a per-call overhead near 0.8 ms, versus the several seconds a gateway accumulates across a 20-call agent loop.

Enforcement modes: observe before you enforce

Ship two modes and default to the safe one.

• observe: evaluate every call and log the verdict, block nothing. Run this for 7 to 10 days to learn which tool-call combinations actually happen in your environment.
• enforce: block dangerous calls in real time before execution.

Make policy authoritative, not the install flag. A stale local observe flag should never override a signed organization policy that says enforce. Locking everything on day one makes staff route around the control plane. Lead with logging and audit, then harden only the genuinely dangerous paths.

Policy model: govern actions and combinations, not just access

Identity-scoped access control answers "who can call this tool." A control plane also answers "should this call happen now, given what already happened this session."

• Per-call policy. Write rules that govern individual tool calls, scoped to what a specific agent is supposed to do. A read-only database agent should never execute a bash script.
• Session-aware combination rules. Track taint across a session. If an agent reads an untrusted document early, block the sensitive external call it reaches for later in the same session. This is the lethal-trifecta pattern: untrusted content plus a critical action is the combination to stop, not either one alone.
• Defense in depth. Escalate through deterministic rules, then a semantic classifier for ambiguous calls, then human approval, with network egress blocking underneath as the final failsafe.

Build vs adopt: Prismor open source

Building all five components is real work. Prismor open source ships them under Apache-2.0, so a self-hosted control plane is an install rather than a project.

pip install prismor
prismor setup
prismor install-hooks

Core commands:

Command	What it does
prismor install-hooks	Register the local interception hook for supported coding agents
prismor dashboard	Open the local dashboard for tool-call telemetry and verdicts
prismor supplychain	Score packages and block risky installs before they run
prismor semantic-check	Run the hybrid prompt-injection classifier
prismor scope	Synthesize per-session, task-scoped rules for headless agents
prismor trail verify	Verify the signed, tamper-evident audit trail
prismor attest verify	Verify a signed posture and inventory attestation bundle
prismor discover	Scan hosts for shadow AI agents

Everything runs locally against a local dashboard. Enforcement modes are observe (default) and enforce, with policy treated as authoritative regardless of the local install flag.

Getting started

1. pip install prismor && prismor setup
2. prismor install-hooks to attach the interception layer to your agents.
3. Run in observe mode for a week and watch the dashboard to learn real tool-call patterns.
4. Write per-call and session-combination policies for the dangerous paths you find.
5. Switch to enforce, and verify the audit trail with prismor trail verify.

Keywords

self-hosted AI agent control plane AI agent governance agent policy enforcement tool call interception LLM security runtime control plane Prismor prompt injection defense agent audit trail MCP Claude Code Codex Cursor GitHub Copilot LangChain CrewAI OpenAI Agents SDK Python Apache-2.0 OWASP LLM Top 10 NIST AI RMF how to build an agent control plane enterprise LLM access control how to audit AI agent tool calls secret cloaking supply chain security lethal trifecta observe vs enforce platform engineering security team