EVALUATE FREE. PROVE THE GOVERNANCE ON YOUR LAPTOP.

A CISO evaluating a governance vendor keeps hitting the same wall: the free tier is a playground, the real product sits behind a procurement cycle, and nobody finds out if the enforcement actually works until a contract has been signed. systemprompt.io inverts that. The template ships the full Rust binary that paying customers deploy. The governance pipeline is not gated, the audit trail is not gated, and the scope checks are not gated. What you evaluate is what you run in production.

The binary compiles to a single artifact under 50 MB. It needs PostgreSQL and nothing else. One process handles HTTP serving, MCP governance, agent orchestration, content, analytics, and background jobs, so there is no sidecar to stand up and no cluster to provision for the evaluation. A staff engineer can have the binary running and accepting governed tool calls inside a single work session.

Every tool call that reaches the server passes through four inline checks before execution: a scope check against the caller's role, a secret scanner that walks the input against a fixed pattern set, rate limiting that is sized per endpoint, and an audit write that records the decision. The checks run in-process on the request path, not as post-hoc log analysis, so a denied call never reaches the backend the agent was targeting. The pre-answer for the CISO is in the audit row: every allow and every deny writes one structured record, which is the evidence a SOC 2 or ISO 27001 auditor actually reads.

A CTO evaluating a governance layer needs to know the minimum install works without a procurement cycle. The template repo is one clone, one build, and a local Postgres. There is no sign-up flow, no licence key, no phone-home, and no demo environment that diverges from the real deployment. An engineer with Rust and PostgreSQL already installed is usually watching the first governed tool call inside an hour.

Prerequisites

You need Git, the Rust toolchain from rustup.rs, and PostgreSQL 18 or later running locally or on the network. Rust is the build tool the binary compiles from. PostgreSQL is the only runtime dependency, because the audit trail lives there alongside the configuration tables. No other services.

Clone and Build

git clone https://github.com/systempromptio/systemprompt-template.git
cd systemprompt-template
cargo build --release

Configure

Copy the example environment file. You set two things: the Postgres connection string and an AI provider API key. The template ships sensible defaults for every other knob, which means the evaluation does not depend on a long configuration session before you see the gate work.

cp .env.example .env
# Edit .env with your PostgreSQL connection string
# Add your Anthropic API key (or other provider)

Run

./target/release/systemprompt serve

The server starts on port 3000. A request to the health endpoint confirms the database connection and returns structured JSON. From that point, every tool call routed through this server is governed. You can verify this by calling a tool the agent does not have scope for and watching the request get rejected before it reaches the backend.

An evaluation that only confirms the product starts up is not an evaluation. The template ships pre-configured governance rules that map each gate to a specific failure mode a real customer would have. Your test plan is to try each failure mode against your own agents and check the audit table afterwards.

Scope gate, against privilege drift

Connect your own agent and call the same tool with different role scopes. The gate compares the caller's typed role against the tool's required scope. Admin-scope calls pass, user-scope calls are denied, and the audit row records which rule fired. A CISO reading the row can confirm who made the call, what policy matched, and why the backend never saw the request. This is the answer to the audit question in the same paragraph as the claim.

Secret scanner, against credential leak

Paste a test AWS access key, a GitHub token, or a PEM private key into a tool call input. The scanner walks the input against the pattern table and rejects the call before the agent can exfiltrate the secret. The credential never crosses the tool boundary, and the audit row names which pattern matched. The reason to evaluate this on your own traffic is to find out whether your inputs trip false positives before the contract is signed, not after.

Audit trail, against compliance failure

Every allow and every deny writes one structured row. Query the audit trail through the CLI, or export it to your SIEM to see how the schema lands in Splunk or Datadog. A SIEM join that needs a custom adapter is the single biggest cost in an AI governance rollout, and this is the test that tells you in advance whether the schema works with your existing infrastructure.

Cost attribution, against hidden spend

Every AI request writes an attribution row with the agent identity, the provider, the token counts, the latency, and the cost. Run several agents during the evaluation and inspect the per-agent totals. The answer to "can we tell which team is burning the API budget" either shows up in the table or it does not, and that is the answer before anyone signs a contract.

The template is the shape of a real deployment. Governance rules, agent definitions, and MCP server registrations all live as YAML in Git, so the evaluation runs against the same configuration surface a platform team would manage in production. A staff engineer reviewing the template sees the infrastructure-as-code workflow they will use on day two, not a dashboard that disappears when they upgrade.

Configuration as YAML in Git

Every governance rule is a file in the repo. Review changes in pull requests. Roll back with git revert. A policy change is a diff a security lead can review before it reaches production, which is what a build-in-house team usually realises they also need to build, three months into their own project.

Pre-configured agents at multiple scopes

The template includes sample agents at admin, user, and restricted scope. You do not have to write any configuration before testing the scope gate. Swap in your own agent definitions once the sample agents have shown you the denied call behaviour.

MCP server registry with OAuth2

The template registers MCP servers with per-server OAuth2 configuration. Every tool call through every MCP server passes through the same governance layer. The evaluation confirms this by adding one of your own MCP servers and running the same tool against the same gate.

Rust extension traits for the work your team will actually do

systemprompt.io is a library, which means your code compiles into your binary. Add routes, tables, background jobs, and page providers through typed Rust traits. There is no plugin runtime to version against, no sandbox overhead, and no compatibility layer to break when the binary upgrades. The extension surface is the same surface Edward uses to build the production features.

Once the denied call has shown up in the audit table and the SIEM export has landed, the evaluation has done its job. The next step depends on what the evaluation told you. For most teams, the answer is either to extend the template with their own policies and run it against a staging workload, or to book a call to talk about the deployment profile. Neither conversation needs a procurement cycle to start.

Self-guided

The documentation covers deployment, configuration, extensions, and every service in the binary. The guides walk through connecting MCP servers, configuring compliance rules, and setting up analytics exports. The live demo shows the governance checks executing in real time for teams who want to see the pipeline before cloning.

Talk to the engineer who built it

Teams evaluating enterprise deployment, custom integrations, or commercial licensing can book a call below. The conversation is with the person who wrote the binary, and the evaluation data you already have makes it a technical discussion, not a sales pitch.