Security
Your books never leave your control.
The first question every leader asks about AI is the right one: where does my data go, and who can change what? This page is the answer — the actual controls, the actual reviews, and the things we refuse to do no matter who asks.
Why this page exists
Most firms ask you to trust the AI. We’d rather show you the controls.
“AI bookkeeping” usually means a language model is handed your general ledger and trusted to behave. That is a reasonable thing to be nervous about, and we are nervous about it too — which is why we did not build it that way. Everything below is a control we actually run, not a policy we wrote down.
There is a second risk that nobody sells against, and we see it more often than we see a security incident: automation pointed at a process that was already wrong just produces wrong numbers faster. Speed is not the win. Being right, month after month, is — and that is an accounting problem before it is a software one. It is why the work starts with an accountant understanding your close, not an engineer automating whatever is currently happening.
The controls
Ten controls between an AI and your general ledger.
They fall into two groups. The first limits what can reach your data at all. The second catches a mistake before it reaches your books — because the failures that hurt a finance function are not the loud ones.
Group one — what can reach your data
Your data is scoped down before a model ever sees it
The narrower the input, the smaller the exposure — and the better the automation works. So we cut the data down to what the job actually needs, and strip the rest.
- A job that reconciles daily sales gets daily sales — not your customer list
- Personal names are redacted where the work does not depend on them, by code, not by good intentions
A stolen password is not enough to do anything
Credentials are held by the systems that use them, not by the people who operate them — so the blast radius of any one person being compromised is small by design.
- Automated jobs run under their own service identity and use credentials that the operators themselves cannot read
- The AI is never given a password. It does not hold your credentials, and it cannot retrieve them — the system supplies them to the job, not to the model
- Administrative rights are held by administrators only, not handed out for convenience
- Anything that moves money stays behind multi-factor authentication, so a leaked password on its own cannot send funds
- Our automation never bypasses an MFA prompt. It stops and asks a named person for the code, and waits
For the sensitive work, we run our own AI on our own hardware
We operate our own machines running our own models. When work is better kept entirely in-house, it runs there — the processing happens on hardware we own, on our own private network, and the data does not leave it.
- No third party is involved in that processing at all
- It means we are never forced to choose between doing the work and sending your data somewhere
- Where we use Anthropic’s models, we do so under their commercial agreement, which does not permit your data to be used to train their models
We control what our software is built out of
Most real-world breaches arrive through something a developer installed without reading. Our rules about third-party code are deliberately stricter than the industry norm.
- Every dependency is pinned to an exact version — nothing floats, so nothing changes underneath us without a person deciding it should
- Nothing that updates itself at runtime is allowed inside a scheduled job
- We never install a package that requires our client credentials in order to function
- Licensing is checked automatically on every change, and an unclassified package fails closed rather than being waved through
Group two — what catches a mistake
If the data cannot be trusted, the job stops
This is the one we would put first if we could only keep one. The dangerous failure in automated accounting is not the crash — it is the run that half-worked, wrote a zero, and reported success.
- A job that cannot reach its source data never writes a zero, a blank, or a partial result. It fails, loudly, and names what went wrong
- No job is allowed to finish successfully after skipping a safety check
- A delivery failure is never quietly downgraded to a warning nobody reads
- Aborting is always better than producing a wrong number. That is a rule in our codebase, not a preference
A human gate on anything that posts
Our automation prepares work. A person releases it. This is a deliberate design decision, and we turned down the easier architecture to keep it.
- Invoices are created in your accounting system but deliberately left unposted — a person reviews and posts the batch
- Journal entry approvals happen outside the accounting system, by a named person, before anything is created — behind password protection and authentication, so an approval can be traced to whoever actually gave it
- No automation of ours sends money, moves a payment, or changes a bank instruction. Ever
Change control on everything that touches your books
No one edits a live system by hand — not us, not an automation, not in an emergency. Every change to the code that touches your numbers is written up, reviewed against its stated intent, and recorded before it is allowed to run.
- Every change carries a plain-English statement of what it is meant to do, so a reviewer can check it did that and nothing else
- Changes to the code paths that move money require a second person’s approval before they can be merged
- If something goes wrong we can name the exact change, who approved it, and when — and reverse it
Every change is attacked by a second, independent AI
We use Anthropic’s Claude models to write our automation — and then we point a different one at the result and tell it to find what is wrong. Findings are not taken at face value either: each one is handed to a further reviewer whose only job is to prove it wrong.
- Only findings that survive the attempt to refute them get fixed
- Every round is logged with its counts — one recent review raised 18 issues, confirmed 8 and threw out 9 as incorrect. The 8 were then fixed
- Findings and their outcomes are recorded, so a review is an event with a result rather than a reassurance
Penetration testing, on a standing schedule
Reviewing new code is the easy half. The harder half is the code written before the review process existed, which is exactly where problems sit undisturbed.
- New code is security-reviewed as it ships
- A standing sweep works backwards through older code, section by section, until all of it has been covered
- Dependencies are checked for licence and supply-chain problems automatically, on every change
We rehearse on a copy before we touch anything live
New automation is built and run against a sandbox or development environment first. Your live system is the last place a change runs, not the first.
- Work is proven in a non-production environment before it is pointed at anything real
- We confirm a working backup is in place before making a change that could need one
- The first live run of anything new is watched by a person, not left to a schedule
Where your data lives
On your servers, for as long as the work needs it. Then gone.
This is the question every security questionnaire asks, so here is the answer in plain terms.
It stays on infrastructure you own
We work inside your environment. The servers your accounting data sits on are yours — your systems, your accounts, your control. We are not asking you to move your books onto a platform of ours in order to be our client.
We hold it only while the work needs it
Where a piece of work requires a working copy, we use it, we finish, and we remove it. Holding onto data after the job is done creates risk for you and value for nobody, so we do not do it.
It is deleted on request, or when it is no longer needed
Whichever comes first. You do not have to wait for the end of an engagement to ask, and you do not have to ask for it to happen.
If your policy requires something more specific than this — a named retention period, a written deletion confirmation, a particular jurisdiction — ask. It is a reasonable thing to want in writing, and it is a much easier conversation at the start than in month three.
Four things we will not do, whoever asks.
Some of these would make us faster or cheaper. We have declined them on purpose, and we will decline them for you too — including on the day you would rather we didn’t.
In practice
How a change actually reaches your books.
Four stages, in this order, every time. No path around them.
Proposed
The change is written up with its intent in plain English — what it should do, what it should not touch, and what would prove it worked. Nothing is changed in a live system.
Written
Only then is it built. The code is written against that statement of intent, and against a test that fails until the change actually works — so “done” is something demonstrated rather than declared.
Attacked
A second, independent AI reviews the change against that stated intent and tries to break it, and a penetration-test pass looks for security problems. Findings are then challenged by a third reviewer trying to refute them. What survives gets fixed.
Approved by a person
A named human approves the change before it can run, and a named human releases anything that posts to your books. A CPA owns the result.
The architecture
AI orchestrates. Code computes. A CPA signs off.
This is the whole design in one line, and every control on this page exists to keep it true. The AI is doing the reading and the sorting — the parts it is genuinely good at. The arithmetic is done by code that can be checked. The judgement belongs to a person who is licensed to exercise it.
Every dollar in your books is arithmetic you can audit — not a guess.
Accountability
The same person holds the security credential and the accounting licence.
Our Managing Partner is a CPA and holds the CISSP — the leading information-security certification. That combination is the reason this page can be specific. Security controls designed by someone who has never closed a set of books tend to be unusable; automation built by someone who has never had to defend a system tends to be unsafe. You do not have to trade one for the other, and you should not have to explain your controls to your accountant.
We also carry cyber liability and errors & omissions insurance, which procurement teams usually ask about and which we are glad to evidence.
And what we don’t claim
We are not SOC 2 certified, and we would rather say so than let you assume otherwise. If a formal attestation is something you need, tell us early — it is a fair thing to require, and an easier conversation in the first meeting than the fifth.
Everything else on this page is how we actually work. Ask us to walk you through any of it.
Straight answers
The questions we actually get asked.
Is my data used to train an AI model?
No. We use Anthropic’s models under their commercial agreement, which does not permit your data to be used to train their models. And for the most sensitive work we do not rely on that agreement at all — it runs on our own models, on our own hardware, on our own network, where no third party is involved in the first place.
What happens if the AI gets something wrong?
It gets caught before it reaches your books, because nothing posts without a person releasing it and a CPA owning the result. And if a change ever did cause a problem, change control means we can name the exact change, reverse it, and tell you what it touched — which is the part most firms cannot do.
Who at your firm can see our books?
Only the people working your engagement, and access is scoped to what the work requires. We work inside your systems rather than moving your books onto ours, so the underlying servers stay yours. Credentials live in a password manager, never in a document, a spreadsheet, or a message, and payment instructions are held separately from everything else.
Can you work inside our security policy?
Usually, yes — and we would rather you send it than not. We already work under client-specific data rules that differ by engagement, including cases where a client’s data is approved for some of our systems and not others. If your policy rules something out, we will tell you plainly what that changes about the scope and the price rather than quietly working around it.
Send us your security questionnaire.
Most firms dread that email. We would genuinely rather answer it up front than discover in month three that we cannot. Bring the hard questions.