Tuesday 25 August 2026  •  By Timothy, CPA — Managing Director, Professional Financelink (PFL)

"Can We Connect Our Accounting Data?" — The Four Questions to Ask Before You Say Yes

The request arrives as one line in an email and looks like an IT formality. It is a standing grant of access, and the protocol underneath it does not carry the safeguards most approvers assume it does.

Yesterday's post was about reach — the fact that financial data is becoming readable from tools your access review was never written to cover. This one is about the moment that actually decides it: someone asks you to approve a connection, and you have about five minutes to work out what you're agreeing to.

Approvals framed this way are routinely assessed on the wrong criterion. The question asked is "is this vendor reputable?" The vendor is usually fine. The exposure comes from the shape of the connection, not the name on it.

What the protocol does and doesn't give you

Most of these connections now run on the Model Context Protocol, or something structured like it. It is worth knowing what that standard actually specifies, because the assumptions people bring to it are generous.

On 20 May this year the United States National Security Agency published a cybersecurity information sheet titled Model Context Protocol: Security Design Considerations for AI-Driven Automation. Its central observation is that adoption has run ahead of the protocol's security model, which was released in a flexible and underspecified form — freedom for implementers, ambiguity for everyone relying on it. Three points from it translate directly into a finance context.

First, the protocol does not define how a session maps to a verifiable identity. Second, authentication is optional rather than required. Third, role-based access control is not part of the protocol at all. Every one of those is something a finance leader would assume was built in — because in the accounting platform itself, all three are.

The NSA's practical conclusion is that organisations should not rely on the security suggestions in the protocol's own documentation, and should enforce least-privilege tokens for every action and tool.

Not in the protocol Role-based access control. Authentication is optional, and session-to-identity mapping is undefined. These are the controls you'd assume were built in — they have to be added by whoever deploys it.

May 2026 The NSA published dedicated MCP security design guidance, flagging uncontrolled automated actions and the absence of input screening between connected systems.

To be fair to the platforms, several are adding those controls themselves. Xero's recent connector work, for example, is explicitly opt-in per permission with reports held read-only. Established platforms also layer their own OAuth scopes, token expiry and permission models over the top, so a gap in the specification is not automatically a gap in the product in front of you. But those are vendor choices sitting on top of the protocol, not properties of the protocol — which is exactly why the question has to be asked connection by connection rather than answered once.

Question one: what is the scope, expressed as data rather than as a product name?

"Access to Xero" is not a scope. "All transactions, contacts and payroll records in the production organisation, read and write" is a scope. The difference is that the second can be argued with.

The specific trap in a small or mid-sized finance function is that payroll usually lives inside the same platform as everything else. A connection scoped at the organisation level therefore includes individual salaries by default, not by anyone's decision. If the tool is being connected to help with debtors, the scope should say debtors.

Ask for the scope in writing before approval, and ask whether narrower is possible. In most cases it is, and nobody offers it unprompted because the default is easier to configure.

Question two: whose identity does it run as?

This is the question people skip, and it's the one that does the most damage.

A connection authorised under a named person's credentials inherits that person's permissions — which means a connection set up by the finance manager quietly carries finance-manager reach for everyone who subsequently uses the tool. It also means the audit trail attributes everything the connection does to that individual, whether or not they were anywhere near it.

The follow-on question matters just as much: what happens when that person leaves? If the answer is that the connection keeps working, then your offboarding process has a hole in it that no exit checklist will find, because the leaver's name isn't on the tool — it's on a token issued eighteen months ago.

Question three: what is retained, and where?

Two distinct sub-questions get collapsed into one here, and they have different answers.

The first is whether data retrieved through the connection is retained by the receiving tool at all — in a conversation history, a cache, an index. The second is whether it is used to train models. A vendor can honestly say it does not train on your data while still retaining it for months in a log you have no visibility of.

For an organisation handling participant, client or employee information, both answers need to be on paper. Australian Privacy Principle 8 obligations don't stop applying because the transfer happened through a connector rather than a file upload, and the fact that the destination is an AI assistant rather than a spreadsheet doesn't change the character of the disclosure.

The standing caution, restated: before any payroll, participant or client data reaches an AI tool, confirm in writing whether the vendor retains customer inputs for model training. The safest posture is a tool where inputs are not retained for training at all — and where you can point to the contractual term that says so, rather than to a marketing page. The term is a floor, not a substitute — the OAIC's guidance is to minimise the personal information entering any AI product in the first place, and to keep it out of publicly available tools altogether.

Question four: what gets logged, and can you read it?

Every finance system keeps an audit log. The question is whether the connection's activity appears in it in a form that means anything.

The honest reason this matters more than it did with older integrations: traffic arriving through a legitimate connector looks like ordinary API traffic. If a token were misused, the requests would carry a valid credential, a recognised application name and a normal request pattern. There is no anomaly to spot unless you have a record detailed enough to show what was retrieved, when, and at whose instruction.

So ask two things. Does the log record what data was accessed, or only that the application connected? And can someone in your organisation actually retrieve that log without going through the vendor? A log you can only obtain by raising a support ticket is not a control you can rely on during an incident.

Making this a five-minute decision, not a project

None of this needs to become a governance exercise that stalls useful work. Write the four questions into a short standing note and require them to be answered before any connection to financial data is switched on. Scope in data terms. Identity, including what happens on departure. Retention, split between storage and training. Logging, including who can read it.

If a request comes back with all four answered, approve it and move on — most will. If it comes back with one blank, that blank is the whole conversation, and you've found it in five minutes rather than during an audit.

One more thing worth building in from the start: a review date. These connections are set up once and then never revisited, which is how you end up with the token issued to a former bookkeeper. Six months is a reasonable interval, and it takes ten minutes if the note from the original approval still exists.

Related reading: In July we set out the data-governance policy layer — what an organisation should write down about AI use before it starts. See our AI data governance checklist. That post is the policy. This one is the individual decision the policy has to survive contact with.

Who approves connections to your financial data?

If the answer is whoever happened to be asked, the scope of your ledger access is being set by convenience. PFL provides senior-level outsourced finance, management reporting, and AI automation for Australian NFP, NDIS, and SME organisations.

Talk to PFL →

Timothy, CPA is Managing Director of Professional Financelink (PFL), providing senior-level outsourced finance, management reporting, and AI automation for Australian NFP, NDIS, and SME organisations. 20+ years in finance leadership across NFP, NDIS and SME.

Sources
NSA Releases Security Design Considerations for AI-Driven Automation Leveraging the Model Context Protocol — National Security Agency, 20 May 2026
CSI: Model Context Protocol (MCP) — Security Design Considerations for AI-Driven Automation (full document, PDF)
APP 8 — Cross-border disclosure of personal information — Office of the Australian Information Commissioner
Voluntary AI Safety Standard — Australian Government Department of Industry, Science and Resources
Customizing their way: the rise of the builders — Xero, 20 August 2026

Tomorrow: most organisations can't tell you what their AI deployment is worth — and the reason is that the measurement had to be built two weeks before the pilot started.