For teams letting AI agents change infrastructure

Your AI agent wants to delete production. Who's stopping it?

Joltrin blocks a risky step, like dropping a database, until the steps before it are recorded, and tells the agent what to do first.

You put it in front of the one tool you want protected. Your agent asks Joltrin before it acts. Open source and free to try in your browser.

Try to make an agent drop a database Watch the short demo

Or run it now (Go 1.26.10 or newer)

go run github.com/sharedcode/joltrin/v5/examples/verify_barrier@latest

It checks the recorded trace, not the world. What this does not prove

// db-maintenance runbook

drop_prod_db BLOCKED backup_validated missing

validate_backup BLOCKED backup_taken missing

take_backup ALLOWED

validate_backup ALLOWED

drop_prod_db ALLOWED

The order is enforced by the barrier, whatever the agent says it already did.

Be the agent. Try to drop the database.

Pick a step. The barrier answers every time, and it does not take your word for anything.

These are the same rules, replayed in the page. For the real compiled check, use the agents page.

Why not just ask your AI to write this?

An AI can write your rules. It cannot sign for your backup system.

A prompt or a policy file can be argued with. Joltrin Private Intent moves the proof outside the agent, so the agent has nothing to talk its way around.

Your rules stay private

Your wording is sealed in a vault on your machine. The checker sees rule ids and what is required, never what you wrote.

Other systems sign, not the agent

The backup system signs that the backup exists. A named person signs the approval. One approval covers one action, and you can revoke it.

The tool that holds the keys checks

The action only runs with a signed receipt for that exact action. No receipt, no run, and the block says what is missing.

Watch an agent get blocked, then approved Simulated in your browser. Open source, free to run.

Technical demo

The engine compiled to WebAssembly. Run ACID transactions, vector search, a benchmark, and an agent checkpoint resume, all in your browser.

Runs on this page ↓

Joltrin Arena

Open →

A cluster simulation. Add workers, crash storage nodes, and spike load to see the concepts behind the engine. It illustrates the design, it is not a live cluster.

Open the simulation →

Joltrin Arena: B-tree game

Play →

Guess how fast the real B-tree is, then run it in your browser and see how close you got. Four short levels, measured on your device.

About three minutes →

Agent verification barrier

Open →

The same verify barrier that gates the MCP and A2A servers. Try to drop a database before the backup is validated and watch it refuse.

Open the barrier →

Start with your setup.

Try a safe example first. Then put the same checks in front of your own tools.

Try in the browser → No install. Block a database drop, record its prerequisites, and retry. Tools are simulated. Run the Go example → One command, no clone. See the barrier reject and then accept a step in your terminal. Connect an MCP agent → Install the server, check the setup, and try the sample runbook. No Go needed.

How it works

The agent and the verifier are separate.

An agent that proposes an action and also judges it safe can be wrong in both places for the same reason. Joltrin keeps the two apart. The agent emits intent. The check runs outside the agent's context window, against the steps the server has actually recorded and the runbook's rules. The check is Go code, so it gives the same answer for the same trace and rules, and the system that performs the action decides whether to wait for it.

Order matters most where an action is hard to undo: dropping a database, changing infrastructure or network topology, moving money, rotating credentials. In those cases the wrong order is the failure, and a runbook can state the right order once and check it on every call. The flow is: the agent proposes a step, Joltrin checks it against the recorded trace and the rules, a missing prerequisite comes back as a structured block, the agent runs the steps it names or stops and asks, and the integrating system lets the action through only after the check passes.

// How the verification barrier sits between the agent and real systems

1. AI Agent

Emits intent: a tool call, API mutation or shell command

2. Verification Barrier

Checks preconditions and safety rules against the run's trace

3. Decision

ALLOW (step committed) BLOCK (nothing runs, fix returned)

4. Real Target

Databases, Cloud APIs, K8s, MCP / A2A Services

Preconditions

A step is blocked until the states it needs have been established in the run's trace. What the agent claims does not count. A backup must be validated before a drop.

Safety rules

A rule can forbid reaching a state unless another state already holds, for example no database drop without a validated backup.

Rollback stays reachable

When a runbook is registered, it is checked that rollback can still be reached from every state. A runbook that can dead-end is refused.

