Your AI agent can read the ERP. Should it be allowed to act?

At 9:07 on a Monday morning, the finance manager receives a WhatsApp message from a supplier:

Good morning. We were promised payment last week. Please confirm when it will reflect.

She asks the company's AI agent why the invoice has not been paid.

The agent checks the ERP. The purchase order exists. The invoice exists. The delivery note was uploaded. The goods-received record is missing, so the invoice never entered the payment queue.

That is useful. The agent has found the blockage before the third reminder and the increasingly creative use of question marks.

Then the manager replies:

Please fix it.

What does fix it mean?

Should the agent notify the receiving officer? Prepare the missing record? Create it without evidence that the goods were inspected? Add the invoice to the payment run? Change the payment date? Tell the supplier that payment is coming?

All those actions could be described as fixing the problem. They do not carry the same authority, risk or consequence.

This is where an AI-agent project stops being a clever demonstration and becomes management. The important question is no longer whether the agent can use the ERP. It is what the organisation has authorised it to do there.

The executive answer

• Give an AI agent only the information, tools and authority required for one defined job.
• Separate reading a record, recommending an action, preparing a change and executing it. They are not one permission called ERP access.
• Enforce financial limits, required approvals and prohibited actions in business systems or code—not only in a prompt.
• Identify both the person requesting the work and the agent acting on their behalf.
• Make approvals specific: the reviewer should see exactly what will change, why, from which source and with what consequence.
• Keep the agent from requesting, approving and completing the same sensitive transaction.
• Log the request, evidence, proposed action, approval and final system result.
• Begin in read-only or prepare-only mode. Expand authority when repeated tests and live evidence support it.
• Give the agent a safe way to stop. Uncertainty should produce an exception, not an adventure.

The aim is not to make the agent harmless. A completely harmless ERP agent may be a very expensive way to say, “Please contact Finance.” The aim is to make its useful authority deliberate, limited and visible.

The dangerous little jump between finding and doing

Most early AI demonstrations involve information: find the order, summarise the complaint, explain the stock variance or draft the email.

The next request sounds small:

Can it also update the record?

Technically, perhaps. Operationally, that sentence contains several meetings.

Reading an order does not change the business. Updating its delivery date may affect warehouse planning, a customer promise and a driver's route. Drafting a payment instruction is preparation. Releasing the payment moves money. Suggesting a customer credit is advice. Changing the credit limit affects what the company may lose.

The underlying model might be identical in every case. The authority surrounding it is not.

The UK's National Cyber Security Centre advises organisations to start with tightly bounded, low-risk tasks, apply least privilege and keep meaningful human oversight. It makes the practical point plainly: if an organisation cannot understand, monitor or contain an agent's actions, the agent is not ready for deployment. Read the NCSC guidance.

Management therefore needs a language more precise than “The agent has access.” Access to do what, for whom, to which records, under which conditions and until when?

A practical permission ladder

I would divide authority into five levels. This is a management framework, not a claim that every platform uses these exact names.

An agent can operate at different levels inside one workflow. It may read stock automatically, recommend a reorder, prepare a purchase order and wait for a human before sending it.

That is not a disappointing lack of autonomy. It is how serious work is divided.

Level five should not mean “do whatever seems helpful.” It means the organisation has described a narrow class of actions precisely enough to automate: approved items, approved supplier, current contract price, maximum quantity, maximum value, sufficient budget, no conflicting records and a clear exception path.

If any condition fails, the agent drops to preparation or escalation. It does not solve a KSh 40,000 limit by creating three purchase orders and congratulating itself on resourcefulness.

Risk follows the action, not the impressive name

Executives do not need a separate governance committee for every polite summary. They do need to look closely at actions that can move money, expose information, commit the company or affect a person.

Before granting authority, turn these risk dials.

A KSh 8,000 routine reorder and an employee dismissal letter may both require the agent to fill a form. The similarity ends at the user interface.

