What to ask before an agent can write to your ERP.

An AI agent is an unusual thing to review, because the interesting risk is not the model. It is that a new non-human identity is being given credentials to a system of record, and asked to act in it continuously without a person watching each action.

That framing makes the review tractable. Most of the questions are ones a security team already knows how to ask about a service account, plus a small number that are specific to how these systems work.

1. The deployment boundary

Two questions that sound like one, and must be answered separately.

• Where does the agent run? Inside your infrastructure, in the same environment as the systems it works with, or in the vendor's cloud with your systems exposed to it?
• Where does model inference happen? This is a different question with different data terms, and a vendor who answers only the first has not answered.
• What data crosses the boundary, in what form, and is any of it retained by the party on the other side?
• Is any of it used to train or improve a model? The answer should be no, and it should be in the contract rather than in a policy page.

2. Identity and access

1. 01A named identity

   The agent authenticates as its own service identity, never as a shared account and never borrowing a person's credentials. Its actions must be attributable to it and not to an employee.

2. 02Scoped reads

   Access limited to the entities the workflow requires. Broad read is normally acceptable within that scope, because reading changes nothing, but the scope should still be written down.

3. 03Narrow writes

   Enumerate every write. For an order agent that is typically: create the target record, attach the source document, add a note. Nothing else.

4. 04No destructive actions

   No deletes, no overwrites of master data, no reversal of posted transactions. This is a structural limit, not a threshold that can be raised later by configuration.

5. 05Credential handling

   Where secrets live, how they rotate, and who can read them. The same standard as any other privileged service identity.

6. 06Review cycle

   Who reviews this access, how often, and against what record of what it actually used.

A useful test for step three: write the permissions as the list of actions you would put in an offer letter for the person doing this job today, then strike every destructive one. If a permission is not on that list, ask why it is being requested.

3. The high-value targets

Three specific things should sit outside the write surface entirely, because the consequence of getting them wrong is categorically different from an incorrect order line.

4. The log as a control

Treat the activity log as a security requirement with a specification, not as a product feature to be admired in a demonstration.

1. 01What is recorded per transaction: the source document, what was extracted, what it was matched to, which rules fired, what was written, and every human intervention.
2. 02Whether a single transaction can be reconstructed end to end from the log alone, months later.
3. 03Where the log lives, who can read it, and whether the agent can modify it. It should not be able to.
4. 04Retention period, and whether it matches your other operational records.
5. 05Whether it can be exported into your own monitoring, rather than only being viewable in a vendor console.

If you cannot reconstruct one transaction from the log six months later, you do not have an audit trail. You have a dashboard.

5. Failure behavior

Ask what happens when things go wrong, and prefer specific answers to reassuring ones.

• What happens when a connected system is unavailable mid-transaction? Partial writes are the risk worth probing.
• What happens when the agent is uncertain? The answer should be that it holds the case, not that it proceeds with its best guess.
• What happens when a document is malformed, or contains instructions addressed to the agent? Content arriving from outside your organization should be treated as data, never as instruction.
• How is the agent stopped? There should be a way to halt it immediately that does not require the vendor.
• What is the rollback story for something it committed incorrectly? It should be your normal correction process, because the agent cannot reverse its own work.

The third point is specific to this class of system and is worth asking directly. An agent that reads external email and attachments will eventually be sent a document containing text aimed at it. The design answer is that external content is data to be processed, and the agent's instructions and permissions come from the deployment, not from the document in front of it.

Answers that should end the evaluation

Agreeing these in advance makes the review considerably faster.

• "We would need broad write access to get started, and we can narrow it later."
• "Inference details are confidential", or an answer that covers where the software runs but not where the model runs.
• "The log shows what it did", with no answer on retention, access or whether the agent can modify it.
• "It learns from your data" without a clear statement of what that means, where it happens and whether anything leaves your boundary.
• "It handles exceptions automatically", with no held queue and no stated stopping conditions.
• Any inability to demonstrate a case the agent got wrong and what happened next.

The last one is the most revealing question in the entire review, and it costs nothing to ask. A vendor who has deployed anything has examples. A vendor who has only demonstrated will change the subject.

The EU AI Act and GDPR covers the regulatory side of the same review, and where the agent stops covers the approval thresholds that the permission model enforces.