The AI that only reads your ERP today will probably write to it tomorrow: quote, invoice, create orders. And the day that happens, someone has to hand it a key to a real system, with real data, that a mistake can actually damage. It's the same decision we made a few days ago at AutoBoost when we opened the company to its first external collaborator, and we solved it with two rules that apply exactly the same whether the one coming through that door is a person or an AI agent.
The question almost everyone skips
When an AI gets connected to an ERP, a CRM, or a billing system, almost the whole conversation revolves around what it's going to be able to do: quote, check stock, create an order. That's the right question, but it isn't the only one. The one that usually falls outside the budget and the contract is: how is the key you're going to give it protected, and what stops it from doing more than you asked?
These are two different questions, and it pays not to mix them up:
- Who is it? (identification): the key proves that whoever is calling is who they claim to be.
- What can it do? (authorization): what that identity is actually allowed to touch.
The common mistake is treating them as one thing: "if it has the key, it can do whatever the API allows." That mixup is what turns a small data leak into a big disaster, and what lets an AI agent with a reasoning mistake touch something it should never have been able to reach.
Rule 1: the key identifies, it never authorizes on its own
When we onboarded AutoBoost's first external collaborator, we built a system of individual keys per person to log hours from the terminal or from an agent, without having to open a browser every time. The technical decision underneath was this: the database only stores the hash (SHA-256) of each key, never the key itself. So even if someone got access to the entire database, they wouldn't get a single usable key, only fingerprints that can't be reversed to recover the original.
This applies exactly the same way when the one using the key is an AI agent writing to your ERP:
- The system receiving the AI's calls should never store that key in plain text anywhere: not in the database, not in a log, not in a readable config file.
- If your AI provider can't explain how they store the credentials you gave them, that's the first security question to ask before letting them write to your system.
- A leaked key (from a misconfigured log, a database breach, a badly built prompt) shouldn't be worth anything on its own if the rest of the system is designed properly.
Rule 2: permissions come from the role, not from the key
The second piece is the one that actually limits the damage. In AutoBoost's collaborator system, having a valid key doesn't grant access to everything: each person only sees and logs hours on the projects they're assigned to, and what they can or can't do comes from their role, exactly like on the web. No key, however valid, lets someone log hours on another person's behalf or touch a record that isn't theirs.
Applied to an AI agent with write access, the rule is the same: giving it a key doesn't mean giving it access to everything that key could technically reach. Its role needs to be defined with the same precision as a person's:
- Which tables, objects, or actions it can touch (and which it can't, even if it technically could).
- Whether it can create but not delete, or modify but not approve payments.
- What happens if it tries something outside its role: does the system block it, or does it just trust the AI to "behave"?
Two real AutoBoost cases show what this looks like in practice. The AI sales agent that quotes over WhatsApp inside an industrial distributor's ERP (full case) can validate the customer, apply the right rate, check stock, and create an opportunity or an order, and nothing more: it can't touch base prices or delete customers, because its role doesn't allow it, even though the key it uses is perfectly valid. And the AI that books invoices for a veterinary group (full case) can only act on what it created itself: if the total doesn't match, it deletes its own invoice, but never touches one it didn't generate.
What happens if you skip these two rules
Without rule 1, a database leak (something that happens even to large companies) turns a stolen key into direct access to your ERP. Without rule 2, even with no leak at all, an AI agent that makes a mistake (and every agent makes one eventually) can touch something it should never have been able to reach, simply because nobody set a limit narrower than "whatever the API allows."
The combination of the two is what separates a well-built AI project from one that works fine until the day it fails big.
Checklist before handing a key to your AI (or any collaborator)
| Question | Bad | Good |
|---|---|---|
| Where is the key stored? | In plain text, in the database or in a log | Only its hash (SHA-256 or equivalent) |
| What can it do with it? | Whatever the API technically allows | Only the actions defined by its role, set in advance |
| Can it act on behalf of another person or entity? | Yes, if it knows the key | No: the key identifies, the role authorizes |
| Can it touch records it didn't create? | Yes, no distinction | No, unless its role explicitly allows it |
| What happens if the key leaks? | Full access to the system | Nothing usable without the role and permissions attached |
If your provider can't clearly answer these five questions before connecting their AI to your ERP or your CRM, you don't have a technology problem, you have an access problem with no limits, and that's exactly the one that costs the most when something goes wrong. At AutoBoost we build every integration with these two rules by default, whether the one entering the system is a person or an AI agent. If you want to review how access looks in your system today, or you're considering an AI that writes to your ERP, get in touch and we'll look at it together, or see how we work in our services.
