Bottom line up front: An owner can trust AI-operated finance when five things hold: the record cannot be quietly changed, the rules are code a person can read, the secrets are managed rather than remembered, every consequential action waits for a named human, and someone can see all of it happening. Together they form a gate that every use of AI passes through, and that gate is a sufficient trust architecture. It does not require a distributed ledger. Verifiable credentials are a separate, optional layer built on top of the record, not part of the gate. Paper #11 in the Thought-OS™ reading order.

Don Lovett, Fractional CFO & Managing Principal · ProjectBits Consulting · October 2026

Abstract

When an AI system categorizes transactions, drafts invoices, and closes the month, the owner has handed it a kind of authority, and the first question a careful owner asks is not "is it accurate?" but "how would I know if it were not?" This paper answers that question with an architecture of five components, which I call the Trust Stack: append-only storage, policy-as-code, secrets management, an approval state machine, and observability.

The claim is deliberately modest. The stack is sufficient, not exotic. Each component is commodity infrastructure, several are decades old, and none requires a blockchain or a distributed ledger. What makes it a stack rather than a shopping list is that each layer closes a gap the one beneath it leaves open, and that the top layer is a person: a human approval whose strength is matched to what the action can undo.

Two parts of the paper go further than the five layers. The first is the gate: how the layers combine into a single path that every use of AI must travel, from identity, through a proxy and a policy decision, through approval, into the record. The second is the identity question under the approval step: what it means to prove a human approved something, and why the strength of that proof should scale with reversibility, not with frequency.

A third, separate topic comes last and is deliberately kept apart. Once the record is trustworthy, an owner may want to carry proof of it to a lender, a buyer, or an insurer without calling their bookkeeper, which is what verifiable credentials promise. That is portable proof, not access control. The gate does not depend on it, and it does not enforce anything. I built the pieces to test the promise and hit a wall I describe in full, because it decides who holds the power.

The paper ends with the boundary. A trust architecture proves what the books say and who did what. It does not make the work good. Sign sloppy work cryptographically and you have signed a lie, faster.

Part I — The Question Nobody Asks Until It Is Late

Every owner who has adopted an AI bookkeeper has been shown a demonstration. The categories are right, the reconciliation is instant, the report is clean. The demonstration answers the question does it work today?

The question that matters arrives later, usually from a third party. A lender asks how the numbers in the package were produced. An insurer asks who can change a payment instruction. A buyer’s accountant asks whether the March close was altered after the fact. A state notice arrives about a year nobody remembers closing. In each case, the person asking is not interested in whether the system is clever. They want to know whether the record can be relied on and whether the authority behind it was legitimate.

Most small-company systems cannot answer, and the reason is structural. They were built to be convenient. Convenience means editing in place, overwriting a field when a number changes, and letting a logged-in session do whatever the person behind it could do. That model was tolerable when the person behind the session was the owner or a bookkeeper they knew. It is not tolerable when one of the actors is an agent that works continuously, never gets tired, and will do exactly what its credentials allow, including things nobody intended.

I came at this as a CFO, not a security engineer, and the framing that helped most is the one a controller already uses: segregation of duties, and a trail you cannot edit. The Trust Stack is those two old ideas, rebuilt so they hold when some of the people in the process are software.

Part II — Five Layers, One Job Each

Here is the whole stack at a glance. Each layer answers one question, and the question is the test of whether you actually have it.

The order matters, because the layers lean on each other.

Layer 1 — Append-only storage

The first property is the one people mean when they say "audit trail," and the one they most often fake. A real audit trail is a record that cannot be altered by the same actors it records. A log that an administrator can edit is a diary.

In practice this means three habits enforced by the database rather than by good intentions. Rows are inserted, never updated. A correction is a new row that supersedes the old one, and both remain. And the table’s permissions are set so the application account can write new rows but cannot change or remove old ones.

Maria Sandoval, whom you will meet in Paper 12, recorded a $12,000 meals expense in March at fifty percent deductible. In August a review found $3,000 of staff-event meals that are fully deductible. Under an append-only record, nothing is erased. The March row stands; an August row supersedes it; anyone can see both, and the date of the change. The correction is visible rather than hidden, and visibility is what makes it believable.

