Is it safe to give AI access to my books and bank feeds?

Short answer

It’s safe when access is governed and every action is logged. The right setup gives read-and-draft access, never silent write access: the system proposes a correction, a human approves it, and every action lands in a permanent run log you can audit. On one build, a closed fiscal year was never touched and not a single entry posted without explicit owner approval.

This is the question people ask us privately and almost nobody in our industry answers in public. So here’s the whole thing, including the parts that aren’t reassuring.

The risk isn’t the one you’re picturing

Most people imagine the danger as theft — AI moving money somewhere. That’s not the realistic failure. Read-only and draft-level integrations don’t move money, and no reputable build gives a system the ability to originate a payment.

The realistic danger is quieter and more expensive: a system that posts entries nobody reviewed. An AI that miscategorizes eight months of transactions with total confidence doesn’t set off any alarms. It produces books that look finished and are wrong — and you find out during a review, a loan application, or a tax filing, which are the three worst times to find out.

That failure has nothing to do with AI being untrustworthy in some abstract sense. It has to do with whether anybody built a gate.

What a governed setup actually looks like

Four controls. If a vendor can’t describe all four in plain language, that’s your answer about whether to hand them credentials.

Scoped access

The system gets access to exactly the accounts and periods it needs, and nothing else. Closed fiscal years are locked out entirely. Payroll and banking origination stay outside its reach as a matter of architecture, not policy — it shouldn’t be a rule it’s asked to follow, it should be access it doesn’t have.

Draft, don’t post

The system prepares the entry. It does not commit it. This single design choice removes most of the risk in the category, and it’s the one most often skipped because it’s slower to build and less impressive in a demo.

A human approval gate

A person with actual authority reviews and approves. Not a rubber stamp buried in a settings menu — a real review step where the proposed change is legible and rejecting it is as easy as accepting it.

A permanent audit log

Every query, every draft, every approval, every posting — recorded, timestamped, and reviewable after the fact. If something is wrong six months from now, you can trace exactly what happened and who approved it. This is also what makes the arrangement defensible to a lender, an accountant, or an auditor.

What we actually did

We built an AI controller for a closely held construction and design group — three legal entities, roughly 199 ledger accounts, twelve live bank and card feeds, six months behind on reconciliation.

It had governed read-and-draft access. It queried the ledger, traced discrepancies and drafted corrections across thousands of transaction lines. It found roughly $110,000 in phantom cash and cleared $27,388.88 of stale prior-period payables — in a single batch that the owner approved before anything posted.

The results that matter for this question aren’t the dollar figures. They’re these: zero unapproved entries. Nothing in the closed fiscal year touched. Every action in a permanent, auditable run log.

That’s not a happy accident. It’s what the system was built to do, and it’s the only configuration we’ll deploy against a live ledger.

Questions to ask any vendor before you hand over credentials

Can it post without a human? If yes, walk — or at minimum understand exactly which categories it can post unattended and why.
What can it not reach? You want a specific list: payroll, banking origination, closed periods. “It only does what we tell it” is not an access control.
Show me the log. Ask to see a real run log from another deployment. If there isn’t one, there isn’t an audit trail.
Whose credentials is it using? It should have its own scoped access under your account — not a staff member’s login, and never a shared password.
What happens on the day we stop? Access should be revocable by you, in minutes, without calling anyone.
Where does our data go, and does it train anything? Get the answer in writing.

Where your data actually goes

Worth understanding, because it’s the part people assume rather than ask about.

An AI employee working on your ledger sends the specific records it needs to a commercial AI model to be processed, then brings the result back. It is not uploading your books somewhere wholesale, and it is not handing your financials to a company that keeps them. But data does leave your building, the same way it does when you use cloud accounting software, a payroll processor or an online backup.

What matters is the terms attached. You want a business-tier arrangement where your data is not used to train models, is retained for a limited window or not at all, and is covered by an agreement you can actually read. Those terms exist and they’re the ones we build on — but you should ask any vendor to name the providers they use and show you the data-handling terms in writing rather than describing them.

If you operate under a contractual or regulatory obligation that restricts where data can be processed — some public-sector and institutional work does — say so before anyone scopes the build, because it changes the architecture rather than the paperwork.

The standard we hold to here came out of high-compliance software work. Our COO’s background is in environments where access is treated as a liability until it’s proven necessary, scoped and logged, and where nothing ships without review. That’s the bar we apply to a contractor’s ledger, and it’s a higher bar than this industry generally uses.

Straight talk: what can still go wrong

An approval gate only works if someone actually reads. The most likely failure in a well-built system is a human clicking approve on a batch they didn’t examine. We build the review step to be legible for exactly this reason, but we can’t make anybody read it.

Bad source data produces confident bad drafts. If the underlying records are a mess, the system will surface the mess — which is useful — but somebody still has to decide what’s true. That’s a person’s job and it stays a person’s job.

Integrations break quietly. A feed can change on the vendor’s end and stop delivering without announcing itself. Monitoring for that is part of what a monthly operating fee should cover, and you should ask whether it does.