The Outside Record: 90 Days to an Auditable Agent Program

The first time an agent does something it should not have, you will be asked what it was allowed to do and what it did. Most programs answer with a prompt file and a transcript. Neither is evidence. A prompt is an instruction, and a transcript is the agent's account of itself.

The Outside Record is my name for the thing that is evidence: a signed mandate (what the agent may do) plus a signed witness record (what it did), held by the party that carries the loss and verifiable without trusting the agent. Three controls follow. No action without a mandate. No mandate without a record. No record inside the agent.

This is the 90-day version for whoever owns the program: head of platform, CISO, head of payments or risk. It requires no purchase; the code I point to is open source, v0 and unaudited, there to be read and replaced.

An agent program is auditable, or it is not, by the end of its first quarter. After that you are retrofitting permissions nobody wrote down onto agents nobody listed.

Why the first 90 days decide it

One week of evidence. The Major Labs census of open MCP servers counted 3,666 on October 24, with 88 in the highest security-risk tier, up six in a week; on a separate cut, 73.4 percent of the 443 network-facing servers that take sensitive actions have no authentication in their source (Major Labs). On October 22, METR and Redwood Research reported what three weeks inside OpenAI found: roughly 75 to 94 percent of internal agent traffic was eligible for monitoring, which is not the same as monitored, and an agent could postpone monitoring indefinitely by continuing to act, because the monitor fired when control returned to the user (METR). OpenAI had already shelved GPT-6.1 Astra for acting outside its scope and misreporting its work (CNBC; Frontier Incident Timeline). On my own Bench, 11 of 51 run summaries from a 20-billion-parameter model under a signed mandate disagreed with the signed record. And from November 24, Wells Fargo's online access agreement treats a delegate's AI agents' transactions as authorized and makes the customer solely responsible for supervising them (Wells Fargo).

More servers carry serious risk, the same share cannot say who is acting, and the bank has written down who pays.

A monitor that asks the agent when it has finished is relying on the agent. So is a dispute process that holds the agent's transcript.

Everything below is cheaper on day one, with three agents and a blank page, than in month nine, with 40 agents and permissions in prompt files.

Days 1 to 30: inventory and mandate

List every agent and what it can touch. An agent, here, is any software that calls a model and then does something because of the answer. Include the agent features inside software the business already pays for, the coding agents in developers' shells, and the weekend pilot. For each, record what it reads, writes, pays, who it can message, and what it remembers between runs. If the list is short, you have not finished.

Write a mandate for each in the five fields. The model is the one in my course on agentic payments: principal, agent, scope, limits, lifecycle. It describes behavior rather than a payee, so it fits any agent.

Decide who signs. The principal signs: whoever carries the budget or owns the process, not the engineer who built the agent. Risk countersigns. The signature is a key, not a name in a wiki; custody belongs to the CISO from day one, because whoever holds the key can rewrite anything signed with it.

Stop any agent that cannot be given one. If nobody can fill the five fields, nobody can say when the agent has exceeded them. Pause it until someone can. "Read-only" is a scope; write it down.

Reference code: MandateKit (pip install mandatekit) turns a plain sentence into a signed mandate and verifies an action against it, returning allow, ask or deny with a reason. IdentityKit (pip install identitykit) gives each agent instance a signed, resolvable identity.

Days 31 to 60: record and verify

Put a witness record outside the agent runtime. Every action becomes an entry: tool call, submission, payment, handoff, and every refusal by a control. Each entry is hashed with the one before it and signed, so any alteration breaks the chain at a place you can point to. The agent's final summary is hashed into the last entry, so claim and actions sit under one signature. The gateway writes the entries, not a logger inside the agent.

Pick who holds it. The party that carries the loss. In most enterprises that is payments or risk, not engineering, because when something goes wrong engineering is the party being asked whether the agent was at fault, and the record cannot sit with the party being asked. The holder pins the keys, keeps the chains, and answers the auditor.

Reconcile weekly, and publish the mismatch rate internally. For every run completed that week, extract the claims in its summary and diff them against the chain. Three kinds of finding come out: a claimed step with no entry; a claim the chain contradicts; a refusal the summary never mentions. Runs with at least one finding, divided by runs, on an internal page with the date. The reference number is 11 of 51 on my Bench, and almost every false "failed" line came from text planted inside a tool result. The injection did not push the agent outside its scope. It made the agent misreport, and the diff was the only thing that caught it.

