Article
An agent that reads and summarizes is forgiving; a wrong answer is embarrassing, not destructive. An agent that updates a subscription, issues a refund, or edits a record is a different category of system, because a mistake is not a bad response, it is a bad write. Most of the agent projects that stall in security review are trying to cross this line without the architecture it requires.
Start from read-only, and mean it
Every agent that will eventually write starts by shipping read-only, with its proposed actions logged but not executed. This is not caution for its own sake; it is how you build the evaluation set that tells you whether the agent's decisions are actually correct before any of them touch a record. Weeks of "here is what I would have done" logs, reviewed against what a human would have done, is the cheapest data you will ever collect on an agent's judgement.
Classify every write by reversibility
Not all writes carry the same risk. Updating a support ticket's status is easy to undo. Issuing a refund or deleting a record is not. We classify every action the agent can take into three tiers: auto-execute (fully reversible, low value at risk), approve-first (a human confirms before it runs), and never-automate (always a person, regardless of how confident the model is). This tiering is a business decision as much as a technical one, and it belongs in a document the client signs off on, not in a prompt.
The approval flow is part of the product
"Ask a human first" is not a fallback; it is a feature with its own UX. The approval surface needs to show what the agent wants to do, why, and what data it is based on, in language a non-technical reviewer can act on in seconds, not a JSON payload. Agents that generate approval requests nobody can parse train their reviewers to click approve without reading, which defeats the entire point of the tier.
Idempotency and reversibility, built in, not assumed
Every write action should be safe to retry without double-applying, and every write that can be should be paired with an undo. A refund action that checks whether it already ran before running again costs an extra query and prevents an entire class of incident. This is ordinary engineering discipline, not AI-specific, but agent systems retry more often than traditional ones because the calling logic is a model deciding to try again, not a developer who remembers it already tried once.
Log the decision, not just the action
When an agent writes something, the audit trail needs the action, the data it read to decide, and the reasoning it produced, in one record. "The agent refunded order 4471" is not an audit trail; "the agent refunded order 4471 because the customer's last three tickets mentioned a billing error and the amount matched the disputed charge" is. This is the same discipline as the observability layer any serious LLM application needs, applied specifically to actions with consequences.
Scope the tool, not just the prompt
The strongest guarantee is architectural: a database role or API scope that makes the disallowed action impossible, not merely discouraged. A tool that can only update the status column of tickets the agent's session owns cannot delete a customer record, no matter what the model is convinced to output. This is the same principle behind tenant isolation in a multi-agent platform: decide it in the schema and the tool boundary, not in the prompt, because prompts are guidance and schemas are guarantees.
What this buys
A write-capable agent built this way survives a security review, because every question it raises — what can it do, what happens when it's wrong, who signs off, what's the undo — has a concrete answer instead of a hope. That is the actual deliverable of AI Automation work that touches real data: not the agent, but the boundary around it.