Policy · v1.0 · October 12, 2026

The Agent Ledger Policy, v1.0

Seven rules for any AI agent that writes to a business's books. Published by Evenbead on 2026-10-12. Every rule can be checked by a machine, and the Evenbead API enforces all seven today; each rule says exactly how, with the field and error names an agent will see. Copy it into system prompts, agent configs and firm onboarding checklists.

In one line: act under a scoped key, make writes idempotent, dry-run before you post, respect your threshold, expect the five proposal triggers, never approve yourself, and carry your identity on every write.

1. Scoped identity

Every agent acts under its own key with named scopes. No shared keys, no ambient credentials, no "office assistant" acting for everyone.

• Why: a leaked key should cost one capability, not the whole books.
• How Evenbead enforces it: an agent is a registered principal with scopes read, propose, approve and admin (plus export, which only the owner or CPA can grant). A key can never carry a scope its agent lacks. Agent keys expire after 30 days by default (at most 90) and rotate with an overlap window (24 hours by default, at most 7 days). GET /v1/me tells the agent who it is, its scopes, its company and when its key expires. Revoking an agent stops all of its keys on the next request.

2. Idempotent writes

Every write that adds something carries an idempotency key. Retries are safe; duplicates are impossible.

• Why: agents retry and networks drop. An agent that posts the same invoice twice has already lost the owner's trust.
• How Evenbead enforces it: the Idempotency-Key header (the idempotency_key argument over MCP, 8 to 200 characters) is required on every write; without it the write is refused with idempotency_key_required. The same key with the same request replays the original response (Idempotency-Replayed: true); the same key with a different request is refused with 409 idempotency_conflict. Writes that only set a value (a setting, a plan) are marked as such in the reference and need no key, because repeating them changes nothing.

3. Dry-run before you post

Before a write that posts, the agent asks what would happen and reads the answer.

• Why: the cheapest correctness check in accounting is looking before leaping.
• How Evenbead enforces it: every write that goes through the posting policy (journal entries, invoices, credit memos, bills, payments, expenses, checks, transfers, refunds, bank-line categorization and suggestions, recurring entries) accepts "dry_run": true. For an entry or a document the answer has outcome: "dry_run" and would: post, queue_for_approval or be_refused, with the policy reasons, the period, the affected balances and any validation errors; batch writes (accepting many bank lines, running recurring entries) answer the same way line by line. Nothing is written and no idempotency key is needed.

4. Respect the posting threshold

Every agent carries a posting threshold in integer cents. Entries at or under it post; above it they become proposals for a person.

• Why: a $40 supplies entry and a $40,000 journal entry are not the same risk. A threshold turns "trust the agent" into "trust the agent up to a line".
• How Evenbead enforces it: posting_threshold_cents is set when the agent is registered, and the policy compares every governed write's total (the sum of its debits) with it. Amounts are whole cents; floats are refused.

5. The five proposal triggers

Even under the threshold, a write goes to a person when any of these is true:

• Why: the cases where a good agent still needs a person are not random. They are the risk surface, made explicit.
• How Evenbead enforces it: the policy checks all five on every governed write and returns the verdict with the reasons that applied (in the dry run, and on the proposal). Evenbead adds stricter holds of its own: an expense recorded from a receipt (receipt_review), an accepted suggestion that is not a rule match (suggestion_review), a bank line whose category contradicts its sign (bank_line_review), and, for AI apps connected with OAuth, the connection's level, daily cap and account scope. A hard-locked period refuses every write, in the database.

6. Never approve yourself

A key with the approve scope may approve or reject proposals, but never its own. An agent can route an approval to a person; it cannot be the person.

• Why: self-approval is the audit finding that ends careers. The rule fails closed: if the only approver is the agent that proposed, the proposal waits.
• How Evenbead enforces it: the approve scope is "approving or rejecting proposals (never your own)". The API refuses with self_approval_forbidden, and the database refuses an agent's approval of its own proposal as well. Rejecting needs a reason, which stays on the record.

7. Carry your identity, and keep the chain tamper-evident

Every write says which model made it and in which run. Every change lands in a hash-chained audit log.

• Why: "the AI did it" is not an answer. "Model X, run Y, proposal 412, approved by a named person at 14:32" is.
• How Evenbead enforces it: agent writes without the X-Agent-Model header are refused with model_required; X-Agent-Run-Id names the run (over MCP: _meta keys dev.evenbead/model and dev.evenbead/run_id; an AI app connected with OAuth is recorded under its registered name). Every change is an event in the company's audit log, each event's SHA-256 hash covering the previous one, so changing any past event breaks every hash after it. The chain can be checked offline: the books export carries it with a stand-alone verifier, and the monthly agent audit report states the chain's head for the month.

What this policy is not

• It is v1.0 of one company's contract, written to be copied. It is not an industry standard. Comments: hello@evenbead.com.
• It governs writes. Reading the books is never metered or billed by Evenbead (rate limits still apply), and an agent with the read scope may read all of them.
• It does not care which agent. Claude, ChatGPT, Gemini or an in-house model: same seven rules, same enforcement.

Adopt it

Paste this into an agent's system prompt or config:

When writing to a ledger, follow the Agent Ledger Policy (v1.0): act under your own scoped key
(read / propose / approve / admin), never a shared one. Send an Idempotency-Key with every write.
Dry-run before you post and read the verdict. Respect your posting threshold in cents. Expect five
proposal triggers: over_threshold, sensitive_account, period_soft_locked, low_confidence,
new_counterparty. Never approve a proposal you made. Send your model name and run id with every write.

Cite it in one line wherever policies are listed:

Agent writes governed by the Agent Ledger Policy (v1.0), published by Evenbead: seven rules for any agent that writes to a ledger. https://evenbead.com/agent-policy

Where to read more

• Quickstart: keys, scopes, idempotency, dry runs and proposals with curl.
• MCP setup: the same rules over MCP.
• Export your books: the audit chain and its offline verifier.
• Plain text of this page: https://evenbead.com/agent-policy.md