How it works

Sign the policy. Permit every action. Verify it yourself.

This is the trust loop. The risk owner signs the policy, every consequential action gets a permit bound to that signature and to one exact payload, and the owner checks every permit on their own machine. Nobody has to trust the model, the vendor or us.

Book the switch-on Find your industry

Sign

The risk owner signs a policy a person can read: the limits, the totals per customer and per day, the bands and the named approver above the line. The numbers are a signed edition, so a change is a new version with a new signature, never a quiet edit.

Permit

Before a consequential action the agent asks for a permit for the exact payload, over MCP or one REST call. Stategram checks the running totals and answers one of three ways: a permit, a referral to the named person, or a refusal with the rule that fired.

Verify

Your gateway checks the permit before it executes: the signature, the payload, the lifetime and that it was never used before. You can run the same check yourself, offline, in about 10 ms, with nothing from us.

Book the switch-on See it for your industry

Measured on the hosted release

Check every write in under 100 ms.

95 ms

per permit at p99, inside the region

115 ms

per permit from outside AWS, median

10 ms

to verify a permit on your own machine

actions when Stategram cannot be reached

Measured on 9 and 10 October 2026 on the hosted release in Frankfurt.

What an offline check proves

Verify six things without us.

It traces back to your signature. Every permit carries a stack of signatures that leads back to the one you put on the policy.
It ran your policy. The hardware proves that the code which answered is the code built from the policy you signed, not a look-alike.
Under your numbers. The limits in force are the edition your signers signed.
It said yes. A permit, not a referral dressed up as one.
For exactly this action. The amount, the customer and the action are bound into the permit, so nothing changes on the way.
Fresh, and used once. Inside its lifetime, and never seen before by your gateway.

Check a sample permit See what you still trust

The facts behind a permit

Keep the facts in your own system.

A permit binds to the facts the rule read at the moment of decision: the balance, the counters and the flags. Those facts come from your own system, never from the vendor whose agent is asking.

Nothing re-runs the policy at execution. Your gateway checks the permit and executes, and it holds the newest facts, so a supplier put on hold after the permit was issued is refused there.

Next come facts your own system signs, and the signed file you already hand a vendor, so a policy can read them without an integration.

What you still have to trust

Know what you still trust.

Two things: your own signature, and the hardware your policy runs on. Nothing else, and you can check both yourself.

You trust

Your own signature. You sign the policy yourself: the limits, the rules and who approves above the line. Every permit traces back to that signature.
The hardware. Your policy runs on hardware that proves which code answered. That proof comes from the hardware, not from us.

Stategram cannot

Change your rules, your limits or your approvers
Sign for you, or approve in your approver's place
Forge a permit, or undo one without it showing
Reset a customer's running total

Ask the hard questions Where your data is stored

Live since 9 October 2026

Run it today in Frankfurt.

Running

Permits in under 100 ms at p99, inside the Frankfurt region
A stack of signatures in every permit, tracing back to the policy you signed
Offline checks of any permit on your own machine, in about 10 ms
One call before the action, over MCP or REST
No action when Stategram cannot be reached
Test sessions a signer can run from the browser before signing

Signing from the dashboard with each person's own key
Refusals you can check offline, like permits
Two companies signing one policy

Where your data is stored, and who processes it: the privacy policy.

Stategram closes the trust loop

Every product that keeps an agent in line decides one thing. Here are the eight options, what each decides, and the names buyers put next to ours in 2026. Then the table: the parts of the loop down the side, the options across the top.

Alternatives

Stategram

The trust loop. The risk owner signs a human-readable policy; before each action the agent asks for a single-use permit, checked against the policy and the running totals; a named person decides above the line; every permit traces back to the owner's signature and verifies offline.

Prompt and model guardrail tools

What the model is asked to do, and what it may say.

OpenAI Agents guardrails, the Claude Agent SDK, Lakera

Rules engines and in-house code

One call, judged from the facts the caller supplies, and the rule that matched.

Aletyx (the Drools and DMN team), Camunda, OPA, Cedar, Taktile, a check in your own code

Approval queue software

A person clicks before the action runs.

n8n human-in-the-loop, UiPath Action Center, ServiceNow supervised mode, Velatir

Agent platforms and gateways

Which tools and data an agent may reach, with an approval gate on some tool calls.

Microsoft Agent 365 and Copilot Studio, Salesforce Agentforce, MintMCP, Composio

Identity and delegation providers

Who the agent is, and on whose authority it was delegated a scope.

Okta, Microsoft Entra Agent ID, DigiCert, KYXStart, VAID

Agent account and payment providers

What an agent spends from an account it holds, with a cap on that account.

Natural, Mastercard Agent Pay, Visa Intelligent Commerce, Google's AP2, Lit

Logging and observability tools, AI insurers

What happened, afterwards, and who pays after a loss.

Langfuse, LangSmith, Arize, NSLogic, Armilla, AIUC, Munich Re's aiSure

Yes means the group does it as published. Partly means some products do part of it, or do it for one agent or one system only. No means nothing in the group claims it. Our reading of public materials, October 2026; corrections to [email protected].

	Stategram	Prompt and model guardrail tools	Rules engines and in-house code	Approval queue software	Agent platforms and gateways	Identity and delegation providers	Agent account and payment providers	Logging and observability tools, AI insurers
Limits signed by the risk owner, every change a new version	Yes	No	Partly	No	Partly	No	Partly	No
One running total across every agent and person	Yes	No	Partly	No	Partly	No	Partly	No
Checked before execution, a single-use permit per action	Yes	No	Partly	Yes	Yes	Partly	Yes	No
A named approver above the line	Yes	No	Partly	Yes	Partly	No	No	No
Hardware-rooted: the hardware proves which code ran the policy	Yes	No	No	No	No	Partly	No	No
A record that verifies offline and the operator did not write	Yes	No	No	Partly	Partly	No	Partly	Partly
Covers your own books: refunds, settlements, claims, contract terms	Yes	Partly	Yes	Yes	Partly	No	No	No
The same rule for a person in the back office	Yes	No	Yes	Yes	No	No	No	No

Hardware-rooted means the permit is signed inside hardware that proves which code ran your policy, so a receipt rests on your own signature and the hardware, not on anyone's word, ours included. Live in Frankfurt since 9 October 2026; an external security audit is planned, not done. Underneath these products sit five ways a company can enforce a limit on an agent, from a prompt to a separate control layer, ranked against the six demands the rules already make: read the five ways.

Switch on your first agent.

Two weeks, a fixed fee, your limits and a named approver, and the method to do the next workflow yourself.

Leave your email

We will email you to find a time for a 25-minute walkthrough with the founder. No slides, no sales script.

Thanks. We will email you to find a time.

Book a call

Pick a time in the founder's calendar, or tell us about your agent first.

Book the switch-on Talk to founder