Tamper-evidence can be made stronger at commodity cost. Each row can carry a hash of the row before it, so changing any past row breaks every row after. A daily root hash can be signed with a managed key and stored somewhere the application cannot reach. Source documents can sit in object storage with retention locks. None of this is a blockchain. It is a hash chain and a write-once bucket, and it answers the only question the auditor has: has this been touched?

Layer 2 — Policy-as-code

The second layer exists because immutability is not enough. An append-only ledger can faithfully preserve a wrong decision. The question after "was it changed?" is "who allowed it, under what rule?"

Most small-company rules live in documents: a policy PDF, an approval email, a sentence in an engagement letter. Documents are not wrong, but they cannot be executed. They cannot refuse a payment that violates them. They cannot be tested. They drift.

Policy-as-code moves the rule into a file an engine evaluates at the moment of the action. "No payment over $10,000 without owner approval" stops being a sentence and becomes a function that returns allow, deny, or require approval, with its inputs and reasoning recorded. The rule has a version. The version has tests. A change to the rule is itself a recorded, reviewed event.

I use Open Policy Agent and its Rego language, but the tool is not the point. The point is that the rule is readable by the owner, runnable by a machine, and the same in both places. An owner who cannot read the rule is trusting me. An owner who can read it is checking me, which is the position a careful owner should be in.

Paper 12 takes this layer further than I do here, treating the rulebook as three separately owned bundles with tests and decision logs. For this paper, the essential claim is smaller: rule-versioning is empty unless the rule is something that runs.

Layer 3 — Secrets management

The third layer is the least glamorous and the one most often responsible for real incidents. Every system in the stack authenticates to something: a bank feed, an accounting platform, a mail service, a database. Each authentication is a secret. Where those secrets live determines whether the first two layers mean anything, because an attacker, or an honest mistake, who holds the key to the storage can bypass the rule engine entirely.

The failure modes are mundane. A password in a spreadsheet. An API key pasted into a chat to "just get it working." A shared login whose owner left. A token that never rotates because rotating it would break something nobody wants to touch.

Managed secrets means the credentials live in a vault, are issued to a service rather than a person, are scoped to what that service needs, and can be rotated or revoked without hunting through documents. The practical test is one question: if an employee, a contractor, or an agent left today, how long would it take to know which secrets they could reach, and to rotate them? If the answer is "we’d have to think about it," the layer is missing.

Layer 4 — The approval state machine

This is where the stack stops being infrastructure and meets a person.

A state machine is a simple idea: an action has a defined set of states, and defined, enforced transitions between them. For consequential actions, the states are roughly requested, evaluated, pending approval, approved or denied, executed, and verified. The crucial design rule is that there is no path from "pending" to "executed" that does not pass through a named human. An agent can request. An agent can prepare, with the evidence attached. An agent cannot approve its own request, and the engine cannot be talked into a shortcut, because the shortcut does not exist as a transition.

I describe the owner’s position relative to the work using four words, because they map directly to how much proof each position needs:

• Under the loop. The agent acts on its own and a human reviews afterward, if at all: read-only queries, draft generation, triage.
• On the loop. The agent acts continuously and the human can interrupt without approving each step: queues, monitors, routine categorization.
• In the loop. The agent proposes and the human must explicitly approve before anything executes: payments, filings, anything that leaves the building.
• Above the loop. The human sets the policy: what the agent may do at all.

The position determines the design. Under the loop, you need to know which system acted. In the loop, you need to know which person approved, and that it was really them. Above the loop, you need that and more, because a mistake or a compromise here silently rewrites the rules for everything beneath it.

Layer 5 — Observability

The last layer is the one that makes the other four honest. A system can have an append-only record, executable rules, vaulted secrets, and an approval gate, and still fail quietly: a job stops running, a gate gets disabled, a rule is edited without review, a denial rate drifts upward and nobody looks.

Observability is the discipline of making the stack’s own behavior visible to a person on a schedule. It includes the obvious things: logs, alerts, uptime. It also includes the specific signals that tell you the controls are alive: how many decisions were made this week, how many were denied, how many waited on approval and for how long, whether the daily hash was anchored, whether the last backup restored.