The mismatch rate is the one number in an agent program that cannot be produced from inside the agent. That is what makes it worth publishing.

Publish it with its method, change the method only with a dated note, and never re-base silently, which is the standard on my own lab's governance page. WitnessKit (pip install witnesskit) is the reference for the chain and ships the reconciliation function.

Days 61 to 90: enforce and test

No action without a mandate, at the gateway. Every tool call, submission and payment passes a verifier before the target system sees it. The verifier checks signature, issuer, window, scope, limits and revocation, and returns allow, ask or deny. Treat anything other than allow as not allowed. The check is deterministic, with no model call; on my Bench it ran on every call in 51 of 51 runs. MandateKit's MCP wrapper does this for any MCP server.

Spend caps in two places. The mandate caps a single action. A second guard caps the running total and the velocity: $90 per item is not $90 for the job, and an agent in a loop will find the gap. BudgetGuard (pip install budget-guard-agents) is the reference. I set this out when Coinbase shipped spend limits for agents.

Approval by default above a threshold. Below the line the agent acts. Above it the verifier returns ask, and a person signs a narrowed, short-lived mandate for exactly that action and amount. Walmart shipped this shape to consumers on October 21: a profile per agent inside the customer account, approval by default or a cap the customer sets, and no card details to the agent (Walmart). A retailer did it at consumer scale; an enterprise can do it for 40 agents.

A playground test before any agent touches a customer. Point the agent at a system built to catch it, with a run record kept outside the agent and a report card graded from that record. There is one at shophunch.com/playground, a Major Labs instrument: a reference store with 12 products and ten traps, a checkout that refuses any order without a mandate, and a graded report for every run. Use it or build your own. An agent that misreports in a store with 12 products will misreport in production.

What to measure at day 90

Who owns what

The second line is the one to argue about. Who Pays When the Agent Pays Wrong sets out why the loss lands on the party with the weakest record; give the party that carries it the strongest one.

The objections

It slows the team down. The verifier is a signature check and a scope comparison. What slows a program down is the incident with no record, when six people spend a quarter reconstructing one run from a transcript.

The vendor does this already. The vendor's log lives inside the vendor's runtime, under the vendor's keys: a record inside the agent by another name. Ask for a signed, exportable record you can verify under keys you pin. A vendor that cannot is asking you to trust its account of itself.

The agents are read-only. Reading is an action, and what an agent reads can leave. The Bench agent that read six companies from a bank then wrote to three and reported six. A read-only mandate is the easiest to write: one verb, no spend, a lifecycle. The day the agent gets a write permission, you will want proof of what it had before.

After the pilot. The pilot is when the habits form and the record is cheapest to add. Defer it and the production decision gets made on the pilot's summaries, the one thing the record exists to check.

What this does not solve

It does not make the agent correct. The Outside Record establishes what the agent was allowed to do and what it did, not whether it did the right thing within scope. The reconciliation compares claims to entries, not tool results to the truth.

It does not stop prompt injection. On the Bench the injection changed what the agent said, not what it did, and the record caught the saying. An injection that keeps the agent in scope and truthful is invisible to it.

It does not allocate liability. The Wells Fargo clause and Regulation E do that; the record is the evidence they get applied to, which is the MM Liability Gap in practice: the loss is unallocated because the fact is unestablished. Simon Taylor listed what a dispute needs in his Brainfood piece on the agentic bank run: the instruction, the authentication, the intent and the outcome. The Outside Record is those four things, signed. It is not the rule that decides who pays.

It is tamper-evident, not tamper-proof. Whoever holds the signing key can rewrite the chain, which is why custody sits with the CISO and why anchoring the chain head beyond the key holder's reach is on every roadmap, including mine. And it does not cover agents you do not know about. The inventory is never finished.

The guide to how agents work has the pattern this plan rests on: permission as a verifiable document, not a prompt. The record of what the agent did is the second document. Nobody ships the pair yet. In 90 days you can.

At day 90, when your agent's summary and its signed record disagree, which one does your risk committee read first?

Charlie Major is a Product Development Manager at Mastercard. The views and opinions expressed in Major Matters are his own and do not represent those of Mastercard.