lotor

# Lotor

A local receipt and approval gate for AI agent sessions. The agent can act, but it cannot sign.

## What it is

This tool writes a signed, tamper-evident log of what an agent did during a session: actions performed, files touched, messages sent, costs incurred, failures encountered. The log lives on your machine, in a format you can inspect, verify, and archive. It does not attempt to prove the agent's actions were correct, only to record them faithfully and make any subsequent tampering detectable.

It also gates the actions you choose. Those stop and wait for an approval signed with a passphrase the model has never seen and cannot derive, so an agent can request a consequential action but cannot authorize one. That is the whole of the tagline: it can act, it cannot sign.

## The other half of reliability

The argument getting loud right now is that you cannot have agentic systems that are reliable unless they can predict the consequences of their actions. That is true, and it is only the front half. Prediction is the front of reliability. The record is the back. A world model guesses what an action will do. A receipt states what it did. You need both, and only one of them is something you can hold in your hand today.

Lotor is the back half. It does not give your agent a world model. It gives you a signed, ordered, tamper-evident record of what your agent's session reported doing, so that "reliable" stops being a claim and starts being a record you can check. Not ground truth. A record, kept by you, that cannot be quietly changed afterward.

And it keeps that record where it belongs. The other warning in the same breath is about culture: if the world's information diet runs through a handful of proprietary engines, that is the end of local culture, and no system is ever truly unbiased. The same centralization is happening one layer down, quietly, to the record of what your agents do for you. Most accountability tools are cloud observability proxies. Your agent's activity flows through their servers, and your own history becomes inventory in someone else's books.

Lotor is routed local first. The receipt is written to your machine and nowhere else. There is no upload path, no account, no server component: nothing leaves because nothing is built to send it. Scoped custodial integrations, the sanctioned way to hand a redacted slice of your record to an auditor, a client, or your own IT, are pending. Reach out for details. That is the whole distinction, not a deployment checkbox and not an enterprise tier. The record of what your machines did for you lives with you, survives whichever vendor you were renting this quarter, and answers to your key, not their retention policy.

That is what a receipt means when the models centralize and the agents multiply. Your books. Local first. The floor that does not move when the vendor does.

## A company cannot audit itself

Every accountability story hits the same wall. The party that produced the record cannot also be the only one who keeps it and checks it. That is not an audit. That is a company grading its own homework. When the vendor whose model did the work also owns the sole log of what it did, you are trusting the audited party to certify itself.

Trust used to be the default, because checking was expensive. That assumption is expiring in public, one incident at a time. What replaces it is not more faith in the vendor. It is a record the vendor does not hold.

Lotor separates the two roles by construction. The receipt is written local first, to your machine, under your key. The party with the real stake in the record's integrity, you, is the party that keeps it. The one who did the work does not get to be the one who certifies it. That is why local first is not a feature here. It is the point.

The same rule points back at this repository. What is wrong with Lotor is published by the party it costs, and the fixes are open to you: the [confession board](./confessions/) is a live list of real holes in this tool, each with a reproduction and a scope. It is there so you can check the work instead of taking it.

## Use cases

Lotor is one primitive, a signed local receipt, applied wherever "what did my agent actually do" is a question you need answered honestly.

