Running AI Bookkeeping Agents in Per-Tenant MicroVMs

Accounting automation has a specific way of failing that other AI-agent workloads don't: it fails quietly and it fails into a number someone trusts. An agent that reconciles a bank feed against an invoice ledger, categorizes expenses, or proposes journal entries for a monthly close isn't producing a summary a human will sanity-check against the source — it's producing the books. If it matches a $4,200 refund from Client A's bank feed against Client B's open invoice because both were sitting in the same process's working memory, nothing crashes. The close just completes, on schedule, with a plausible-looking number that is wrong.

I'm Ajay, I build PandaStack. This post is about why AI bookkeeping and reconciliation agents deserve the same per-tenant isolation discipline as a database or a billing engine, and about a specific pattern: one ephemeral microVM per client per close, seeded only with that client's transactions, with tool access scoped to that client's accounting-system credentials and nothing else reachable.

Why reconciliation agents are a sharper problem than other agent workloads

Most AI-agent isolation writing focuses on the agent doing something destructive — running `rm -rf`, exfiltrating a secret, escaping to the host. Reconciliation agents can do plenty of that too, but their more common and more dangerous failure is subtler: matching the wrong two records. An agent that's given tool access to "the transaction database" instead of "this client's transactions" doesn't need a prompt injection to misbehave. It just needs a fuzzy-matching heuristic to find a closer match in the wrong company's data than the right one in the correct company's data, and it will take it, because nothing told it that record was off-limits.

• Bank feeds and invoice ledgers for multiple clients sitting in one process's context window is the same shared-cache problem billing engines have — except the agent's job is explicitly to go looking for matches, so it actively searches for cross-tenant collisions instead of accidentally tripping over them.
• Categorization models trained or fine-tuned on one client's chart of accounts shouldn't see another client's transaction descriptions during inference, both for privacy and because vendor names and memo fields are exactly the kind of thing that leaks in a support ticket screenshot.
• A reconciliation agent that calls out to a client's actual banking or accounting API (Plaid, QuickBooks, Xero, a corporate card platform) is holding live financial credentials — the tool-call surface is a real bank connection, not a mock.
• Auditors ask for exactly the same thing accountants have always asked for: show your work, for this client, for this period, reproducibly. A shared agent process with rolling context doesn't have a clean answer.

One microVM per client, per close

The pattern is the same shape as isolating a billing run or a per-tenant ETL job, applied to an agent instead of a fixed pipeline: for each client's monthly close, spin up a fresh sandbox, load only that client's exported transactions and open items into it, give the agent tool access scoped to that client's read-only accounting-system connection, let it propose matches and draft entries, capture the output, and destroy the machine. The orchestrator — the part that knows which clients are due for a close and holds the master credential vault — never runs client-specific reconciliation logic itself and never lets one guest's context include a second client's data.

from pandastack import Sandbox
import json

def reconcile_client_period(client_id: str, period: str,
                             bank_transactions: list[dict],
                             open_invoices: list[dict],
                             accounting_api_token: str) -> dict:
    """Reconcile ONE client's bank feed against ONE client's ledger, in a
    guest that has no other client's data or credentials in it at all."""
    sbx = Sandbox.create(
        template="agent",
        ttl_seconds=1200,
        metadata={"client": client_id, "period": period, "kind": "reconciliation"},
    )
    try:
        # Only this client's records enter the guest -- there is nothing
        # else present for a fuzzy matcher to accidentally match against.
        sbx.filesystem.write("/work/bank.json", json.dumps(bank_transactions))
        sbx.filesystem.write("/work/invoices.json", json.dumps(open_invoices))

        # Scoped credential: read-only, this client's accounting connection,
        # expires with the sandbox. Never the platform's master API key.
        sbx.env.set("ACCOUNTING_API_TOKEN", accounting_api_token)
        sbx.env.set("ACCOUNTING_API_SCOPE", client_id)

        out = sbx.exec(
            "cd /work && python3 -m reconcile.run "
            "--bank bank.json --invoices invoices.json --out matches.json",
            timeout_seconds=900,
        )
        if out.exit_code != 0:
            raise ReconciliationFailed(client_id, period, out.stderr)

        return json.loads(sbx.filesystem.read("/work/matches.json"))
    finally:
        sbx.kill()  # bank data, invoices, and the client's token all vanish

