Which AI Tools Can Touch Your ERP? The Approved-Tool List and Permission Review for Odoo 20 and MYOB Acumatica

An approved-tool list names the AI tools staff may use with company data, and a permission review checks, on a fixed date, what each can still reach in your ERP. On Odoo 20 that means every MCP-scope API key and every server action marked Available in MCP; on MYOB Acumatica, every integration user, connected application and role. We review write access monthly and the rest quarterly.

At a glance

• Who it is for: owners, CFOs, finance managers and whoever holds the administrator login in an Australian business of roughly 20 to 200 staff that runs Odoo or MYOB Acumatica and already has assistants, agents or AI features touching it.
• Problem it solves: AI access accumulates: a key issued for one pilot, a skill ticked during a demo, an integration account that outlived the integration. Nobody decided it should still be there; nobody checked.
• Platforms: Odoo 19 and Odoo 20 Enterprise (API keys, the Odoo 20 MCP server, agents and their skills), MYOB Acumatica (users, user types, roles, connected applications and AI Automation), and whatever AI tools your staff use on their own laptops.
• What the list records: each tool, the data classes it may be given, where its provider says the data goes and whether it may be retained or used for training, who approved it, who may issue it an ERP key or token, and the date you last read the terms.
• What the review checks: every live key or token, its owner, expiry and scope; every tool, skill or automation that can write; every account used by an integration and the roles on it; and whether the logs still show what each one did.
• Approval gate: the owner of each key or agent signs the review line; anything they can’t explain is disabled that day and re-enabled only if someone asks for it in writing.
• Audit trail: the review itself, dated and signed, filed with the AI agent register; the ERP’s own key list, server action settings and access history are the evidence.
• Cadence: monthly for anything that can write to the ERP or holds a key with no expiry; quarterly for everything else; immediately when someone leaves, a version is upgraded or a new agent goes live.
• Typical cost: no software to buy. The first review takes about half a day for one site; the quarterly one an hour or two once the list exists. A governed agent rollout starts from $5,000 ex GST per our AI agents for ERP in Australia hub, as at 14 October 2026.
• Typical timeline: the list in a week, the first review the week after, then the calendar does the rest.
• Last verified: 14 October 2026 against the Odoo 20.0 MCP server documentation and the Odoo 20 Enterprise source (commit 09c72a11, 4 October 2026), MYOB Acumatica’s user access documentation, MYOB’s AI page, the Essential Eight maturity model and the OAIC’s Guide to securing personal information.

We’ve written about the AI usage policy staff sign, the agent register and the risk register. This post covers the two documents left in that pack, and they’re the parts of AI agent governance that happen on a Tuesday in March when nothing is wrong, which is when you find the key nobody remembers issuing.

What is an approved-tool list, and how is it different from the agent register?

The agent register answers “what agents do we run, and who owns each one?” The approved-tool list answers an earlier, wider question: “what AI may anyone here use with company data at all?” Most entries on it will never be agents. They’re the assistant in a browser tab, the meeting summariser, the model behind an ERP feature you switched on, and the client on a laptop someone wants to point at the ERP.

A list entry is small. Tool name and provider. The data classes it may be given, using the three from the usage policy. Where the provider says the data is processed and stored, and whether it may retain or train on it, with the link and the date you read it. Who approved the entry. And who, by role, may issue that tool a key, token or login to the ERP. That last field is the one most lists leave out, and a key you can’t trace to an approver is a key you can’t review.

The vendors give you the raw material. MYOB’s AI page says MYOB Acumatica stores customer data in Australia, that depending on the feature data may be processed in Australia or through global infrastructure from Anthropic, AWS and Microsoft, and that those providers “cannot store it or use it to train their models”; its AI Automation documentation covers connecting your own model from Azure, Amazon Bedrock, OpenAI or Anthropic and says your data-handling policies have to allow sending potentially sensitive data to it. Odoo’s 20.0 agents documentation names two providers, ChatGPT from OpenAI and Gemini from Google, chosen per agent, and the MCP server documentation names Claude, Antigravity and Codex as clients. Each is a line on your list, or a deliberate decision not to be. The Office of the Australian Information Commissioner’s guidance on commercially available AI products is the reason the data-class column exists: entering personal information into an AI tool can be a use or a disclosure under the Australian Privacy Principles, and the OAIC says personal information, especially sensitive information, should not go into publicly available generative AI tools.

Which AI tools belong on the list, and which should stay off it?

The test is boring on purpose. A tool goes on the list if someone has read its terms and can say, in one sentence, where company data goes when staff use it. “Everyone uses it already” is a reason to do the reading, not a reason to approve.