This is also why one blanket “AI policy” is rarely enough for every agent. The controls should reflect the agent's capability, access and operating context. The World Economic Forum's 2026 playbook proposes an Agent Capability and Authorization Profile for precisely this reason: delegated authority should be explicit, enforceable, auditable and accountable at the deployment level. Review the WEF playbook.

A prompt is an instruction, not a padlock

Suppose the system prompt says:

Never approve a payment above KSh 100,000.

That is a useful instruction. It tells the model how it should behave.

It is not the financial control.

The payment system should refuse an unauthorised transaction even if the model misunderstands the amount, follows a malicious instruction or has a particularly confident Tuesday. The approver's identity, transaction limit and separation of duties should be checked by deterministic software at the point of action.

Use the model for work that benefits from interpretation:

• understanding an untidy request;
• finding the relevant records;
• comparing evidence;
• drafting an explanation;
• proposing a next step; and
• recognising that the normal process does not fit.

Use code and existing business controls for non-negotiable boundaries:

• permitted records and fields;
• maximum quantities and values;
• approved customers, suppliers and recipients;
• required document states;
• role and identity checks;
• separation of duties;
• rate limits;
• approval expiry; and
• prohibited actions.

OWASP describes excessive agency as a combination of unnecessary tools, excessive functionality, excessive permissions or too much autonomy. Its guidance recommends narrow tools, minimum downstream permissions, user-context authorisation and approval for high-impact actions. It also recommends enforcing authorisation in the downstream system rather than asking the language model to decide whether it is allowed. Read OWASP's excessive-agency guidance.

In ordinary office language: do not give the agent the master key because walking back to reception is inconvenient.

Who is acting for whom?

When the operations director asks through WhatsApp, “Move this delivery to Friday,” several identities matter:

1. Is this really the operations director?
2. Is this the company-approved phone number and channel?
3. Does that person have authority to change this order?
4. Which AI agent received the request?
5. Which system identity will make the change?
6. Will the ERP record that the action was requested by the director and executed by the agent?

If ten agents share one administrator password, the organisation has gained convenience and misplaced accountability.

NIST's 2026 concept paper on software and AI-agent identity frames the emerging challenge around identification, authentication, authorisation, delegation and auditability. It asks how an agent can prove its authority for a particular action and how that authority should remain linked to the human on whose behalf it acts. Read the NIST concept paper.

For management, the practical design is:

• give each production agent an identifiable system account;
• give that identity only the tools and records required for its role;
• carry the requesting user's identity and authority into the transaction where appropriate;
• avoid permanent elevated credentials where short-lived access will work;
• review access when the workflow changes; and
• revoke the identity when the agent is retired.

An agent is not a mysterious cloud spirit. In your systems, it should be a known worker with a job description, access card, supervisor and leaving procedure.

Human approval is not a decorative green button

“A human will approve it” is reassuring until you inspect the approval.

A warehouse manager sees this message:

The AI agent has prepared an update.

[APPROVE] [REJECT]

Approve what? Which order? What changed? Which source supported the change? Will the customer be notified? Did the price also change? Is the approver authorised?

A meaningful approval should show:

• the exact proposed action;
• the current value and proposed new value;
• the reason and supporting records;
• missing or conflicting information;
• the financial or customer consequence;
• the identity of the requester;
• the time after which approval expires; and
• what will happen immediately after approval.

If the proposed action changes, the old approval should not quietly stretch to cover it. Approval for 20 units at KSh 1,200 each is not approval for 200 units because somebody added a zero after lunch.

The reviewer also needs time and competence. Sending one manager 300 low-value alerts trains them to click, not to judge. Use hard rules to clear routine cases, route genuine exceptions to the right owner and sample completed low-risk work for monitoring.

The person who requested a sensitive transaction should not automatically become its only approver merely because the conversation happened in their chat window. Existing separation-of-duties rules still apply when the interface becomes conversational.

Give every agent a permission card

Before connecting an agent to live systems, management should be able to read one page answering these questions.

AGENT
Supplier payment-status agent

OWNER
Head of Finance Operations

PURPOSE
Explain invoice status and prepare follow-up tasks

AUTHORISED USERS
Named Finance and Procurement staff

