A finance agent is most useful when it can see widely and change narrowly. Broad read access, across the ledger, sub-ledgers, contracts and bank data, lets it explain variances, match transactions and spot errors. Write access should be confined to the few capabilities it has proven. The gap is deliberate, not an oversight.
Why does analysis need wide visibility?
Most useful finance work involves connecting things. Explaining why a cost line moved means looking at the ledger, the purchase orders behind it, the contracts that set prices and perhaps the payroll data for the team involved. Reconciling a balance means seeing both sides. Spotting a duplicate invoice means seeing all invoices from that supplier, not just this month's.
An agent with narrow read access gives narrow answers. Asked why marketing spend rose, an agent that can see only the general ledger can say which accounts moved. One that can also read purchase orders and contracts can say a new agency was engaged at a higher rate. The second answer is the one a management accountant needs.
The practical steps for this are covered in how to give an AI agent read access to your general ledger. The principle is that reading is depth 1, the lowest-risk capability an agent has, and it is where most of the agent's analytical value comes from.
Why should write access stay narrow?
Because every write is a change to the firm's books, and changes are where harm happens. A wrong journal misstates the accounts. A wrong supplier record misdirects payments. A wrong payment moves money that may not come back. The potential damage from a single bad write is far larger than from a single bad read.
Write access should therefore follow evidence. An agent earns the right to change something only after it has shown, on the firm's own cases, that it does so correctly. That evidence is built at depth 2, where the agent drafts and a person posts. The reasoning is set out in finance agents should draft journals before they post them.
Even then, write access should be granted capability by capability. An agent certified to post recurring depreciation journals has not shown it can post accruals, let alone change supplier records.
What does the asymmetry look like?
An illustrative mapping for a general-purpose finance agent in its early months:
| System | Read | Write |
|---|---|---|
| General ledger | Full, all entities and periods it needs | Draft journals only (depth 2) |
| Accounts payable sub-ledger | Full | None; may draft invoice coding |
| Supplier master data | Full | None |
| Purchase orders and contracts | Full | None |
| Bank feeds and statements | Full | None |
| Bank accounts and payment initiation | Balances only | None |
| Payroll | Aggregated by cost centre | None |
| Fixed asset register | Full | Draft additions and disposals (depth 2) |
The table shows the shape, not a rule. Each firm will draw the lines differently. What should be common is that the read column is broad and the write column is short, mostly drafts.
Bank access deserves a specific note. Whether a finance agent should have access to the company's bank accounts depends on what "access" means. Reading balances and transactions is useful for reconciliation. Initiating payments is depth 4, which should be granted rarely and only after extensive evidence.
Isn't wide read access a risk too?
Yes, and it should not be dismissed. Read access exposes information. Payroll data reveals salaries. Contracts contain commercially sensitive terms. Customer ledgers may contain personal data. An agent that can read everything can, in principle, disclose anything, whether through a mistake, a misdirected report or an attacker's prompt.
The answer is to be deliberate about sensitive data, not to restrict reading generally. Useful techniques include aggregating payroll to cost-centre level unless individual detail is needed, masking personal identifiers where the analysis does not need them, and making sure the agent's outputs go only to people entitled to see the underlying data. Data protection principles such as data minimisation still apply: read what the purpose needs, not everything that exists.
There is a useful test. For each data source, ask whether the agent's analysis would be noticeably worse without it. If not, leave it out.
What about orchestrators and sub-agents?
Some finance setups use an orchestrating agent that delegates tasks to specialised sub-agents: one for reconciliations, one for accruals, one for commentary. The asymmetry should hold at every level. A sub-agent should receive the read access its task needs and only the write access it has itself earned.
Crucially, an orchestrator cannot hand out authority it does not have, and should not pass on its own authority wholesale. The question of whether an orchestrator agent can give a sub-agent more authority than it has has a clear answer: no. Each sub-agent's actions meet their own bounds, and the lowest bound wins.
How do you see whether the balance is right?
Watch what the agent tries to do. If it frequently attempts writes it is not permitted, and they are refused or held, the held and refused verdicts show where the boundary is pinching. Some of those will be signs that the agent is ready for more depth in a particular capability; others will show the agent drifting outside its role. As the argument goes, the held queue tells you more than any dashboard.
Watch, too, for the opposite. If an agent has write access it never uses, remove it. Unused authority is risk with no benefit.
Where Pryme fits
In Pryme, read and write are separate capabilities with separate depths, so an agent can read the ledger at depth 1 while drafting journals at depth 2 and posting nothing. Each write is checked against role scope, certificate, sources, the customer's limits and platform guardrails at the moment of action. This supports AI agents for finance: books you can audit.
Questions people ask
Should read access be certified like write access?
Reading is depth 1 and carries less risk, but the agent's answers based on what it reads should still be tested for grounding and accuracy before people rely on them.
Can an agent read data from other group entities?
If its analysis needs it and the firm is entitled to share it across entities, yes. Intercompany work usually requires it. Check data-sharing rules between entities first.
How often should access be reviewed?
At every recertification, and whenever the agent's role changes. Access reviews for agents should sit alongside the firm's normal user access reviews.