Three categories need a decision each. The general assistants staff already have: approve the ones whose business terms exclude training on your data and whose data residency you can state, keep the consumer versions off, and say so in the policy. The AI built into the ERP: Odoo 20’s agents, Ask AI fields and credit-based digitisation, and the eight features MYOB lists, which its page says are “best configured by power users or administrators”. These still get a line, because the provider behind each one is a fact you’ll want written down when a customer asks. And the clients that connect from outside: an MCP client on a laptop, a self-hosted agent framework, an agent we built. Each of these gets a line naming who may issue it an ERP credential and with what scope.

The Australian Cyber Security Centre’s joint guidance on the careful adoption of agentic AI services, published in May 2026 with its Five Eyes counterparts, asks for the same thing from the security side: an inventory of the data, tools and systems each agent may reach, limits enforced on the platform rather than by the agent’s self-restraint, and logging that covers what agents do. The list is the inventory. The review is how you find out whether the platform still enforces it.

What does a permission review check in Odoo 20?

Odoo 20 put most AI access on two mechanisms, keys and server actions, which makes the review shorter than it was on Odoo 19. Our Odoo 20 MCP server permissions post covers the design; this is the checklist that follows from it.

Start with keys. Every MCP connection runs on an API key a user creates under My Preferences, Security tab, Add API Key, choosing the MCP scope and a validity period (the documentation’s example is one month). The key authenticates as that user, so the agent sees what the user sees. The review question per user is simple: which keys exist on this account, what scope, what expiry, and does the person still need each one? Keys with a long or missing expiry are the first thing we tighten. The Odoo 20 Enterprise source also contains an OAuth flow for MCP that the 20.0 documentation did not describe as at 14 October 2026: the user sees a Grant Access screen naming the client and the MCP scope, picks a duration, and what comes out is an ordinary MCP-scope API key on that user’s account, internal users only. So a connection approved by clicking Allow in a browser lands in the same per-user key list as one created by hand. Check the list, not your memory of who asked.

Then the tools. Under Settings, Technical, Server Actions, each tool has a Usage tab with two checkboxes: Available in MCP, which exposes it, and Readonly Tool, which tells the client it may run the tool without asking the user first. The documentation is explicit that Readonly Tool does not hide a tool or enforce anything; it’s a label. So the review reads every server action with Available in MCP ticked, confirms only tools that read carry the label, and confirms Create Records and Update Records are still hidden unless someone has a written reason. On the agents side, it reads each agent’s skills: an agent with no skills can only answer questions, and the preconfigured Create Records and Update Records skills are what turn it into something that changes data.

Two further settings sit in the Enterprise source under a group titled MCP OAuth: Allow Dynamic Client Registration, which lets clients register themselves, and a list of allowed client ID metadata document URLs. We leave registration off and treat the URL list as the Odoo-side approved-tool list; registered clients can be archived from an OAuth Clients menu under the technical security menu. Odoo’s documentation does not describe a log of MCP calls, so the last check sits outside Odoo: are the clients’ own tool logs kept, and has anyone read them since the last review? The credit statement behind our Odoo 20 AI credits post is a rough activity log for the features that spend credits.

What does a permission review check in MYOB Acumatica?

MYOB Acumatica has no MCP endpoint in the ANZ release as at 14 October 2026, so AI reaches it through the same doors as any integration, and the review follows MYOB’s own user access documentation, which already tells administrators to review access regularly, deactivate accounts when people leave, and review access history on forms that hold company data.

Start with accounts. MYOB’s guidance for integrated applications is one user account per application, on a user type whose Security Policies tab sets the allowed sign-in type (API, or Unrestricted for OAuth 2.0 and OpenID Connect) and the number of concurrent sign-ins. The review lists every user on an API-style user type, matches each to a line on the list, and asks whether a human is still accountable for it. An “integration” account three former staff knew the password to fails on the spot. Then roles. Access Rights by Role (SM201025) shows what one role can reach; Access Rights by Screen (SM201020) shows every role’s level on a form, the faster way to find who can edit Customers or release AP documents. Where a user has several roles the most permissive level wins, so an agent’s account gets one role, built for it, nothing inherited.

Then the connected applications. OAuth clients are registered on Connected Applications (SM303010) with a client name, a flow and shared secrets shown once; since release 2025.1.1 the External Applications form (SM301000) has a Tokens tab listing the tokens obtained for an application. The review reads both: which clients exist, which secrets are near expiry, which tokens belong to people who’ve left. Finally the AI features. AI Automation is switched on per site on Enable/Disable Features (CS100000), and MYOB’s documentation says only authorised users can configure or run prompts, with existing access controls and audit logging applied before any data is sent. The review confirms which roles those are and reads the automations that create or route records, the way the Odoo review reads skills. Our MYOB Acumatica AI guide covers what each feature does; the review only asks who can reach it.

How often should you review, and who signs it off?

