When an AI agent should be allowed to write, and what guards it

The sales team already uses an AI assistant to read pipeline data and prepare account summaries. The next request sounds modest: let it update the next follow-up date after a call. Then finance asks whether it can prepare a credit note. Operations wants it to reschedule a delivery. These actions do not carry the same risk, and "the agent has write access" is too blunt a way to describe any of them.

A useful agent does not need unrestricted access to become useful. It needs a small catalogue of approved actions, each protected by application controls that work even when the model makes a poor suggestion.

Reading and acting are different products

A read-only assistant can produce a wrong explanation, but it cannot change a record by itself. A writing agent can create a second consequence. The risk comes from both the quality of the decision and the authority attached to it.

That does not mean every write needs a human click. It means the business should decide which actions may run automatically, which require approval and which remain outside the agent's scope. The decision depends on reversibility, financial value, customer impact and the confidence available from deterministic checks.

Define an action contract

Each approved action needs a contract that names what the agent may request and what the application will enforce. This contract is code and configuration, not prose inside a prompt.

An action called update_follow_up_date might accept one customer identifier, one date and one reason. The application checks that the customer exists, the user may access that account, the date falls within an allowed range and the current record has not changed since the agent read it. The agent cannot add a new field or switch to another operation.

This narrow shape makes the action testable. It also lets security and business owners review the exact authority without reading a model conversation.

Put policy between the proposal and the system

The model proposes an action with its reason and supporting evidence. A policy service then checks the request against user permissions, action limits, business rules and current system state. The model does not decide whether its own proposal is allowed.

Policies should be concrete. A delivery-date change may stay within the same calendar week unless a manager approves it. A discount may have a maximum percentage by role. A communication may use only approved templates and verified recipients.

If the policy cannot reach a clear decision, it holds the request for review. The user sees what the agent wants to do, why, which records will change and which checks passed.

Use approval where judgement or impact remains

Approval is valuable when it gives the reviewer a real decision. A screen that asks someone to approve every harmless task will be clicked through without thought. A screen that hides the changed fields forces the reviewer to repeat the agent's work.

Show the current value, proposed value, reason, source evidence and policy result. For financial actions, preserve separation of duties so the person who requests or configures the action cannot also approve every outcome.

Low-risk actions can earn less supervision after they have a clean operating history. That change should be deliberate. Review the audit record, failure rate and recovery cases before changing an action from approval to automatic execution.

Make execution safe to retry

Networks time out. Users click twice. A service may complete an action but fail before returning the result. Without a retry design, the same request can create two tasks, two bookings or two financial entries.

An idempotency key gives one business request one identity. If the application receives the same approved request again, it returns the original outcome rather than performing the action twice. The service should also compare the current record version with the version the agent used. If another person changed the record in the meantime, the action stops and asks for a fresh decision.

Audit the whole decision, then plan recovery

A useful audit record includes the user, agent version, proposal, source evidence, policy result, approver, exact request sent to the business system and final response. It should also link to the record state before and after the action.

Recovery depends on the action. Some changes can be reversed directly. Others require a compensating action, such as issuing a cancellation rather than deleting a posted document. The application should know which method applies before the action is enabled.

A kill switch must stop new actions without disabling read-only access or hiding existing audit records. Rate limits and financial caps can contain impact while the team investigates unusual activity.

A responsible rollout sequence

1. List the actions people repeat today and rank them by impact and reversibility.
2. Select one narrow, reversible action with a clear business owner.
3. Write its action contract and enforce permissions in the target system or integration service.
4. Build validation, policy checks, idempotency, audit and recovery.
5. Run the agent in proposal-only mode and compare its suggestions with human decisions.
6. Enable approval-based execution for a limited user group.
7. Review errors and near misses before considering any automatic path.

This sequence creates evidence without asking the organisation to trust a general autonomous agent. Every new action repeats the same review. Authority grows by capability, not by handing the model a broader account.

Questions to approve before an agent can act

• What exact operation may the agent request?
• Which identity executes it, and what is that identity unable to do?
• Which fields, values and targets does the application validate?
• When is human approval mandatory?
• How does the service prevent duplicate execution?
• What happens if the record changed after the agent read it?
• How can the business reverse or compensate for the action?
• Can one switch stop new actions while preserving read-only service and audit evidence?

The examples describe control patterns, not permission to automate any specific financial or regulated process. Each action requires a risk and authority review in the target environment.