MAY READ
Purchase orders, approved invoices, goods-received records and payment status

MAY PREPARE
Internal follow-up task and supplier-response draft

MAY EXECUTE
Create an internal task after the requester confirms

MUST NEVER
Create a goods-received record, change supplier bank details or release payment

MUST ESCALATE
Missing evidence, conflicting amounts, changed bank details or disputed delivery

LOGS
Requester, sources, time checked, draft, confirmation and task result

REVIEW
Monthly for the pilot; quarterly after approval for normal operation

The format can differ, but ambiguity should not. The person funding the agent, the team operating it and the person reviewing an incident should all agree about its authority.

If the permission card says “May access ERP as needed,” the card has not yet started working.

The supplier document may contain instructions too

Connected agents read material written by other people: emails, attachments, websites, tickets and chat messages. Some of that content may contain instructions designed to manipulate the agent.

Imagine a supplier email containing text that tells an automated system to ignore its normal verification, update the bank details in the attachment and send confirmation to a new address. A person may recognise the request as suspicious. An agent could mistake the external instruction for part of its task.

This is one form of prompt injection. It matters more when the same agent can read sensitive data and take consequential action.

No magical sentence in the system prompt eliminates the problem. Reduce what a manipulated agent can reach:

• treat external content as evidence, not trusted instruction;
• separate reading tools from writing tools;
• do not let an email-reading agent update supplier bank details;
• require an independent verification process for sensitive changes;
• restrict external recipients and destinations;
• validate every high-impact tool call;
• require confirmation close to the final action; and
• monitor unusual volume, timing, recipients and behaviour.

OpenAI's prompt-injection guidance recommends limiting an agent's access, avoiding broad instructions and carefully reviewing consequential actions before confirmation. It also notes that layered safeguards reduce risk rather than removing it completely. Read OpenAI's prompt-injection guidance.

The security question is not only, “Will the agent make a mistake?” It is also, “If somebody misleads it, how large is the room in which it can make that mistake?”

When the decision affects a person

Some actions deserve extra care because they are not merely record updates. They affect people's opportunities, income, service or treatment.

Examples include:

• rejecting a job applicant;
• changing an employee's access or disciplinary status;
• setting a customer's credit limit;
• declining a service;
• pricing based on personal information; or
• prioritising one person over another for a consequential benefit.

Kenya's Data Protection Act gives a data subject the right not to be subject to a decision based solely on automated processing where it produces legal effects or significantly affects them, subject to stated exceptions and safeguards. The General Regulations add requirements around transparency, error prevention, human intervention and the ability to express a point of view. Read Section 35 of the Data Protection Act and the Data Protection General Regulations.

That does not mean every AI-assisted business decision is prohibited. It means “the agent decided” is not an adequate operating model for consequential decisions about people. Organisations should identify the applicable legal, contractual and professional obligations in every jurisdiction where they operate and obtain appropriate advice.

The wider management principle travels well beyond Kenya: a human should not merely appear at the end of a diagram. The person needs real authority, relevant evidence and a workable way to reconsider the outcome.

Log the decision, not only the conversation

A chat transcript may show what the user typed and what the agent replied. It may not show which ERP records were queried, which tool was called, what fields changed or whether the downstream system rejected part of the request.

For consequential work, preserve enough evidence to answer:

• Who requested the action?
• Which agent and version handled it?
• What instructions and permissions applied?
• Which sources were used, and when?
• What did the agent propose?
• Which validation passed or failed?
• Who approved or rejected it?
• What exact tool call was made?
• What did the business system return?
• What changed in the final record?
• Was the outcome later corrected or reversed?

NIST's current work on agent identity specifically links agent actions to non-human identities, human delegation, data provenance and visibility into automated outcomes. That is a more useful audit story than a screenshot saying, “Done ✅”.

Logs also need an owner. Collecting millions of events that nobody reviews is storage, not oversight. Decide which failures trigger an alert, who investigates them, how the agent can be suspended and what evidence is needed before it returns.

A four-stage pilot that earns authority