The most important lesson here came from my own estate. I once had monitors that watched whether jobs ran and none that watched whether what they read was true. A job can exit cleanly while reading an empty page behind a login wall, and report success on zero rows. Monitoring that checks activity instead of outcome gives you a green dashboard on a dead process. The Trust Stack’s fifth layer is not "we have monitoring." It is "something checks the outcome, and a person looks at it."

Part III — The Gate: Where AI Use Is Actually Controlled

The five layers are components. The control comes from putting them in a line, so that no use of AI can reach a model, a client record, or a payment instruction without passing through them in order. I call that line the gate, and it is worth being exact about what it is made of, because it is the part that governs AI use and it does not rely on credentials at all.

1. Identity. Every request carries an identity: a person, or a named agent or service. This is where secrets management and the strength-of-proof rule in Part V apply.
2. The proxy. All traffic to AI services is forced through one controlled point. The rule is blunt: no proxy, no model access. Outbound connections to known AI hosts are blocked everywhere except from the proxy, and the proxy sits on its own network segment so a user cannot get around it by changing an address on the local network.
3. The policy decision. The proxy asks the rule engine before it forwards anything. The engine returns allow, deny, or require approval, based on who is asking, which service, what kind of data, and which version of the rulebook.
4. Approval. If the answer is require approval, the request waits in the state machine for a named human. There is no path around it.
5. The record. Every request, decision, denial, and approval is written to the append-only store with the rule version attached, and observability watches the result.

The proxy has a natural ladder, and the point of the ladder is to match the depth of inspection to the sensitivity of the use. At the first rung, the proxy sees only which AI service is being contacted and by whom, without decrypting anything, and asks the rule engine whether that person, on that device, may use that tool. That alone answers the question most firms cannot answer today: which AI tools are actually in use, including the ones nobody approved. At the second rung, traffic to AI hosts only is decrypted so the content of each request can be classified before anything leaves; everything else is passed through untouched. The third rung, reserved for the enhanced tier, would act on that classification, routing confidential prompts to a model running on the firm’s own hardware and recording the response, because capturing and acting on content is itself a privacy decision that needs a reason.

Where this stands is not in this paper, on purpose. I am building the gate on my own estate in phases, and its state changes week to week: which rung is enforcing, which devices are covered, what the tests currently show. A number printed here would be stale before a reader found it. The current state lives in the build’s own daily evidence reports, which are generated from the ledger rather than written by hand. What belongs in a paper is what held up no matter where the build stood, and there are four such lessons.

A gate has to say what happens when it breaks. A gate that fails open produces evidence but does not control, and a gate that fails closed controls but can stop the work. Neither is wrong, but the choice must be deliberate, written down, and visible in the record, with the unreachable state logged as such. The claim "no proxy, no model access" is only true once direct egress is blocked at the firewall; until then the proxy is a checkpoint people can walk around. Treat the cutover from one to the other as its own event, with its own proof.

Every gate has bypasses, so list them. Some programs ignore the system proxy, some devices cannot be pointed at it, and some traffic never touches it. The honest control is a daily report that names what is not covered, so that an exception is a visible line item rather than a surprise.

Rules are the right first layer and the wrong only layer. Pattern rules catch structured identifiers such as Social Security numbers, card numbers, and keys with high precision. They miss prompts that describe a client’s situation without containing any identifier. Content inspection needs a second, semantic layer, and it should be evaluated on held-out examples rather than on the ones the rules were tuned against.

Prove the control with the failure, not the success. A rulebook is not tested until it has negative cases that must deny, and a ledger is not tamper-evident until someone has rewritten it and the copy caught the difference.

Notice what is absent from this list. The gate makes no use of verifiable credentials, wallets, or decentralized identifiers. It does not need them. An agent’s limits are enforced because the proxy refuses the request and the rule engine says no, not because the agent holds a signed statement of its mandate. A signed statement can describe a limit. Only a control can enforce one. Keeping that distinction clear is the reason Part VI is separate from this part.

Part IV — Why Not a Distributed Ledger

Anyone who has read about tamper-proof records has met the suggestion that the answer is a blockchain. It is worth being precise about why the stack above does not need one, because the claim is easy to overstate in either direction.

