Connecting AI Agents to Your Books with MCP and OAuth 2.1

A growing number of our clients — and their accountants — already work alongside an AI assistant. It is natural to want that assistant to see the books: "What did I spend on materials this quarter?", "Which invoices are still unpaid?", "Draft me a summary for the bank." The question is not whether people will connect AI agents to financial data; they will. The question is whether the connection is engineered like an integration or like a leak.

This article explains how external AI agents connect to Elizabeth Bookkeeping, and the boundaries we hold regardless of how capable the agent on the other end claims to be.

MCP: tools, not database access

We expose the platform to external agents through the Model Context Protocol (MCP), an open standard for connecting AI systems to applications. The design choice that matters most is what MCP connections are made of: named tools with defined inputs and outputs, not a raw query surface.

An agent connected to our MCP server does not get a database connection, an export of your ledger, or a browsing session in your account. It gets a specific vocabulary of operations we have chosen to offer — reporting queries, invoice status lookups, draft proposals — each with a narrow contract. Anything not expressed as a tool simply does not exist from the agent's point of view. That inversion is the foundation of everything else: instead of asking "what can we block?", the surface is built from "what have we explicitly allowed?"

OAuth 2.1: grants you make, grants you can end

Authentication uses OAuth 2.1, the current revision of the standard that consolidates hard-won security practice — including PKCE and the retirement of the weaker flows of earlier versions.

What this means in practice, without the alphabet soup:

• No shared passwords. You never type your Elizabeth Bookkeeping credentials into another AI product, and no external agent ever holds them. Authorisation happens with us directly, and the agent receives only a token.
• Tokens are scoped. Each token carries an explicit list of what it permits — and nothing else. A token issued for reporting cannot call drafting tools, no matter how politely the agent asks.
• Grants are visible and revocable. You can see which agents are connected with which scopes, and disconnect any of them. Revocation cuts access without a support ticket or a password change.

Least privilege, applied to software that can be talked into things

Least privilege is an old principle with new urgency. An AI agent is a piece of software whose behaviour is shaped by text it reads — which means it can be manipulated by text it reads. You should assume any connected agent might one day act oddly, whether through a model failure or a prompt-injection attempt, and size its permissions for that day.

So scopes are granular and default-minimal. An assistant that answers "how is the quarter going?" needs read access to reports — so that is all it gets. The capability boundary that matters most, though, is this one:

No external agent can post to your ledger. Ever. The most a fully-scoped agent can do on the write side is propose drafts — and a draft proposed by an external agent enters exactly the same pipeline as a draft from our own AI: AgentLedger validates it mechanically, and a human approves, corrects, or queries it per your review policy. AI drafts. AgentLedger validates. People approve — the rule does not soften because the drafting AI belongs to someone else. If anything, it matters more.

Every call, on the record

Each MCP call is logged: which agent, under which token and scopes, invoked which tool, when, and touching what. This is the same audit-trail discipline we apply to our own AI's work, extended to visitors.

The log serves three purposes. Operationally, it answers "what has this agent actually been doing?" — worth reading before renewing any grant. Forensically, if a token is ever compromised, the blast radius is knowable: bounded by scope in what it could do, and enumerable from the log in what it did. And contractually, when an accountant or auditor asks who has had access to the books, "here is the list, with timestamps" is an answer rather than an investigation.

Failure thinking, briefly

Security claims are cheap; failure analysis is where the design shows. A leaked token is bounded by its scopes, its lifetime, and one-click revocation. A manipulated agent can read what its scopes allow and propose drafts that a validator and a human will inspect — unpleasant, but not an unattended path to corrupted books or moved money, because no such path is exposed as a tool at all. A buggy agent hammering the API is visible in the call log and cut off by revoking one grant, not by rotating your credentials.

None of this makes connecting an agent risk-free, and we will not pretend otherwise — you are extending read access to financial data, and that decision deserves the same thought as granting it to a person. Our job is to make the grant narrow, visible, revocable, and logged, so it is a decision you stay in control of. The NCSC's guidelines for secure AI system development make a similar point from the builder's side: assume the AI component can misbehave, and design the surrounding system so that misbehaviour is contained.

Check eligibility / Ask for Details