Security & confidentiality
Where your client data actually goes
Most advice about “AI and client data” argues about one thing: a person pasting a tax return into a chatbox. That's a real question — but it's not how OpenAccountants works. Our skills run inside the AI agent you already control. The architecture changes the threat model, so let's be precise about it — including the parts that are genuinely your job, not ours.
You're not handing us the data. That's the point.
When you adopt QuickBooks Online, Thomson Reuters, or a cloud portal, your client's data lives on that vendor's servers. The whole security conversation is about trusting them to hold it.
OpenAccountants is a different shape. Our skills are files, not a service. They're reference rules — rates, thresholds, the relevant law — that load into your own AI agent. Your client's numbers are read and computed by that agent, under your account and your controls. In the normal flow, the client data never has to reach us at all.
So the honest claim isn't “trust our servers.” It's “the sensitive data doesn't come to our servers in the first place.”
The architecture
Three facts, all checkable in the code
Skills are local markdown
A skill is a tax recipe — “if turnover exceeds the threshold, register; here’s the form.” It lives on your machine or in your agent's memory. It contains rules, never client names, amounts, or scenarios. No telemetry, no callbacks home. You can open one in a text editor and read every line.
Our server hands out reference data, not client data
When your agent calls OpenAccountants, it pulls back public facts — tax rates, brackets, verifier names, skill content. It is read-only. Nothing about your client's situation is sent up to get an answer back.
Computation happens inside your agent
Your client's bank statement or scenario stays in the agent's context, on your side. The skill's rules are applied there. The output is a review-ready working paper on your machine — we never see the inputs or the result.
The one place data leaves your agent
When you ask a human to sign off
There's exactly one flow where client data crosses to our side: when you explicitly request an accountant review. At that point the scenario, working paper, and your contact details are sent to us so a named, licensed professional can review it. We won't pretend otherwise — that data does land on our servers.
Here's how it's held:
- It's only ever sent when you call the review tool — never silently, never as a side effect of computing.
- Encrypted in transit (HTTPS) and at rest (managed Postgres).
- Locked down by row-level security: not public, not readable by other users. Only the service role and the accountant assigned to your jurisdiction can see it.
- You can request deletion at any time.
If you never use accountant review, no client data ever reaches us.
What about usage analytics?
We record coarse usage metadata so we know which jurisdictions get used — tool name, jurisdiction code, a session id. The caller's IP is stored only as an irreversible salted hash, so we can count unique callers without being able to tie it back to a person. No names, no emails, no scenario content, no transaction figures. These metadata rows are deleted after 180 days.
The risks we won't gloss over
Where the real attack surface is
“Same servers, same standards” is the line a skeptical accountant correctly smells as marketing. The infrastructure isn't where the genuine risk lives. These are:
Prompt injection & poisoned skills
A skill is instructions your agent will follow. A malicious or tampered skill is therefore an attack — hidden instructions that could try to redirect the agent. This is the genuinely new risk, and it's not overblown. Our answer is the verification model: skills are open and inspectable, accountant-reviewed skills carry a Q1 (accountant-verified) badge, and you should treat any skill the way you'd treat any code — load it from a source you trust. We give you a vetted source; we don't ask you to run arbitrary files blindly.
The agentic surface (browsing, file access, computer use)
The moment an agent can browse the web, read your whole drive, or run code, you've widened the attack surface well beyond pasting text. That's an endpoint-security and agent-configuration question on your side: keep sensitive files in cloud storage and connect rather than bulk-download, sandbox computer use, force SSO + MFA. None of this is specific to us — but a firm that turns on full file access on a partner's laptop and changes nothing is taking real risk.
Output reliability is a liability, not a data leak
The figure most likely to bite you isn't a breach — it's a wrong number. AI hallucinates thresholds, applies last year's rates, invents citations. Our skills exist precisely to reduce that by feeding cited rules instead of guesses, and to produce a working paper a human reviews. But the return still carries your professional liability. Keep a human in the loop. We reduce the risk; we don't eliminate it.
The setting that matters most
Your plan choice is a security decision
Whatever AI agent you run our skills in, the single biggest control is which tier of it you're on. Free and personal plans have no contractual safeguards behind them. Business and enterprise tiers (Claude for Work / Team / Enterprise, and the equivalents from other providers) typically give you what a firm actually needs:
- A contractual guarantee your inputs are not used to train the model — and double-check the “improve the model” toggle is off.
- SOC 2, encryption in transit and at rest, admin controls, SSO.
- Defined (or zero) data-retention terms and audit logs.
On that footing, the confidentiality risk of working with client data in a business-tier agent is roughly the same vendor-risk question you already answer for QuickBooks or your tax software — not a new category of law. And because our skills keep the heavy data on your side, you're starting from a stronger position than a firm pasting raw returns into a chatbox.
Make it defensible
What a careful firm does
Vet the agent like any vendor
Use the business/enterprise tier, confirm training is off, review the SOC 2 and retention terms. Same due diligence you run on any critical tool.
Load skills from a source you trust
Prefer accountant-verified (Q1) skills, inspect what you load, and don't run untrusted markdown any more than you'd run untrusted code.
Keep a human in the loop
Every output is a draft working paper. A professional reviews and signs off. Document a clear review process — a concise one-page AI usage policy goes a long way.
Update your paperwork
Address AI use explicitly in your WISP and engagement letters. A lot of the felt insecurity is paperwork lag, not a technical fact.
The blunt version:the confidentiality fear around business-tier AI is largely a vendor-due-diligence question dressed up as an existential one — and our architecture removes the biggest part of it by keeping client data in your environment. The risks worth your attention are prompt injection, the agentic file/browser surface, and plain wrong output. We're honest about all three because pretending they don't exist is exactly how you'd end up less defensible, not more.
This page describes how the product handles data; it isn't legal advice. Your firm's obligations under GLBA, the FTC Safeguards Rule, and your professional body remain yours.