ONE BINARY. COMPLETE STACK. FIFTY MEGABYTES, POSTGRES ONLY.

A compliance officer asks where every prompt, every tool call, and every model response physically resides. In most AI deployments the honest answer is "I do not know, because the vendor's sub-processor list is twelve names long." When the binary runs on your hardware and connects only to your Postgres, the answer is one address. There is no compiled-in callback to a systemprompt.io endpoint, no anonymous telemetry ping, no authentication round-trip to our service. A CISO can confirm this with a packet capture. The binary's outbound connections are the Postgres socket and the AI providers configured in the profile, nothing else.

The audit trail lives next to the data. Every tool call writes a row into mcp_tool_executions with the tool name, server, input, output, status, user_id, session_id, and trace_id, so one SQL query links a model response back to the identity that authorised it. AI request cost in microdollars, tokens, model, and provider land in the ai_requests schema. The trace module stitches identity, permission decision, tool call, and model request into one trace_id per request. An auditor runs a SQL query against your Postgres. No API key to a SaaS audit service sits in the loop.

Retention and export stay under customer control. Skills, configuration, and profile data export as Markdown with YAML frontmatter through a file-based sync pipeline, so a compliance team can diff them in their own git. Anonymous session data is purged on a schedule by a job that runs in the same binary. Session retention is governed by the session repository. The binary, the extension crates, and the database schema are the complete artifact. No vendor sits in the loop after handover.

A platform engineer rolling out Claude across teams usually wires six things together by hand. An OAuth server, a permission layer, a host that supervises agent processes, a secret store that keeps API keys out of model prompts, an audit pipeline a SOC 2 auditor will accept, and a way to ship reusable skills without asking each user to clone a repo. Six vendors, six failure modes, six upgrade cycles, six processor contracts the security team has to review. systemprompt.io compiles all six into one Rust binary, so the control plane is one artifact to monitor, one process to patch, one contract to review.

The binary bundles identity, permission enforcement, agent lifecycle supervision, server-side secret injection, audit persistence, and skill distribution. Identity is an OAuth2 server with PKCE and WebAuthn passkeys. Permission enforcement is a single check that runs before every governed handler. Agent lifecycle supervision is a reconciler that drives running processes to the configured state. Server-side secret injection sets credentials on the subprocess environment before the tool process spawns, so they never appear in a prompt. Audit persistence writes every tool call to Postgres with its identity and trace_id. Skill distribution emits versioned Markdown with YAML frontmatter. Each subsystem is named inline in the bullets below with a code reference for every claim.

One release build against a customer fork produces one artifact. The same artifact runs on a laptop for a developer smoke test, in a Kubernetes pod for staging, and inside an air-gapped subnet for production. The CTO's "what am I actually self-hosting" question resolves to one answer, the whole stack. No sidecar, no outbound call to a vendor service, no second daemon to upgrade in lockstep.

The security team has already bought identity, secrets, and a SIEM. They will not approve a deployment that asks them to rip any of it out. systemprompt.io does not require that. The Extension trait exposes override points for AI providers, background jobs, database schemas, HTTP routes, and tool providers, so a team keeps the vendors the security review has already cleared and drops systemprompt.io in as the governance layer. What an extension does not override stays populated by the built-ins.

Integrate. Identity is not an extension override. It is OAuth2 federation at runtime configuration. Point the binary at Okta or Auth0 as the issuer and the external JWT flows into the permission check unchanged. Forward audit events out to Datadog or Splunk with a scheduled job that reads the audit schema and pushes, or with a lifecycle hook handler. Pull credentials from Vault the same way, through a job implementation that writes into the server-side secret store. Identity, secrets, and telemetry stay in the systems the security team already audits. The permission check, the rate limits, and the lifecycle hooks still run on every request inside the same process, so the governance plane does not move.

Replace. For air-gapped or greenfield deployments, the binary ships the built-ins and runs with PostgreSQL as the only dependency. OAuth2 with PKCE, JWT generation, WebAuthn passkeys, profile-defined rate limits, and per-request cost attribution in microdollars all compile in. One artifact, one database, zero outbound calls. That resolves the staff engineer's "how do I run this in an air-gapped VM" question without adding a second process.

A staff engineer reading the architecture wants to know exactly where the binary ends and the rest of the world begins, because that boundary is where the security review ends. The boundary is concrete. AI model calls, identity providers, SIEM sinks, MCP-speaking agents, and operator browsers sit outside. Everything inside the binary terminates at one of four named surfaces, each with a file a reviewer can open.