Experience the verification barrier live in your browser: Click through the exact verify runbook gating MCP and A2A agents. Try dropping a database before taking a backup.

Launch Agents Barrier Demo →

Test it with your own AI agent

Any agent that supports MCP can use the barrier. This downloads a binary of about 6 MB, checks its checksum, and registers it with Claude Code, Codex, and the Gemini CLI, whichever are installed. No Go needed.

curl -fsSL https://raw.githubusercontent.com/SharedCode/joltrin/master/scripts/install.sh | sh

On Windows, in PowerShell:

irm https://raw.githubusercontent.com/SharedCode/joltrin/master/scripts/install.ps1 | iex

Or in Command Prompt (cmd.exe):

powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://raw.githubusercontent.com/SharedCode/joltrin/master/scripts/install.ps1 | iex"

Then ask it: "Use the joltrin tools to run drop_prod_db on workflow db-maintenance with trace id t1." The server refuses until take_backup and validate_backup have run in that trace, whatever the agent claims. Recorded runs with real agents.

Or drive it from LangGraph

A StateGraph with an agent node, a ToolNode over the server's MCP tools, and a loop between them. The agent tries drop_prod_db, reads the block, runs the steps it names, and retries. With ANTHROPIC_API_KEY set, a Claude model makes the calls. Without it, a small scripted policy stands in so the example runs offline and in CI. The policy is not a language model.

agent   -> execute_step drop_prod_db
barrier -> BLOCKED missing backup_validated, run first: ['validate_backup']
agent   -> execute_step validate_backup
barrier -> BLOCKED missing backup_taken, run first: ['take_backup']
agent   -> execute_step take_backup
barrier -> ALLOWED
agent   -> execute_step validate_backup
barrier -> ALLOWED
agent   -> execute_step drop_prod_db
barrier -> ALLOWED

That output is from a run of examples/langgraph_agent/agent.py with the scripted policy. Source and setup.

A block tells the agent what to do next.

A blocked call is a normal result, not an exception or an opaque error. It says what is missing and which recorded step would establish it, so the agent can replan instead of retrying the same call.

{
  "blocked_by": "precondition",
  "missing_state": "backup_validated",
  "established_by_steps": ["validate_backup"],
  "attempts": 1,
  "next": "run_established_by_steps"
}

blocked_by names the rule that stopped the step. missing_state is what has not been established in this run. established_by_steps lists the steps that would establish it.

Read it as a replan signal. attempts counts how often the same step was blocked for the same reason in this run, and next says whether to run those steps or stop and ask. Retrying the same call with different parameters will not change the answer.

With memory turned on, the server also counts, per rule, how many runs it blocked and how many of those went on to commit the step. That shows whether a rule is catching bad plans or is set too strict. It is a count, not an analytics product.

Agents hand off work. The barrier checks every call.

Jira, Grafana, AWS, and PagerDuty agents hand off work. Every call passes three checks first: the tool is on that agent's allowlist, any claim matches evidence a tool returned, and the steps it depends on have committed.

Replays the output of go run ./examples/agent_team. The tools are stubs and the checks are real. A result: line is what an agent gets back when a step is blocked on order: the rule, the missing state, and the steps that would establish it.

A block is feedback, not a dead end

The result names which rule tripped, the state that is missing and the steps that would establish it, so the agent can replan from the block itself.

In six runs where Claude Opus or Sonnet was allowed to run the other steps, five took the steps the block named and finished without repeating a blocked call. In the sixth, Claude Code's own safety check stopped a malformed call before it reached the server. Haiku refused the task. That is a small sample, so the prompts, models and transcripts are written up in full.

Read the agent test results

The same barrier, in front of kubectl delete.

sop-k8s-gate is a Kubernetes validating admission webhook. The API server refuses a delete of a protected PersistentVolumeClaim until the runbook's required steps, such as a validated backup, are recorded for the trace named on the object.

$ kubectl -n prod delete pvc orders-db-data
Error from server: admission webhook "gate.joltrin.dev" denied the request: step "drop_prod_db" requires state "backup_validated", which has not been established in this trace

