When Not to Give an AI Agent Write Access
Yesterday we argued that the real question in agentic ERP is where reasoning should live. Today, the harder half of that question: once an agent can reason about your data, what should it be allowed to do to your data?
Gartner’s answer, published in May, is that uniform governance across all agents is itself a failure mode. Controls should scale with autonomy. Their middle tier, agents that advise and draft while humans execute, stays read-only with no write access to anything. That framing is right, and for a smaller company it can be made even simpler. The write-access decision is the governance decision. Get that one right and most of the rest is paperwork.
Read is cheap to forgive, write is not
An agent with read access that produces a wrong answer wastes minutes. Someone reads it, frowns, checks the source. An agent with write access that takes a wrong action changes your records, and an ERP is unforgiving about changed records. A wrongly posted invoice ripples into the ledger, the VAT return, the supplier balance. The cost of a mistake is not symmetric, so the permissions should not be either.
Three questions before granting write
Before an agent gets write access to any system, ask these about the specific action, not the agent in general.
First, is it reversible? Creating a draft email is reversible. Sending it is not. Flagging an invoice for review is reversible. Paying it is not. Agents earn irreversible actions last, if ever.
Second, what is the blast radius? Updating one order’s internal status touches one order. Writing to a master data record (a price list, a tax rate, a bill of materials) touches every future transaction that reads it. Master data should be the last place an agent ever gets write access, long after transactional records.
Third, will anyone notice if it is wrong? A drafted reply gets read by a human before it matters. A silent nightly update to stock levels may not be looked at for weeks. If no human naturally reviews the output, the action needs either an approval gate or it stays read-only.
Draft-but-not-send, flag-but-not-post, propose-but-not-execute. Most of the value of an agent survives these constraints, because the expensive part of the work was the reading and reasoning, not the final click.
Prompts are not controls
One mistake we see often: teams “restrict” an agent by telling it in the system prompt what it must not do. Instruction-following is best-effort, and prompt injection is a real attack. The restriction has to live outside the model, in the same permission layer that governs your human users. This is why we like the ERP-native approach: Etendo’s Copilot runs inside the ERP’s existing role and permission model, so an agent literally cannot write to a window its role does not grant, whatever the prompt says. We covered the broader case in why agentic ERP has to start with governance.
The practical outcome for an SME is a one-page table: each agent, each system it touches, read or write, and the approval gate for anything irreversible. If you want help drawing that table for your own workflows, that is exactly the kind of thing our free assessment covers.