Four primitives, one decision.

Every time one of your agents tries to spend money, sign a contract, or call an external system, Ledgerline answers a single question in a few hundred milliseconds: is this action authorized, by whom, and within what limits? The answer is built from four things.

1. Identity

An identity in Ledgerline is anything that can take an action — a human operator, a swarm controller, an individual agent. Every non-root identity has a parent, and every chain ends at a human principal. There is no such thing as an orphan agent.

This isn't novel — it's how filesystems and AWS IAM have worked for decades. The novel part is that we apply it to agents before the action they're about to take, not as a label after the fact.

What you get from this: when an agent does something, you can walk back up the chain and answer "who delegated this, recursively, to a real person." When that person's account is revoked, every descendant identity loses its authority instantly — without a deploy.

2. Policy

Policies say what an identity is allowed to do. Today they are JSON; the engine is moving to Cedar — the same policy language AWS uses for IAM and Verified Permissions. We chose Cedar because it has formal semantics, a real grammar, and tooling that already exists.

A policy attaches to an identity (or to its tenant) and matches against the proposed action. Common shapes:

• Constrain the set of allowed actions (e.g. only card.authorize and email.send)
• Cap individual transactions by amount or merchant category
• Restrict the time of day or geography
• Require a co-signer above a threshold

Policies are versioned and deployed independently of agent code. Changing a limit doesn't require redeploying anything the agent talks to.

3. Budget

Policies say what. Budgets say how much, over what window. Budgets attach to identities and have a period (hourly, daily, monthly), a dimension (amount, transaction count, tokens, anything you can count), and a limit. Each authorized action reserves from the budget; settled transactions consume.

The reservation step is where most "agent runs up the bill" stories actually originate. Without reservation, two simultaneous purchases each individually under the limit can together exceed it. Ledgerline reserves at decision time and reconciles on settlement.

4. Audit

Every authorization decision — allow or deny — writes a row to an append-only log. Each row contains the identity chain, the policies that fired, the budget state before and after, and a hash that includes the previous row's hash. Tampering with an old row breaks every subsequent hash.

The log is queryable, exportable to CSV, and verifiable in one call. Your auditor doesn't need to trust your storage; they can recompute the chain themselves.

Putting it together

When an action is proposed — say, your agent wants to charge a virtual card $47.23 at AWS — the request flows through:

1. Resolve the identity. Walk the chain. If any ancestor is revoked, deny.
2. Evaluate every applicable policy. If any explicitly denies, or none permits, deny.
3. Check every applicable budget. If any would go negative after this action, deny.
4. Reserve the budget. Allow.
5. Write the audit row, hash-linked to the previous one.

The whole thing is a few hundred milliseconds. It is the same five steps whether the action is a card swipe, a contract signature, or a call to an external API — the action is just a string and a few attributes.

Where it lives

Ledgerline is a control plane your agents call before acting. Two integration shapes are supported today:

• Inline — your agent code calls POST /v1/authorize and acts only on a permit response. This is the right shape for code paths you control.
• Real-time card auth — for spending, you issue virtual cards through Ledgerline. The card network calls Ledgerline at the moment of swipe, and Ledgerline allows or declines synchronously. The agent code doesn't change.

More integration shapes (contract co-signing, message routing, deal-room approvals) ship as we hear what design partners actually need.

What Ledgerline is not

• Not an LLM observability tool. If you want to see a trace of every prompt and tool call, use LangSmith or Langfuse. Pair them with Ledgerline.
• Not a content guardrail. If you want to stop the model from saying something embarrassing, use a guardrail library. Ledgerline operates one layer below — once the agent decides to act, did it have authority to.
• Not a replacement for IAM. Your agents still need credentials to talk to your databases and clouds. Ledgerline governs the actions taken with those credentials, not the credentials themselves.

Read the threat model → for what this design defends against, and what it doesn't.