For agent builders
Give your AI agent receipts for what it does.
When an AI agent acts today, the record is a log on the machine it ran on, editable by whoever controls that machine. Elara gives each act you record a receipt signed with the agent's own key, naming the permission it acted under. Anyone can check the signature offline, without trusting you or us.
01 What you get
A mandate. A signed permission slip from you to your agent, valid for a window of time. You can revoke it with one command.
A receipt for each act. Your agent calls one tool, and the act is recorded and signed with the agent's post-quantum key (ML-DSA-65, FIPS 204). The MCP server hashes the real arguments itself (SHA3-256 of canonical JSON) and never accepts a hash computed elsewhere, so the receipt covers what the agent actually sent.
A status check for any act. Was it inside a live mandate? An act
after a revocation comes back flagged post_revocation, an act outside the
window expired or not_yet_valid, and an act by a different key
claiming your mandate agent_mismatch. Revoking stops the future and never
rewrites the past: acts made before it stay authorized.
An offline check. Anyone can check a receipt's signature with
elara-verify: no node, no network, no account.
A log is your word. A receipt is something others can check.
02 Set it up: three steps, about twenty minutes
Your own chain and a mandate
Follow the issuer quickstart: two identities (yours and the agent's), a local node, a mandate, a first act, a revocation, an offline check. About fifteen minutes, most of it the first build (9 min 19 s on a 4-core desktop in our run). Nothing in it talks to our network: the chain is yours.
Install the MCP server
cargo install elara-mcp builds it from source, 82 s in our test. It
speaks MCP over stdio, so any MCP client can start it.
Point your agent at it
Add it to your MCP client's config, with your node, your network, the agent's identity file and the mandate id from step 1, as below.
{
"mcpServers": {
"elara-mandate": {
"command": "elara-mcp",
"env": {
"ELARA_MCP_NODE_URL": "http://127.0.0.1:19474",
"ELARA_NETWORK_ID": "my-agent-chain",
"ELARA_MCP_IDENTITY": "/path/to/agent.json",
"ELARA_MCP_MANDATE_ID": "<mandate id from mandate-issue>",
"ELARA_MCP_CLI": "/path/to/elara-mesh/target/release/elara-cli"
}
}
}
}Your agent now has four tools: mandate_act_emit records a
signed act, mandate_act_status asks whether an act was authorized,
mandate_my_mandate shows the agent its own mandate, and
mandate_bundle_verify checks a mandate bundle without touching the network.
Tested on 2026-09-25 from a fresh clone, as a newcomer would, through two real MCP clients: AWS Strands (3/3) and deepseek-harness (4/4). Each run recorded a real act, and both acts then verified offline. Worked examples: examples/strands, examples/dsh. Not yet run: a full model-driven agent on top. The tests drive each client's own MCP layer, below the model.
03 Check a receipt
cargo install elara-verify --features cli
curl -s http://127.0.0.1:19474/record/<record-id>/wire -o act.wire
elara-verify --wire act.wireReal output for the act our test recorded through Strands (excerpt):
VERDICT: VERIFIED
this exact content was signed by 6cda335498524165…,
who claims it existed at 2026-09-25 18:12:08 (UTC, the creator's own claim).
Trustless time bracketing requires an --anchor proof — not given here.Read the last two lines. The signature is proven; the time is the agent's own claim. Pinning the time down needs an epoch-anchor proof (a Bitcoin existed-by and a drand not-before bound), which the quickstart does not set up; see ELARA-VERIFY.md. Fetching the record needs a node that holds it; the check itself needs nothing.
04 Limits, stated plainly
Only recorded acts get receipts. A receipt exists because the agent, or your code around it, called the tool. An act nobody records has none, so record at the point where your code carries the act out rather than leaving it to the model's judgment.
It proves what was sent, not what happened. A receipt shows which key signed which arguments (by their hash), under which mandate. It does not show that the tool call succeeded, or that the arguments were true.
A narrowed scope is recorded, not enforced. You can write a narrower
scope into a mandate, such as a list of allowed operations. It is signed and recorded,
but not yet enforced: such a mandate reports scope_deferred: true. Don't
treat it as policy.
On a chain you run alone, it is only as trustworthy as you. You hold every key and run the only node, so a receipt proves the agent's key signed, but the chain's history rests on you. Independent nodes are the design; today stake admission is operator-controlled, and several consensus features that engage only with multiple staked nodes are shipped but not yet hardened (known limitations, section 7).
Keys are plaintext by default. The key files the quickstart writes
are owner-only (mode 0600) but unencrypted, and anyone who can read the agent's file can
act as your agent. A node encrypts its own identity file when you set
ELARA_IDENTITY_PASSPHRASE (section 17 of the same page).
05 We run it on ourselves
Elara's maintainer is an AI agent, and it publishes its receipts: a public proof log where every row carries the commands to check it yourself, including the status of the mandate behind it.
Give your agent its first receipt.
Your chain, your keys, open source. No account, no permission needed.
git clone https://github.com/navigatorbuilds/elara-mesh.gitStart the quickstart