A distributed ledger solves a specific problem: a group of parties who do not trust each other need a shared record that none of them can unilaterally rewrite, and there is no neutral party they would all accept to hold it. Cryptocurrency is the canonical case. The cost of the solution is real: throughput limits, key-management burdens, immutability that conflicts with legal rights to correct or erase, and an operating complexity most owner-operated firms cannot staff.

An owner-operated firm does not have that problem. It has one owner, a bookkeeper or an agent, an accountant, a bank, and a regulator, and all of those parties already operate inside a framework of law, licensure, and contract. The risk is not that nobody can be trusted to hold the record. It is that the record might be edited quietly, or that an authority might be exercised without a trail. Both are solved by an append-only store with a hash chain, a signed daily root, retention-locked source documents, and an approval gate. That is cheaper, easier to audit, and compatible with legal obligations like corrections and retention schedules.

There is one place where a shared, neutral record could be worth its cost: multi-party settlement, where several institutions must agree on the state of something none of them controls. That is a real use case. It is not the owner’s use case, and it should not be sold to the owner as though it were.

Part V — The Strength of the Proof Should Match What the Action Can Undo

The approval layer has a hidden requirement. "A named human approved it" is only as strong as your ability to show that the human, and not someone using their session, did the approving. This is an identity problem, and it has a clean answer if you ask the right question.

The wrong question is how often does this action happen? Frequent actions feel like they deserve low friction, and rare ones feel like they deserve ceremony. That reasoning is backwards. The right question is the blast radius: if this exact credential were phished right now, what is the worst thing that could happen?

NIST’s digital identity guidelines, SP 800-63, give a vocabulary for this in three Authenticator Assurance Levels. At the first level, a password or PIN alone proves little; it is acceptable only where compromise has a minimal blast radius, such as a read-only dashboard. At the second level, two factors, such as a password plus a code or a biometric unlock on a device, are strong for routine use but can still be defeated by a real-time relay, where an attacker proxies the login as the victim performs it. At the third level, the proof is a cryptographic signature from a hardware-bound key that never leaves the device and is bound to the genuine site’s address. A relay attack fails because the key will not sign a challenge from the wrong origin. There is no code to read aloud to a scammer and no password to type into a fake page.

Matched to the four loop positions, the rule that falls out is simple:

I chose the hardware token as the working example because I have done it by hand rather than diagrammed it. I enrolled a YubiKey as a key slot on an encrypted volume, and the design uses that same key as the approval signature in the gate. The approval is a physical tap: the key signs a challenge, the engine verifies the signature, and the transition from "pending" to "approved" is recorded with the proof attached. Phones can meet the same bar. A phone’s secure hardware holds a key bound to that device and gated by a biometric, and by the NIST definition that qualifies. What a phone cannot do as easily is be issued, inventoried, and revoked by an organization independently of the person carrying it, which is why a separate token remains the standard for attestation an organization controls. That is a trade-off, not a verdict, and the choice depends on who needs to be able to revoke what.

The point to carry forward is not the hardware. It is the rule of proportion: spend assurance where the action is hard to undo, and do not spend it where it is not.

Part VI — Portable Proof: Optional, Separate, and Downstream

This part is not about controlling AI. That is the gate, and it is complete without anything below. What follows concerns a different question: once the record is trustworthy, can the owner prove it to someone outside? A credential is evidence handed to a third party. It enforces nothing inside your systems, and nothing in the gate depends on it. If credentials never mature, the Trust Stack is unaffected.

Everything so far makes the books trustworthy to the owner and to ProjectBits. A lender, a buyer, or an insurer is a third party. They cannot read my vault. Today, the owner re-proves their financial maturity from scratch to each of them, by assembling packages, answering the same questions, and paying someone to vouch.

The idea that promises to change this is the verifiable credential. The plain-language version needs no jargon. Think of a notarized letter. A trusted party examines something, signs a statement about it, and hands you the letter. You can show the letter to anyone, and they can confirm the signature is genuine without calling the notary. A verifiable credential is that letter in digital form. The notary is the issuer, you are the holder, and the person you show it to is the verifier. The signature is checked against a public key the issuer publishes, so the verifier never has to contact the issuer.