- **Replacing your harness's permission prompts.** Run the agent with its own confirmations off and let Lotor be the thing that stops it. A harness prompt is per-call, ephemeral, and dismissed with a click, which is the shape of a control people learn to click through. A Lotor gate is bound to one exact command, signed with a key the agent cannot produce, single use, and recorded whether you approve or deny. You trade a prompt you stop reading for a signature you have to mean.
- **Long-horizon and delegated work.** A gate that costs one trip to a terminal per action is a gate that gets turned off during exactly the sessions worth gating. Delegation grants make one signature cover an enumerated set of requests, so a long build or an overnight run stays gated instead of becoming a choice between friction and no floor at all.
- **Answering "what actually ran" without spending context.** Reconstructing what happened costs tokens: re-reading files, re-deriving history, holding it all in the window. Querying a receipt costs almost nothing and is not subject to the agent's account of itself. In practice the record is often faster than the reasoning, and it is right more often. A worker in this project once reported which model it was running on, in the section of its report reserved for admitting uncertainty, and was wrong. The receipt was not.
- **Session accountability.** End every interactive session with a signed receipt: what ran, what it touched, what it sent, what it cost, what failed. Failures are surfaced, not buried.
- **Overnight and unattended runs.** Wake up to a morning-after record of what an agent did while you were not watching, instead of a pile of transcripts you will never read.
- **Gated high-stakes actions.** Make destructive or irreversible actions (delete, deploy, send, spend) fail closed until you sign an approval bound to that exact action and its exact parameters. The denial and the approval are both receipted.
- **Proof of your side.** When a client, vendor, or counterparty disputes what happened, you have your own signed record. Their books, and now yours.
- **Tamper-evidence.** The chain detects after-the-fact alteration of the log. It does not prove the events were complete or truthful at capture time (see Known limits), but it proves the record has not been changed since.
- **Feeding your own memory.** Receipts are durable, structured input to your own long-horizon agent memory, not telemetry for a vendor's dashboard.
- **Vendor-churn survival.** Switch models or providers whenever you want. The record stays on your machine and stays readable. Your history does not belong to whichever engine you were renting.
- **Scoped custodial integrations (pending, reach out for details).** The sanctioned path for sharing a record with an auditor, a client, or your own IT: a scoped, redacted view, signed, sent only where you send it. Not built in v1. Today the default is absolute rather than chosen, because there is no export path at all. Anything you share, you share by hand.

## Claim discipline

Provable priority, not enforced credit. This is bookkeeping: their books, and now yours.

Measurement, not indictment. A receipt records what the session self-reports; it does not judge intent or catch silent failures.

Self-attested capture. The log begins at signing time. What happened before that moment is not covered by the tamper-evidence chain.

Nothing described in the present tense here is unbuilt. Anything not built is in the list below or in [KNOWN-LIMITS.md](./KNOWN-LIMITS.md), and it is marked pending in the same breath as it is named.

## Herding modes

Nine gated-or-warned matchers is not a posture anyone can hold in their head. Three named presets replace the nine-switch matrix with a single choice:

| Mode | Posture | Egress rules (push, publish, egress-other, opaque-exec) | Local-only rules (destructive, scope-escalation) |
|---|---|---|---|
| **Herded** | the pen | gate | gate |
| **Grazing** | the fence — the default on a fresh install | gate | warn |
| **Loose** | the open field | warn | warn |

`self-mod` and `mode-change` gate in every mode, with no exception. Loose means free to act on the world, not free to rewrite what stops you: an agent in Loose still cannot edit the gate, its policy, its hooks, or switch modes without your signature. Loose also never turns a rule fully `off` — it warns, which still appends a receipt. The alternative (`off`) would make the most dangerous mode the one that leaves the least evidence, since an unmatched rule takes a fast path with no chain write at all.

Check or switch the mode:

```bash
npm run mode              # print the current mode and its rule-by-rule expansion
npm run mode -- herded    # switch (requires your approval passphrase at a real terminal)
```

Switching requires the same passphrase that signs a gated action, for the same reason: changing what everything else requires should cost at least as much as approving one thing. The mode in force is stamped into every session's opening receipt (see `npm run receipts`), so a switch is never invisible after the fact.

An existing `policy.json` from before this feature shipped is not silently upgraded. It keeps its hand-tuned rules and loads with mode `custom`; naming a preset only happens when you ask for one.

**Honest limit.** Lotor's mode is independent of your harness's own permission mode, and the two do not compensate for one another. Loose plus a harness set to bypass its own checks is genuinely nothing stopping anything on either layer. Lotor now warns when it sees that combination and records the posture once per session, because your harness reports its own mode on every