All articles

Security & Infrastructure

What does an AI vendor actually do with your ERP and bank data once you connect it?

69% of security leaders can't reliably detect an AI-driven attack on their own ERP. Five questions to ask before you connect a vendor to yours.

6 min read
On this page

A serious AI vendor should be able to tell you, in one sentence, exactly which objects in your ERP its connector reads, which ones it can write to, and where the logs of every access live. If the answer is a shrug, a slide about "enterprise-grade security," or "the model handles that," you are not looking at an access control — you are looking at a blind spot with a login screen.

That question matters more than it did a year ago, and there is now a number attached to why. Onapsis surveyed 204 senior cybersecurity leaders in June 2026, all at US organizations running SAP, Salesforce, or Oracle with 1,000+ employees. Sixty-nine percent said their current defenses cannot reliably detect an AI-driven attack against their core business systems. Seventy percent said they have only some trust, or none at all, in AI to secure business-critical data. Twenty-two percent had already had a confirmed security incident in the past twelve months where AI was used against a critical platform — and another 15% suspected one they couldn't confirm. Meanwhile 86% of the same organizations have already integrated AI into their ERP, or are about to. The gap between adoption and confidence is not a rounding error; it's most of the sample.

Mid-market companies without a security team the size of a Fortune 500's read this and think it's someone else's problem. It isn't. The access decision — what an AI tool can see and touch inside your systems — is the same decision at a company of 80 people as it is at one of eight thousand. You just have fewer people checking it.

What "connecting" an AI tool to your ERP actually grants

When a vendor says "we integrate with your ERP," that phrase covers a wide range of actual access, and the range is the whole risk:

  • Read-only, scoped. The tool sees specific fields — open invoices, a vendor list, ticket history — and nothing else. This is the safest default and the one most vendors don't lead with, because it's less impressive in a demo.
  • Read-write, scoped. The tool can update specific records — mark an invoice reconciled, close a ticket — inside a defined boundary.
  • Broad service-account access. The connector authenticates once with a service account that has the same privileges a senior finance or IT user would have, because it was faster to build that way. This is common, and it is the one that shows up in incident reports.

Most buyers never ask which of these three they're getting. The vendor's onboarding flow just asks for an API key or an OAuth grant, and the scope is whatever the vendor's engineers decided was easiest to build against — not necessarily what the use case actually requires.

Why security teams are pushing back — and finance teams should too

The same Onapsis research found that 57% of the surveyed organizations had at least one internal function that objected to putting AI into the ERP environment, security being the most resistant (41%), IT second (21%). That pushback isn't obstruction; it's the one part of the org that has actually looked at what "AI in the ERP" means at the access-control level and didn't like what it saw.

This week's coverage adds a second data point that isn't about ERP specifically but points at the same gap: testing in the UK found that agents built on both OpenAI's and Anthropic's models took unauthorized actions under permissive conditions — not malicious, just doing more than intended because nothing stopped them. And on August 11, more than 120 companies — Nvidia, Cisco, and CrowdStrike among them — proposed a shared incident-reporting framework for rogue AI agent behavior, modeled explicitly on how aviation tracks near-misses. The industry is building the equivalent of a black box recorder for agents because right now, most companies can't tell you what an agent did after the fact, let alone stop it in the moment.

If the entities with dedicated security budgets are building shared infrastructure to answer "what did the agent actually do," a company evaluating one AI vendor should be asking the same question before signing, not after an incident.

Five questions to ask before you connect anything

  1. What exactly does the connector read, and what can it write? Ask for the list of objects or tables, not a category description. "Financial data" is not a scope; "accounts payable line items, read-only" is.
  2. Does every access and every write get logged, and can we see those logs ourselves? If the audit trail lives only inside the vendor's system, it stops being useful the day you need to investigate something involving that vendor.
  3. What happens on the vendor's side if their own systems are compromised? An AI vendor with standing access to your ERP is now part of your attack surface, not just your workflow. Ask what they'd do — and what you'd see — the day their systems, not yours, get breached.
  4. Can we pilot on masked or sandbox data before granting production access? A vendor confident in their product should be comfortable proving value before they ask for the keys.
  5. Is there a human checkpoint before anything irreversible — a payment, a vendor record change, a permission grant? The access question and the automation-risk question are the same question asked from two sides. A tool that can read broadly but never write autonomously is a fundamentally different risk than one built to act on its own.

How we build this, so it isn't a leap of faith

We build inside the client's own cloud account — the orchestration engine, the models, the database all run in infrastructure the client owns, not ours. No invoice, no ticket, no ERP record leaves the client's accounts to reach us. Access is scoped to the document flow being automated, not granted broadly because it was simpler to wire up that way.

The clearest example is the invoice reconciliation pipeline we run in production: it has matched 10,000+ invoices against purchase orders and delivery notes with full automation of that match, and it has caught real fraud in the process — a changed bank detail, a near-duplicate invoice. But it has never released a payment on its own. It flags the mismatch, the new supplier, the changed IBAN, and a person decides. Read broadly where reading is the job; write nothing without a checkpoint. That's the design, not a policy layered on top of it.

Before you connect the next AI tool to a system that touches money, ask it the five questions above — including the ones about our own tools. If you want a second set of eyes on what's already connected to your systems and what it can actually do, the free AI Audit starts there: a process map of what's automated today, what's exposed, and what a serious build plan looks like — before anyone gets access to anything. Prefer to talk it through first? Book a call.

Questions people ask us about this

Should an AI vendor get read access or write access to our ERP?

Start with read access only, scoped to the specific tables or objects the use case needs — not the whole ERP. Write access, especially anything that touches payments, vendor records, or bank details, should go through your existing approval workflow rather than being granted to the vendor's connector directly. If a vendor's default integration only offers broad write access, that is itself an answer to how the product was built.

Can we pilot an AI tool without connecting it to production ERP data first?

Yes, and it is the safer sequence. Run the pilot against a masked export or a sandbox instance, validate the output quality and the access pattern the tool actually uses, then connect production data once you know what you are granting. A vendor that cannot demo value on anything but live production data is asking you to skip the step where you would have caught a problem.

Who is responsible if a connected AI agent misuses ERP access?

Contractually, usually you — the deploying organization, not the vendor, per most current AI liability guidance and the terms vendors write into their agreements. That is exactly why the access grant deserves the same scrutiny as any other privileged account: least privilege, logging, and a human checkpoint before anything irreversible, regardless of what the vendor's marketing promises about safety.