A policy file maps an operation to a runbook step, and it takes the same runbook files as the MCP server. Steps are recorded through a separate endpoint that needs a bearer token. A --warn-only mode allows everything and reports what would have been blocked, so a policy can be tried before it enforces.

It was checked against a real API server in a local kind cluster, by hand and not in CI. Whoever holds the commit token can record a step, so the token belongs with the job that takes the backup and not with the workload being controlled. It runs as one replica and keeps recorded steps in memory.

Read how it works and what it leaves to you

Questions teams ask before trying it

What do I have to build?

You name the risky tool and the steps that must come first, then route the agent's call to that tool through Joltrin. It runs in your own environment as a Go library or as an MCP or A2A server. If the agent can reach the tool another way, Joltrin cannot stop that call.

Can't the agent just say the backup is done?

If the agent records its own steps, yes. Joltrin checks the recorded steps, not the real world. Steps that matter should be recorded by a tool you trust, such as the result of a backup check, and not by the agent's word.

How is this different from permissions or approval prompts?

Permissions decide who may call a tool. Approvals ask a person every time. Joltrin decides whether the earlier steps happened, so safe orders go through on their own and risky ones wait. Use them together.

What does Pro add that the free version does not?

The free version is the barrier, the MCP and A2A servers, and this demo, under the MIT license. Pro is for teams: one shared policy for every agent and a record of each allow and block. Some of that code is in the repository already, and bringing it into your setup is design-partner work today.

How do I buy, and what happens next?

Press Request Pro in the pricing section and fill in the short form. It then shows an Email Us to Start Pro button that opens your mail app with the details filled in; the request is sent when you send that email. We reply and set it up with you. There is no self-serve checkout yet, and you are not charged by clicking.

What is real, what is simulated, what it does not do.

Real

The checks. The same verify package serves the MCP and A2A servers and compiles to WebAssembly for the live demo, and the repository has tests for it. A recorded run with real agents covers one runbook over MCP.

Simulated

The tools. In the team demo, Jira, Grafana, AWS and PagerDuty are stubs, and the Arena is an illustration, not a cluster. The demos show the checks, not live systems.

Not covered

The barrier only answers, so whatever performs the real action must wait for it. It cannot see what the trace does not contain: a backup in another cloud account has to be represented by a step you trust, such as one that checks that account and then records the result. A committed step in the trace means the barrier allowed it, not that the action happened in the world. It does not judge whether an agent's own claim is true, and it does not replace sign-in, access control or isolation around the systems that act.

Implemented and tested: The Go verification engine (verify), the MCP server (tools/mcpserver), the A2A agent, the Kubernetes admission gate (tools/k8sgate), runbook files that are checked strictly, a single-tenant HTTP mode with a bearer token, and the check, try and demo commands. CI runs the tests with the race detector on the verification, MCP, A2A and runbook packages, and scans for vulnerabilities on every change.
Deployed and checked: A hosted instance of the Joltrin server, which handles the site's billing requests, runs on Azure Container Apps as one replica with a health check, Prometheus metrics with a latency histogram, and five Azure Monitor alerts. This is a different program from the barrier. The barrier is not hosted. How it is run, incident and alert-test log
Demonstrated: The barrier in your browser, compiled to WebAssembly, recorded runs with real agents over MCP, and the MCP server's HTTP mode and the Kubernetes admission gate running in a local Kubernetes cluster, checked by hand and not in CI. The tools in the demos are stubs, so they show the checks and not live systems.
Not implemented: A hosted barrier with per-client sign-in and stored state, and a dry-run mode. What hosting it would take

Open core, paid governance

The engine, vector search, agent memory, and the verification barrier are MIT licensed and stay free. Paid plans add team governance on top.

Open source

$0 MIT license

Embedded ACID B-Tree engine
Durable agent memory and vector search
Verification barrier, MCP and A2A servers
Community support on GitHub

Get it on GitHub

Pro

For teams

$49 per month, per team

For teams that let agents touch real systems. Write the rules once as policy, and keep a tamper-evident record of every allow and block, so you can answer "who let the agent do that?" in minutes.

Everything in open source
Policy-as-code: one set of rules for every agent
Tamper-evident audit lineage, with signed export
Team workspaces and quotas