Australian guidance gives you the cadence; you only have to borrow it. The Australian Signals Directorate’s Essential Eight maturity model, under restrict administrative privileges, has requests for privileged access validated when first requested at every maturity level, and from Maturity Level Two has privileged access disabled after 45 days of inactivity and after 12 months unless revalidated. A key that lets a tool read your ledger is privileged access by any sensible reading, so those are the floor: approve each key when it’s requested, kill it when it goes quiet, make someone re-justify it within a year. The OAIC’s Guide to securing personal information adds the privacy framing: limit access to those who need it for their job, review or revoke it when a person changes role or leaves, and review audit logs on an ongoing basis. The National AI Centre’s Guidance for AI Adoption asks you to keep an AI register, extend your data governance and cybersecurity practices to your AI systems, and monitor each system after you deploy it.

Our own cadence is tighter: monthly for anything that can write to the ERP or holds a key without an expiry, quarterly for everything else, and immediately when a key holder leaves or changes role, when a version is upgraded (our Odoo 20 upgrade checklist covers what the AI settings now mean) and when a new agent goes live. The sign-off belongs to the owner of each key or agent, not to IT. The person who asked for the access is the one who can say whether it’s still needed, and a signed line each quarter is what turns “we have a review” into one that changes anything.

“The first review at a new site always finds the same thing: a key from the pilot that never expired, on the account of someone who’s since changed jobs, with a write tool still ticked because the demo needed it. Nobody did anything wrong. Nobody looked. The review is just the looking, on a date, with a name beside each line.”

Bill Alvarez, Practice Manager, Auboros

A worked example: the quarterly review that found the key nobody remembered

Picture a Brisbane industrial supplies wholesaler on Odoo 20, about 70 staff, one agent in production: a sales order drafter that reads inbound PDF orders and drafts orders for a coordinator to confirm. First quarterly review since go-live. The finance manager has the approved-tool list open: two general assistants on business terms, the Odoo agent on one named provider, the drafter’s MCP client, nothing else.

The key review turns up four MCP-scope keys. Two belong to the drafter’s account and the coordinator, both expiring next month, both on the list. The third is on the sales manager’s account, named “demo”, created in July with no expiry; a consultant set it up to show the MCP client reading the pipeline. The fourth is on the account of a warehouse supervisor who moved to a customer site in August and still has an active login. Neither is on the list. Both are deleted that morning, and the supervisor’s user is archived while they’re there.

The tool review reads the server actions with Available in MCP ticked. Seven: the five Odoo exposes by default and two the implementation added, one that drafts a sales order and one that logs a note. Update Records is also ticked. Nobody can say who ticked it or when, so it’s unticked, with a register line saying it comes back only on a written reason from the sales director. The two custom tools are checked against their code: the drafter stops at a quotation in draft, the logger writes to the chatter only. The agent’s skills: Information retrieval and the two custom skills, no Create Records. Pass.

The last line is logs. The MCP client kept its tool log; the last month shows 212 draft orders, each followed by a confirm or an edit by the coordinator in Odoo, and nothing from the “demo” key since July. Forty minutes, four lines signed, two keys gone, one write tool back behind a person. Nothing dramatic happened, which is the point.

Where the review goes wrong

The common failure is the tick-box review: a spreadsheet with “reviewed” written on it by someone who didn’t open the key list. The register says what should exist, the ERP says what does, and the review is the diff; if it doesn’t read from the system it isn’t a review.

The second is an allowlist with no approved way to do the thing. Ban the consumer chatbot without putting a business-terms assistant on the list and the ban lasts until the next deadline.

The third is the shared integration account. It feels efficient, and it means a key review has nobody to ask, a log has nobody to name, and “validated when first requested” can’t be met because nobody requested it. One account per tool, one role per account; the cost is five minutes of setup.

The fourth is trusting a label. Odoo’s Readonly Tool checkbox and a role called “AI read-only” are names; the review checks what the code does and what the role can open. We’ve found a vendor-shipped AI tool that lifted itself to administrator rights before, and the review is where you’d catch the next one.

Goes well with

• The AI agent register: the one page per agent that the permission review checks the live system against.
• Odoo 20 MCP server permissions: the design decisions behind the keys, tools and flags this review reads.
• AI usage policy for Australian businesses: the document that tells staff which tools are approved and who may hand out an ERP key in the first place.

Do you know every key that can read your ledger right now?

Auboros runs the first approved-tool list and permission review for Odoo and MYOB Acumatica sites from Brisbane, working across Queensland, interstate and New Zealand, then hands you the checklist and the calendar reminders to keep doing it yourselves.

If you’d like to know what can touch your ERP before the next pilot adds to it, book a free consultation. Half a day usually finds the key nobody remembered.