Skip to main content

​
Overview

Steerholm is two planes over one boundary: agents act on the action plane, you govern from the control plane. Every action an agent takes flows through the daemon, which authenticates the agent and checks it against your policy before it reaches a server — so an agent can only ever do what you granted. This page is the technical view of the control plane: how a grant becomes a governed connection, and how the boundary is enforced on every request.

​
System diagram

Agents
▼ Streamable HTTP + Bearer token
Steerholm daemon /mcp
Agent Verification
Policy Enforcement
Tool Routing
▼ spawn / connect
MCP Servers

​
Request flow

​
Entry points

holm — control plane

Your governance surface. Manage servers, agents, policies, and the daemon — this is where you control what every agent can do.

/mcp — action plane

The agents’ surface: they connect here over Streamable HTTP with a Bearer token to act. Requires authentication and has no admin commands.
Agents connect to /mcp; they do not run the holm admin CLI.

​
Server processes

Servers are shared by all agents — the daemon runs one set of server processes and isolates agents by policy, not by per-agent processes.

Stdio servers

Started and managed by the daemon as shared server processes.

Streamable HTTP servers

Connected by the daemon as shared server sessions.

​
Connection flow

1

Agent connects

The agent connects to http://127.0.0.1:4767/mcp over Streamable HTTP.
2

Authentication

The agent sends Authorization: Bearer steer_sk_.... The daemon resolves the agent by checking the access key against stored hashes. The access key determines the agent — it cannot be self-declared.
3

Request authorized

The shared MCP server resolves the agent’s policy and filters or routes tools through daemon-managed servers.
4

MCP traffic flows

Standard MCP traffic flows through Steerholm. Every call_tool is checked against the policy before forwarding.

​
Summary