Pro is design-partner access today. We reply by email and set it up with you. Self-serve checkout is not switched on yet. The policy, record and workspace code exists in the open repository; wiring it into the barrier for your team is the work we do together.

Enterprise

Everything in Pro
Okta and Microsoft Entra ID sign-in
Custom safety rules for your runbooks
Compliance audit exports

Start free

One developer, one agent, no account. Run the barrier on your own runbook and watch it block a bad step and say what to do next.

Try the barrier in your browser

Move to Pro when

More than one person edits runbooks and policies, and you want one place for them plus a record of who changed what. Policy compilation, the hash-chained audit log, and team workspaces are in the governance package in the public repo today.

What is built and what is not

Move to Enterprise when

Security or compliance asks for single sign-on, signed audit records, and a named owner for production approvals. Okta and Entra ID support and audit signing exist as building blocks; we scope the rollout with each team instead of promising a checklist.

Hosted Joltrin Cloud is planned and not available yet. .

Enterprise

Tell Us What You're Building

A few details about your agents and what you need, and we'll follow up personally.

Full Name *

Work Email *

Company Name *

Job Title / Role

Tier Interested In *

Primary Use Case *

More details (optional)

Company Size

Approx Number of AI Agents

Identity Provider (SSO)

Deployment Preference

Company Website (Optional)

What are you hoping to build with Joltrin?

No credit card needed. We reply by email.

Supporting capability

Durable state underneath.

When an agent's process restarts, a network connection drops, or a container gets evicted, whatever it was holding in memory is gone. Joltrin gives it durable state, transactional checkpoints, and a deterministic way to recover.

1. Durable State

Survives restarts

State is written to local copy-on-write B-trees or to clustered storage, not to a cache that disappears with the process.

2. Checkpoints

Atomic checkpoints

Record each step atomically. If an agent fails on step 8 of 10, it resumes from the last committed step, not from the start.

3. Recovery & Rollback

Rollback on failure

A transaction that fails before it commits is rolled back, so a half-finished change is not left behind. Commits use two-phase commit.

4. Vector Similarity

Vector search

Recall similar past episodes and facts by cosine distance. The index lives in the storage engine.

5. Persistent Working Context

No network hop

Runs inside your application binary, or in the browser on OPFS (Origin Private File System), so reads do not cross a network.

Loading the engine

Loading the WebAssembly build. The demos start when it is ready.

Core engine

Under the hood: the storage engine

Underneath the agent layer is a storage engine: copy-on-write B-trees, write-ahead logging, two-phase-commit ACID transactions, and Reed-Solomon erasure coding. It compiles to native Go and to WebAssembly, so the demos below run in your browser.

In-Memory B-Tree Financial Ledger

Real-time balances stored in local B-Tree nodes.

Execute ACID Scenario

Debit From

Credit To

Amount ($ USD)

Browser WAL & Execution Log

0 µs

// Ready to process client-side ACID transactions.

// Click 'Execute Atomic Transfer' to dispatch transaction to Go WASM kernel.

A Atomicity

C Consistency

I Isolation

D Durability

Check before it commits.

Your AI agent wants to delete production. Who's stopping it?

An AI can write your rules. It cannot sign for your backup system.

Start with your setup.

The agent and the verifier are separate.

A block tells the agent what to do next.

Agents hand off work. The barrier checks every call.

A block is feedback, not a dead end

The same barrier, in front of kubectl delete.

Questions teams ask before trying it

What is real, what is simulated, what it does not do.

Real

Simulated

Not covered

Open core, paid governance

Open source

Pro

Enterprise

Start free

Move to Pro when

Move to Enterprise when

Tell Us What You're Building

Durable state underneath.

Survives restarts

Atomic checkpoints

Rollback on failure

Vector search

No network hop

Loading the engine

Under the hood: the storage engine

In-Memory B-Tree Financial Ledger

Execute ACID Scenario

Browser WAL & Execution Log

Embedded Vector Similarity Search

Client-Side High-Throughput Benchmark

Embedded B-Tree Inspector

Kill the Agent Mid-Task. Watch It Resume.

Committed Reasoning Trace

Recalled From Memory

Agent Lifecycle Log