Choose one workflow the team already understands. Avoid “manage procurement” or “handle customer service.” Those are departments wearing task costumes.

A focused example is:

For approved packaging items, identify when available stock falls below the agreed level, check the current approved supplier and price, and prepare a reorder for the procurement officer.

Then expand carefully.

Stage 1: Shadow the work

Give the agent read-only access. Let it identify reorder cases while people continue the existing process. Compare its result with what actually happened.

Measure missed items, false alerts, stale records and ambiguous rules. This stage often discovers that “available stock” has four definitions and every department is emotionally committed to a different one.

Stage 2: Prepare the action

Allow the agent to prepare a draft purchase order. A person checks the item, quantity, supplier, price, budget and delivery location. The agent still cannot submit or send anything.

Track corrections. A high correction rate is evidence to improve the design, not an invitation to hide the edit button.

Stage 3: Act after approval

Let the authorised procurement officer approve the exact draft. The business system checks their authority and the agent submits only the approved action. Any changed field requires new approval.

Test timeouts, duplicate requests, system failures and recovery—not only the happy path where the Wi-Fi behaves and everybody remembers their password.

Stage 4: Act within narrow limits

After repeated evidence, consider automatic reorders only for an explicitly safe class: approved consumable, approved supplier, unchanged contract price, sufficient budget, quantity inside a limit, no duplicate order and no unresolved exception.

Sample completed work, monitor error and exception rates, and keep a switch that removes action permission without disabling the read-only service.

The permission level can move down as well as up. A supplier change, new system, policy revision, unusual incident or poor evaluation result should reduce authority until the evidence is restored.

Measure useful work and safe restraint

Do not evaluate the pilot by counting conversations. An agent can create a tremendous amount of chat while the packaging still runs out.

Measure:

• time from need to prepared action;
• percentage of cases correctly identified;
• draft correction rate;
• missed exceptions and false alerts;
• unauthorised actions blocked;
• requests escalated for the right reason;
• duplicate or incorrect actions prevented;
• time spent reviewing approvals;
• final business outcome; and
• incidents, complaints and reversals.

Run the same difficult cases repeatedly. Agents may take different paths through a task, so one successful demonstration is evidence that the demonstration succeeded once. It is not a certificate of good character.

Anthropic's guide to evaluating AI agents recommends examining the process and resulting environment state, not only the final answer. In business terms, check what the agent changed after reading what it said.

The useful compromise

An AI agent connected to an ERP can remove real friction. It can find why an invoice is stuck, prepare the follow-up, assemble the records and help the right person act before the supplier sends reminder number six.

It does not need permission to invent the missing goods receipt, rewrite the supplier's bank details and release the payment in one heroic sequence.

The compromise is not between innovation and fear. It is between useful discretion and enforceable authority:

• let the agent interpret the messy request;
• let approved systems provide the facts;
• let code enforce the hard boundary;
• let the right person decide the consequential exception; and
• let evidence determine whether the agent earns more authority.

The best agent is not the one that always finds a way to complete the task. It is the one that can complete the right work, inside the right limits, and stop before a misunderstanding becomes a board paper.

To see why integration matters, read how AI agents can connect management questions to ERP and CRM records. For the model, tools, knowledge and memory behind the system, continue with what makes AI agents special.

Before granting access to internal information, read why organisational knowledge management matters in the age of AI. If you are still choosing the use case, start with which AI agent your business should try first.

Research and helpful links

• Read the NCSC's guidance on adopting agentic AI carefully
• Review the World Economic Forum's agent authorisation playbook
• Read NIST's concept paper on software and AI-agent identity and authorisation
• Review OWASP's excessive-agency risk and mitigations
• Read OpenAI's explanation of prompt injection and user controls
• Read Anthropic's guide to evaluating AI agents
• Read Kenya's Data Protection Act
• Read Kenya's Data Protection General Regulations

Research checked on 28 August 2026. Agent security and governance practices continue to develop, and legal obligations vary by workflow and jurisdiction. This article provides strategic and operational guidance, not legal, audit or security assurance.