For an owner, the credentials of interest are statements like these books were reconciled through the period, or this firm operates under a documented approval policy. Accumulated over time, they form what I have been calling a Financial Passport: a set of signed statements about the business that the owner carries and chooses to disclose.

The Trust Stack makes the credential credible, because the credential is not a new claim. It is a portable pointer to a computation the stack already recorded. Take the Larson Industries sandbox I use for demonstrations. Its ratio engine produced a survival score of 4.9, in the safe zone, on revenue of $1,007,883 and a current ratio of 1.33. The same run also produced a debt-to-equity ratio of 4.07 and a days-sales-outstanding of 118. I would put all of those numbers in the credential, including the weak ones, and I would do it on purpose. A credential that carries real weaknesses next to real strengths is the reason a lender would rely on it. A credential that says only nice things is marketing, and no verifier trusts marketing. The credential does not create trustworthiness. It makes an already-auditable computation portable, and the lineage behind it, which inputs, which formula, which rule version, is what lets a skeptical verifier ask for the receipts.

Part VII — Which Wallet Holds the Power?

Here is the part of the thesis that I tried to break, and where I found the weakness.

The standards behind verifiable credentials are open: the W3C data model, decentralized identifiers, and the OpenID protocols for issuing and presenting. The cryptography is solved and runs today. I built a working issuer, holder, and verifier loop on open-source components, with credentials signed by an identifier I control, and the loop closes. If the question were whether the math and the protocols work, the answer is yes.

The question that decides whether a Financial Passport is really the owner’s is different: where does the credential live, and who controls that place? A credential is only useful if it sits in a wallet the holder can open and present from. The obvious wallet is the one already on every enterprise phone, Microsoft Authenticator, which supports a feature called Verified ID. So I asked a simple question: can a credential signed by my own identifier be delivered into that wallet?

It cannot, and the reason is structural rather than a configuration problem. According to Microsoft’s own documentation, there are four independent locks. Issuance runs only through Microsoft’s hosted request service. The signing key is generated by Microsoft inside its key vault, with no path for you to import your own, so your key can never be the issuer. The credential’s schema must live in a Microsoft-hosted manifest. And the wire format is a link pointing back to Microsoft’s host rather than the open credential-offer format, so there is no seam where a self-hosted issuer could attach. Even a vendor with every commercial reason to offer a workaround reaches the wallet only by proxying Microsoft’s service with your Microsoft credentials. The path also accepts only one credential format, which rules out the selective-disclosure formats an insurance underwriter would want.

This was established through a structured research pass across many sources, and I rate the core finding as strong: the four locks were each confirmed against vendor documentation, not inferred. What I did not verify is the mobile wallets from other vendors and the European digital identity wallet efforts. I expect some to behave differently, and I will not claim otherwise until I have tested them. The wallet I could run end to end in my own lab is a custodial web wallet, not a phone app, which is its own custody question.

The implication is the sentence I would put on the wall:

The specifications are open and genuinely interoperable. The wallet with distribution is a walled garden. Self-sovereign identity delivered through a wallet you do not control is sovereign at the specification layer and captured at the product layer.

I do not say this to discourage the idea. I say it because every brochure about this topic skips it, and because an owner deciding whether to build a Financial Passport should ask the vendor the same question I asked: which wallet holds it, who controls that wallet, and what happens to my credentials if the relationship ends? The constructive version is that the open loop works today, the cryptography is not the obstacle, and the unresolved part is custody and distribution. That is a market problem, not a math problem, and it will resolve in one direction or the other. Until it does, the honest design is one where the owner’s proof is portable out of any wallet, and where the record underneath is the Trust Stack, which is the owner’s regardless of where a credential is presented.

Part VIII — What the Stack Does Not Do

A trust architecture has a boundary, and an author who does not state it is selling something.

It does not make the work correct. The stack proves who recorded a number, from what, under which rule, and that it has not been altered. It does not prove that the number is right. If an agent miscategorizes a transaction under a flawed rule and a human approves it, the stack will preserve that mistake with perfect fidelity and a valid signature. A credential built on sloppy work is a signed lie, delivered faster. The stack’s value is that the lie is attributable and correctable, not that it cannot happen.

