00 Runtime authority for AI agents
Your AI can spend money. Charter decides when it can.
Every action is checked against your written authority before it executes.
Actions are allowed automatically, blocked, or paused for human approval.
Every decision is written to an immutable ledger. Not even Charter can edit it.
For engineers shipping agents that move real money.
01 What it does
Three things, and that is the whole product.
Decide
Allow, block, or ask a person
The agent asks before it acts. Small refund: allowed. Large one: frozen until finance signs. Something its owner forbade: blocked, and the money is never touched.
Record
A ledger nobody can edit
Every verdict is hashed into a chain and signed. Change one old entry and every entry after it stops matching. The database role Charter runs as cannot delete or update rows.
Constrain
A written authority per agent
A named person grants each agent a spending limit, an expiry, the tools it may use and the operations it may never perform. A grant can only ever tighten the rules.
02 The rules
Every rule decided before the agent runs. So nothing is negotiated in the moment.
Behind this text is the whole rulebook, every clause the gate can reach for. Drag the pointer through it. Click to push it.
-
001 / Fail closed
Database unreachable, policy missing, tool not in the rulebook, agent not chartered, request timed out — the action does not proceed. There is no path through Charter that ends in "allow because we could not tell".
-
002 / One transaction
The verdict and its ledger entry commit together. The agent is told "allowed" only after Postgres has confirmed the write, so an action can never happen unrecorded.
-
003 / Insert only, enforced by the database
The role Charter connects as holds no UPDATE and no DELETE on the ledger tables. This is not a convention in the application code — revoke it and the application breaks.
-
004 / Rules are versioned, never edited
Activating a change writes a new version. Every entry records the version it was judged under, so a decision from March is still readable against March's rules.
-
005 / A spending window, not a counter
Budgets are evaluated over a rolling window from the ledger itself. Nothing to reset, nothing to drift out of sync with the record.
-
006 / A person on the hook
Anything above the line freezes and goes to a named human on Telegram with the arguments they are approving. Their identity and the moment they decided are recorded.
-
007 / Authority beats policy
An agent's charter is checked before the rulebook is even consulted. Expiry, forbidden operations and the granted budget can only tighten what policy would have allowed.
-
008 / Signed checkpoints
The chain is anchored at intervals by an Ed25519 signature over a Merkle root, so a range of history cannot be quietly rewritten and re-hashed.
-
009 / A verifier that shares no code
Canonicalisation and hashing are implemented twice, independently. The auditor's tool cannot inherit a bug from the thing it is auditing.
03 The decision
Watch it decide, live.
Nothing here is invented. Every row is a real verdict from a real gate — with a rule id and a ledger entry you can go and check. Run Charter yourself and this decides live; on this hosted page it replays a recorded run, and says so.
Verdict
Waiting
The agent has not asked for anything yet.
04 For engineers
Wrap the tool you already have.
No new agent framework, no proxy in front of your model. You wrap the function that moves money and Charter becomes the thing that stands in front of it.
import { CharterClient } from "@charter/sdk"; const charter = new CharterClient({ baseUrl: "http://localhost:8090", apiKey: process.env.CHARTER_AGENT_KEY, agentId: "refunds-agent", }); // The tool your agent already calls — now it has to ask first. export const refund = charter.guard("refund", stripeRefund, { principal: () => session.user.email, reasoning: () => model.lastThought, });
Allow
stripeRefund runs. The verdict and the arguments hash are already in the ledger before it does.
Deny
It throws. PolicyDeniedError — the wrapped function is never entered.
Escalate
It waits. A person approves in Telegram, then the call proceeds — with their name attached to it.
05 The artefacts
What Charter actually hands you.
Four things exist after an agent acts. These are not illustrations — every shape below is sampled from real hashes, a real Merkle root and a real signature. Run Charter yourself and they redraw from your own ledger on every reload.
06 Compliance
Built for the audit, not just the demo.
Charter's export maps every decision to named controls under SOC 2, the EU AI Act and the RBI IT Governance Direction — with the clause, the expectation, and the field in the pack that proves it. Control-level mapping, not legal advice.
SOC 2
- TSC CC7.2 / CC7.3 — monitoring for anomalies, evaluation of security events
- TSC CC8.1 — change management for authorisation logic
EU AI Act
- Reg. (EU) 2024/1689, Art. 12 — record-keeping / automatic logging
- Art. 14 — human oversight, intervention and interruption
RBI
- IT Governance Direction, 2023 — maker-checker / dual authorisation
- Audit trail over straight-through processing
- Delegation of financial authority and limit discipline
Article 12 and 14 bind systems in scope as high-risk under Annex III — Charter produces the evidence either way, but whether your agent is in scope is your counsel's call, not ours.
And the six questions underneath all of it
Not a dashboard screenshot. Six specific questions an auditor puts to you about an automated system, and the artefact in Charter that answers each one.
01
Who authorised this agent to act?
A named human principal owns every agent, with the date they granted it and the date it lapses.
Proved by: the authority document
02
What was it allowed to do?
The version of the rules in force at that instant, not the version live today.
Proved by: policy version on every entry
03
Who approved this specific payment?
The approver's identity, the moment they decided, and the request they saw when deciding.
Proved by: the hold record
04
Has the record been altered?
Recompute the chain yourself. One edited byte anywhere breaks every hash that follows it.
Proved by: independent verifier
05
When did you know?
Signed checkpoints anchor the chain at points in time, so a range cannot be back-dated.
Proved by: Ed25519 checkpoints
06
Show me last quarter.
One export: every decision in the window, the rules applied, the approvals, the maths.
Proved by: the attestation report
07 Where it stands
Honest about what is built and what is not.
Built
The gate, the ledger and the verifier. Policy versioning, spending windows, human approvals over Telegram, Merkle checkpoints, and a verifier that shares no code with the thing it audits.
Built
The registry and authority layer. Agents are chartered by a named person, with budgets, expiry and forbidden operations enforced before policy is even consulted.
Built
Credential custody. Charter holds the payment credential, so the agent is never given one. It asks for a tool by name; Charter checks the action and makes the call itself. An agent that skips Charter no longer gets away with it — it has nothing to pay with.
Not built
Multi-tenant hosting. This runs on one machine against one Postgres. There is no hosted product to sign up for.
↘ Early access
Get Charter when it is ready for your agents.
It holds a real credential today, and it is still a prototype rather than a hosted product. Leave an email and you will hear when you can point it at your own agents.
You are on the list.
We will write to when Charter can hold a real credential. Nothing else, and no one else gets it.
Just your email. It reaches us via Formspree, is used only to tell you about Charter, and goes to nobody else. No tracking on this page.