You give an AI agent write access to your books safely by putting the rules in the ledger, not in the prompt. LedgerMCP enforces four accounting invariants inside Postgres, keeps an append-only audit log with one-click reverse, offers read-only keys for report-only agents, and lets you lock closed periods. The agent can do the repetitive work while the database refuses to let it corrupt anything.
Why is prompt-level trust not enough?
The common way people try to make an AI safe with money is to write careful instructions: "always balance the entry," "never delete anything." That is trust in the model, and it fails the first time the model misunderstands, hits an edge case, or a retry fires twice. Instructions are advisory. The safe design puts the guarantees one level below the agent, in the write path itself, so that no wording in any prompt can override them. In LedgerMCP the agent proposes changes, but the database decides what is allowed to land. That separation is the whole safety story, and everything below is a specific example of it.
What are the four invariants enforced in the database?
Four rules are checked in Postgres at commit time, not in application code and not in the prompt. They hold for every write, whether it comes from you, from Claude, or from any other MCP client.
| Invariant | What it guarantees |
|---|---|
| Balanced | Debits must equal credits with at least two lines, or the write is rejected. The books cannot drift out of balance. |
| Immutable | Postings cannot be edited or deleted. A correction is a linked reversal, so history is never rewritten. |
| Idempotent | An idempotency key makes a retry safe: replaying it returns the original entry and posts nothing. No double charges from a dropped connection. |
| Computed | Account balances are derived from the postings every time, never stored in a column an agent could set. The report cannot disagree with the ledger. |
Because these are constraints and triggers in the database, an agent that tries to post a lopsided entry gets an error, not a corrupt book. This is the same foundation described in what an MCP server is, applied to money.
How does the append-only audit log protect me?
Every write through the MCP surface lands in an append-only audit log, tagged with the key that made it. Nothing is silent. If an agent categorizes 300 transactions overnight, you have 300 log entries, each with a one-click reverse in Settings. Because postings are immutable, a reverse does not erase the original: it posts a linked counter-entry that cancels it and leaves both visible. You can always answer "what did the agent change, and when," and you can undo any of it without a database export or a support ticket. Contrast that with a tool that edits numbers in place, where a mistake overwrites the truth and there is nothing left to inspect.
How do read-only keys and lock dates limit access?
Not every agent needs to write. LedgerMCP keys are account-level bearer tokens you create in Settings, and you can make one read-only. A read-only key lets an assistant pull balances and run reports, a monthly review, a cash-flow check, a P&L for your accountant, without any ability to post. Give the analyst agent a read-only key and the bookkeeper agent a full one.
Period lock dates add a second boundary. Once you set a lock date, closed months are frozen: no agent, and no human, can post or back-date into a period you have already reviewed and settled. New work flows into the open period only. Together, read-only keys and lock dates let you decide exactly how much surface any given agent touches. You can read more about how this fits the overall model on the security page.
Why are deletes human-only?
The safest destructive action is the one that does not exist as a tool. LedgerMCP does not ship a delete posting or an edit posting tool for agents, because there is no edit or delete in the ledger at all: UPDATE and DELETE on posted entries are revoked in the database, even from the service role. An agent cannot call a capability that was never built. Duplicate feed rows are soft-excluded rather than removed, and accounts are archived, never deleted. When something genuinely needs to disappear, that is a deliberate human action outside the agent's toolset. This is the difference between an agent that helps keep your books and one that can quietly rewrite them.
Why is this safer than handing an AI a spreadsheet?
A spreadsheet is the worst place to give an agent write access, because it has no rules. Every cell is editable, formulas break the moment a value is pasted over them, a deleted row leaves no trace, and there is no concept of a balanced entry to enforce. The agent has total freedom and the file has zero guardrails, so a single wrong move can silently corrupt months of work.
A real double-entry ledger inverts that. The agent has narrow, well-defined tools, and the substrate underneath rejects anything that would break the books. An unbalanced entry bounces. A delete is impossible. A retry is harmless. Every change is logged and reversible. If you are weighing the broader question of trust, our post on whether AI bookkeeping is safe covers it in depth, and the split between the reasoning agent and the durable ledger is the subject of our companion piece on the difference between an AI agent and an MCP server. You can also see the guardrails in action on a real task in bank reconciliation, where every tie-out is persisted as proof.
The whole design is available to inspect: LedgerMCP is a real accounting MCP server, so the tools an agent can call, and the ones it cannot, are a fixed, published contract rather than a promise.
Quick answers
Is it safe to let an AI write to my accounting system?
Yes, when the write path enforces its own rules. LedgerMCP checks four invariants in Postgres, not in the prompt: every entry must balance, postings are immutable, retries are idempotent, and balances are computed from postings. An agent physically cannot leave the books unbalanced or silently overwrite history.
Can an AI agent delete my transactions?
No. UPDATE and DELETE on posted entries are revoked in the database, even from the service role, so no agent tool can remove or edit a posting. Corrections happen as linked reversals that leave the original in place, and every write lands in an append-only audit log with a one-click reverse.
How do I give an agent read-only access?
Create a read-only bearer key in Settings. Read-only keys let an agent pull balances and run reports but cannot post, so a report-only assistant never touches the ledger. You can also set a period lock date that freezes closed months against any back-dated write.
How is this safer than handing an AI a spreadsheet?
A spreadsheet has no rules. An agent can overwrite any cell, break a formula, or delete a row and leave no trace. A real ledger rejects an unbalanced write, refuses to delete history, and records every change in an audit log, so mistakes are visible and reversible instead of silent.