It does not govern through credentials. The limits on what an agent may do are enforced by the proxy, the rule engine, and the approval gate. A credential can describe those limits to an outsider; it cannot enforce them.

It does not replace the books. A credential is a presentation channel, not a system of record. The general ledger remains the general ledger. The Trust Stack surrounds it.

It cannot manufacture a verifier who cares. Cryptography can make a credential checkable in a second. It cannot make a lender, a buyer, or an insurer want to check it. The Financial Passport is only worth building to the extent that someone on the receiving end changes a decision because of it, whether by faster approval, a better rate, or a tighter due-diligence process. That is a demand problem, and I have not solved it. Anyone who tells you the technology creates its own demand is describing a hope.

It does not remove the human. Every layer either supports a person or ends in one. The approval state machine is a place where a named human takes responsibility on the record. If the owner is unreachable, the stack will faithfully refuse to act. Paper 13 takes up exactly that problem: authority that remains verifiable and bounded when the approver cannot be present.

Part IX — Where to Start

The stack can be built in an order that pays for itself as you go, because the early layers are cheap.

1. Make the record append-only. Stop updating rows. Insert corrections. Remove the application’s permission to change or delete history. This is the cheapest control with the largest effect.
2. Move secrets into a vault. Inventory every credential. Issue them to services, not people. Rotate the ones that have not changed in a year.
3. Write the three rules that matter most as code. Payment thresholds, who may approve what, and what requires a second person. Three rules, with tests, beats thirty in a binder.
4. Put the approval gate in front of anything that leaves the building. Payments, filings, client-facing reports. No path from "pending" to "done" that skips a named person.
5. Find out what AI is in use. Route AI traffic through a single proxy at the first rung and look. Expect to find tools nobody listed. Tier the tools and write the rules. Roll out in phases, name every device the gate does not yet cover, and then block direct egress, because a gate that can be walked around controls nothing.
6. Match the proof to the position. Use hardware-bound approval for the in-the-loop and above-the-loop actions. Do not spend it on read-only access.
7. Make something look at it. Pick the five numbers that tell you the controls are alive. Check them weekly. Check outcomes, not just whether jobs ran.
8. Only then, ask about portable proof. Credentials are optional and sit on top of the record. A credential on top of a stack you have is a force multiplier. A credential on top of a stack you do not have is decoration.

Closing — The Answer to the Careful Owner

The careful owner asked, at the start, how they would know if the system were wrong. The honest answer has two halves. The first is that the Trust Stack makes the system’s behavior knowable: what happened, under which rule, approved by whom, and unaltered since. The second is that knowability is not correctness, and a person still has to look.

The stack does not ask the owner to trust the AI, or to trust me. It asks them to trust a record they can inspect, rules they can read, and an approval only they can give. That is a smaller trust to extend, and a far more defensible one.

Relationship to the Series

Paper 11 establishes the architecture. Paper 12, The Provenance Ledger, takes the first two layers further for tax-ready books, adding the bitemporal record and the rule registry, and gives the stack its first fully worked application. Paper 13, The Owner’s DAO, takes the governance and continuity layers forward: what happens when the approver cannot approve.

Sources and Standards

• NIST SP 800-63-4, Digital Identity Guidelines (July 2025), which defines the Authenticator Assurance Levels used in Part V.
• W3C, Verifiable Credentials Data Model and Decentralized Identifiers (DIDs), the open specifications referenced in Parts VI and VII.
• OpenID for Verifiable Credential Issuance and OpenID for Verifiable Presentations, the open protocols referenced in Part VII.
• Microsoft Entra Verified ID documentation, the source for the four structural constraints described in Part VII.
• FIDO Alliance, FIDO2 / WebAuthn, the origin-bound authentication standard behind the hardware-key discussion in Part V.
• Larson Industries is a sandbox company used for demonstration; its figures illustrate the method and are not a client’s results.

This paper is the eleventh in the ProjectBits reading order. Read the series in order at projectbits.com/method. It is followed by Paper 12, The Provenance Ledger.

ProjectBits Consulting · projectbits.com/method · Reston, VA. Thought-OS™, CFO-OS™ and Tax Ready Bookkeeping™ are trademarks of ProjectBits Consulting. This paper is published for practitioner and client education.