Two details matter more here than in a generic per-tenant job. First, network egress: the guest should only be able to reach that one client's accounting-API endpoint, not the general internet and not any other client's endpoint — an agent with a browsing or scraping tool attached is otherwise one instruction away from calling out somewhere it shouldn't. Second, the credential itself should be scoped and short-lived, ideally a read-only connection issued per run rather than a long-lived integration key checked out of a shared vault, so a compromised or confused agent run can do no more damage than reading data it was already entitled to see.

Agent-written matching code is still untrusted code

Modern reconciliation agents don't just call a fixed matching function — they write and execute matching logic on the fly, because real-world messiness (a vendor name that's abbreviated differently on the bank statement than the invoice, a payment split across two transactions, a foreign-currency conversion that doesn't quite match) resists a static rule set. That means the agent is generating and running a small program against real financial data on every close, which is exactly the code-execution risk that any AI coding agent carries, just wearing an accountant's hat.

Treat it accordingly: no filesystem access beyond the working directory for this run, no network egress beyond the one scoped API endpoint, resource limits tight enough that a pathological matching loop times out instead of running the meter, and a hard TTL so a wedged run gets reclaimed rather than lingering with a live credential. None of this is exotic — it's the same discipline covered in sandboxing untrusted Python and sandboxing LLM-generated code generally. What's specific to bookkeeping is the stakes: the artifact this code produces is a journal entry, and journal entries have a way of becoming permanent the moment someone approves the close.

The audit trail is the other deliverable

An accountant reviewing an agent-proposed close will ask the same question an auditor asks a human bookkeeper: why did you match these two records? A per-client, per-run sandbox gives you that answer for free, because the run is a discrete object rather than a slice of a shared process's log stream. Every match the agent proposed, every tool call it made, and the exact transaction and invoice sets it saw are scoped to one run, one client, one period — attributable without a grep across everyone else's closes.

• Reproducibility — pin the sandbox template/snapshot generation used for each close in the run record, the same way you'd pin a rating engine's environment, so re-running a disputed match starts from the same tool versions and matching logic.
• Least privilege by construction — a scoped, short-lived, read-only credential per run means a review of "what could this agent have touched" has a short, factual answer instead of "whatever the shared integration key could reach."
• Human-in-the-loop by default — the sandbox proposes matches and drafts entries; a trusted orchestrator (or a person) approves and commits them to the ledger, exactly like the billing pattern of computing in the sandbox and writing in the trusted process.
• Clean blast radius — if one client's close goes sideways (a malformed export, a matching bug, a runaway loop), it stays contained to that client's guest and that client's period. Every other client's close that day is unaffected.

Shared agent process vs container-per-close vs microVM-per-close

• Cross-client matching risk — Shared process: multiple clients' bank feeds and invoices can sit in the same context window across a session, and a fuzzy matcher will happily find a plausible cross-client match. Container per close: process isolation helps, but a shared credential vault and shared filesystem mounts often leak through anyway. MicroVM per close: only one client's records are ever present in the guest, so there's nothing else to match against.
• Credential exposure — Shared process: typically holds one broad integration key across many clients' accounts. Container: usually scoped per job, but still a shared kernel and shared secrets store. MicroVM: a scoped, short-lived, read-only token per run that dies with the sandbox.
• Agent-written code risk — Shared process: agent-generated matching scripts run with the same filesystem and network access as everything else in that process. Container: cgroup limits help but the kernel is shared. MicroVM: a real kernel boundary around code the agent wrote moments ago against real financial data.
• Auditability — Shared process: reconstructing what one client's close saw means reading interleaved logs from every close that ran nearby. Container: better, but ephemeral containers rarely pin a reproducible environment. MicroVM: one run, one snapshot generation, one attributable log — a genuine replay is possible.
• Cost of isolation — Shared process: near zero per close, which is why most tools start here and stay there long after it stops being appropriate. MicroVM: on PandaStack a create is 179ms p50 (~203ms p99) because every create restores a baked snapshot rather than cold-booting; a fraction of a second is not the expensive part of closing the books.

The summary

A reconciliation agent's worst failure isn't a crash, it's a confident, plausible, wrong match between two clients' records that nobody notices until an auditor does. The fix isn't a stricter prompt telling the agent to stay in its lane — it's making the wrong match structurally impossible by ensuring the process proposing it never has a second client's data or credentials in scope. One microVM per client per close does that, and hands you a reproducible, attributable audit trail as a side effect of the same architecture.