AI providers. The provider factory routes to any upstream you operate through a custom endpoint, including a self-hosted inference cluster or vLLM gateway. Commodity providers (Anthropic, OpenAI, Gemini, Bedrock) match a provider name string to a concrete implementation. Cost is attributed per request in microdollars, so a finance review of AI spend is a SQL query on your own database rather than an invoice reconciliation.

Identity. The OAuth2 discovery document is served from /.well-known/oauth-authorization-server, the path OIDC clients already probe. Federated tokens are validated by the same permission check the built-in OAuth server uses, so a security team reviews one code path whether identity is local or federated.

Telemetry. Analytics events implement a stable JSON shape through a server-sent-event serialisation trait, which Splunk, Datadog, or ELK ingest without a custom parser. A SIEM search by user_id or session_id is one query, not a regex over free-form strings, so the audit workload your team already runs extends to AI agent activity without a glue service.

Agents. Claude Desktop, Claude Code, and any MCP client connect to the binary as tool consumers. Per-server health checks run under the MCP monitoring module and agent-to-agent traffic terminates in the A2A server. Every tool call, whichever client originated it, hits the same permission middleware, so a leaked admin token in a CLI is blocked at the same line as a leaked token in a browser.

A security lead does not ask "is there governance". They ask "what code, in what process, on what line, decides whether a write tool against a customer database runs". In this binary the answer is a single function in the MCP permission middleware. It validates the JWT, extracts the user claims, compares OAuth2 scopes against the required permission, and returns an error before any handler runs. Nothing reaches the tool runtime around it, so a CISO can cite one line in an audit instead of stitching logs across a proxy and a sidecar.

Two companion surfaces run on the same call path. Rate limits live in a profile YAML file with per-tier multipliers so a tightening response to a live incident is a config push, not a release. The lifecycle hook surface is an enum variant per moment an external action might need to fire. Before a tool runs, after it runs, after it fails, on session start, session end, prompt submit, notification, stop, subagent start, and subagent stop. The variant list is the contract.

Policy values live in YAML profiles the binary reads at startup, so a security team ships a tightened rate limit or a new permission tier without touching Rust and without waiting for a product release. The enforcement code lives in the binary on the same call path as the tool. No sidecar can be misconfigured into a no-op, which resolves the CTO's "does this replace what I'm building" question. The enforcement layer is a single function call away from the tool dispatcher, and that is what a sidecar has to emulate.

An architect drawing the box diagram wants one place where every AI request from every agent crosses a controlled line. That line is the binary, and the contract is a single Rust trait. An extension implements the trait to contribute HTTP routes, background jobs, database schemas, migrations, AI providers, tool providers, page prerenderers, roles, required assets, and configuration sections. What an extension does not override falls through to the in-binary defaults, so no path lets a component sneak in without the trait declaring it.

Two deployment shapes use the same trait. Run the binary with every default on, and one artifact provides identity, permission enforcement, MCP supervision, secrets, audit, and skill distribution against one Postgres. That is the air-gapped shape a staff engineer cares about, a single binary in a subnet with no internet egress. Override the AI provider routing, the HTTP router, and an analytics job, and the same artifact becomes a thin policy layer that hands identity to Okta and telemetry to Datadog while still running the permission check and the lifecycle hooks on every call. The security review is the same trait in both cases, which is what makes the build-vs-buy answer defensible.

The codebase is exercised by integration tests, load tests, fuzz tests, and benchmarks, so the "is it production-ready" question has a test suite to read rather than a sales claim to trust. The Rust runtime has no garbage collector to schedule around, a real point for latency-sensitive agent calls that belongs on a dedicated benchmark page, not here.

The team adopting this does not want a SaaS dashboard with limited webhooks. They want to add a route, a job, a schema, and a custom AI provider, and ship it as part of the same binary the security team already approved. systemprompt.io is a source-level dependency. The integrator adds the crate to Cargo.toml, implements the extension trait, runs a release build, and ships one artifact. Proprietary logic compiles into your binary, not into a third-party service, so source-available licensing covers both the library and the extensions together.

The extension trait exposes methods across every domain. HTTP routes, database schemas, migrations, background jobs, AI model routing, MCP tool providers, static page prerenderers, YAML config namespaces, permission roles, and required static assets. Each method has a predicate so the registry can skip extensions that do not contribute in a given domain, and a default so extensions only write the methods they override. The registry that loads them lives in a typed registry module a reviewer can read end to end in one sitting.

Version pinning is the integrator's call. The artifact compiled today runs the same way next year unless someone bumps the dependency and recompiles, so no forced upgrade can land on a production deployment from a vendor. A staff engineer answering "can I freeze this for a regulated audit cycle" has a one-line answer. Pin the crate version in Cargo.toml.