When Your Ledger Becomes an Agent's API

You built a double-entry ledger. Locked down authentication, set up role-based access control, added the audit trail, wired up the webhooks. Then an agent called the API.

Not a human clicking through your dashboard. A piece of software that reads balances, proposes multi-leg journal entries, and expects your ledger to say yes or no in real time. Ramp built its coding agents on Fragment, where the agent proposes whatever it wants and the ledger decides what's allowed.

That second sentence is the engineering problem. Your ledger already knows how to answer "who is calling?" What it probably can't answer is "what is this caller allowed to do, who said so, and how do I enforce that at write time?"

What changes when the caller is an agent

Your ledger authenticates the agent and checks its role the same way it would for a human. API key, OAuth token, mutual TLS, whatever you already use.

But authentication only answers who is calling. When a human calls your ledger, someone approved their access level during onboarding. The human has context: they know their budget, they've checked the balance, they understand what they're doing. The constraints live partly in the person's head and partly in the UI that gates their actions.

An agent has none of that implicit context. It will call your API as fast as your rate limit allows, propose whatever entries its model thinks are correct, and never second-guess a balance. The constraints that were implicit in human workflows need to become explicit in the ledger's enforcement surface.

Handing someone your debit card creates the same problem. When you swipe it yourself, you know your balance and your budget. When you hand it to someone else to run errands, you want the bank to enforce a daily spending limit, a per-transaction cap, and maybe a list of approved stores.

The card itself needs constraints because the person holding it doesn't have your context. An agent with ledger access is that situation at API speed, potentially a thousand swipes a minute.

The constraint surface

Balance conditions. The ledger checks that the source account can afford the debit before the entry posts, then verifies the balance hasn't dropped below a floor afterward. Fragment's Entry Conditions split this into a precondition that checks the balance before writing and a postcondition that enforces a minimum after.

Both evaluate atomically with the write. If the condition fails, nothing posts and the ledger never reaches a partial or inconsistent state.

Delegation scope. The agent has a budget, and it's more specific than "this API key can access these accounts." It looks like this agent can spend up to $500 per day from this specific account, on transactions tagged as a particular category. The delegation record needs to be a first-class object the ledger can check on every write, not an application-layer honor system.

Entry attribution. Every journal entry needs metadata distinguishing who initiated it. Was this a human posting through the dashboard, or an agent proposing entries through an MCP server? When an auditor asks, your ledger needs to answer with the agent ID, the delegation grant that authorized the entry, the timestamp of the authorization check, and a reference to the workflow that generated it.

I wrote about the delegation gap at the protocol layer in October. The same gap exists at the ledger layer, and the stakes are similar. Without a machine-readable delegation record, you can prove the entry posted correctly but you can't prove it was authorized.

Why MCP over REST

Your ledger already has a REST API. So why does the agent need something else?

You define REST endpoints, publish the docs, and the client constructs payloads to match. The client needs to know the schema in advance and get the request body right on the first try.

Through MCP, the agent discovers what operations are available, reads their schemas, and proposes actions. For a ledger, this means the agent can inspect the chart of accounts, understand what entry types exist, and propose a multi-leg journal entry that the ledger validates before posting.

A payment flow that involves debiting a customer, crediting a merchant, splitting a platform fee, and posting a reserve entry is four ledger lines that must post atomically. With REST, the agent constructs the full payload and POSTs it. If any line violates a condition, the whole thing fails and the error message may not pinpoint which leg broke and why.

MCP turns this into a negotiation. The agent proposes, the ledger server validates each line against conditions, and returns structured feedback before anything posts. The agent can adjust and re-propose without touching real state.

Fragment shipped its MCP server in July 2026. The agent connects, reads the schema, and writes financial code, ledger designs, entry types, and conditions, with the ledger validating at every step.

Because the MCP server exposes the constraint surface alongside the operations, the agent knows the rules before proposing an entry that would break them.

Where should authorization live?

The delegation gap piece laid out the problem at the protocol layer. x402, ACK, and MPP all verify who paid but none verify who said the agent could spend. That gap lives at three different layers, and the engineering question is which one should own enforcement.

Protocol layer. Stripe's Machine Payments Protocol, launched in March 2026 on Tempo, standardizes how agents discover payment endpoints, negotiate terms, and settle. MPP is rail-agnostic, settling stablecoins through Tempo, cards through Visa, and Lightning through Lightspark. But MPP handles the payment message format and settlement. Whether the agent had permission to initiate that specific payment lives somewhere else.

Ledger layer. Fragment's entry conditions operate here. The ledger itself checks, at write time, whether the proposed entry satisfies the constraints defined in the schema. If the postcondition says the account balance must remain above zero, an agent can't overdraw it regardless of what the application layer told the agent to do.

Application layer. Your own middleware, sitting between the agent and the ledger API. You check the delegation grant, enforce the spending limit, validate the merchant whitelist, and pass the call through if everything checks out. This is the most flexible approach and the most fragile. It's another piece of code that can have bugs, and the ledger has no way to know whether the application layer enforced the constraints or skipped them.

The strongest production architectures I've seen combine layers. Ledger-layer conditions handle the structural guarantees, balance floors and double-entry integrity. The application layer adds business-specific delegation like spending caps and category restrictions on top, while the protocol layer covers settlement and payment discovery. No single layer does the whole job.

Simulation as a safety gate

Fragment's Scenarios let you simulate a payment flow against a schema without posting real entries. When agents are proposing the flows, simulation becomes a critical safety layer.

The agent proposes a multi-leg transaction. Before it hits the real ledger, the proposal runs through a scenario that applies the same entry conditions, balance checks, and schema validation as production. The real entry posts only when the scenario passes. A failed scenario returns structured feedback about what broke, and the agent can adjust before trying again.

This is the financial equivalent of a dry run, except the dry-run environment enforces the same constraints as production. An agent can iterate on a payment flow, adjusting amounts, changing account paths, adding fee splits, without touching real money. The iteration happens in seconds, not in deployment cycles.

The audit trail regulators will ask about

When a regulator reviews your ledger, they'll want to know which entries were initiated by agents. Most ledger schemas today don't distinguish between a human posting through a dashboard and an agent posting through an API.

The minimum viable audit trail for agent-initiated entries records the agent identifier, the delegation grant that authorized the action, the timestamp of the authorization check, and a reference to the workflow that generated the entry. Without these, you can prove the entry posted correctly but you can't reconstruct who authorized it.

Fragment tags every entry with metadata, and when the entry comes through the MCP server, that metadata can include the agent context, covering which model generated the entry, which session it belonged to, and which delegation scope applied. The audit trail becomes a first-class part of the ledger record rather than something reconstructed from application logs after the fact.

Regulators already expect entries to balance. They'll want to know who authorized this agent to post this entry, what constraints governed the action, and where the record lives.

Your ledger has always answered the accounting questions, and the agent layer now forces it to answer the authorization questions in the same system of record.