The meeting is always the same. Somebody demos an agent that works, somebody from IT asks what access it will need, and the answer — "it would have to update the status in the ERP" — turns a fifteen-minute demo into an agenda item for a committee that meets every three weeks. From that moment on, the project calendar is no longer set by the person who built it.
The thesis in one line: AI agent write permissions are not a security checkbox you tick at the end of the design. They are the variable that moves the cost and the timeline of everything else the most. A read-only agent ships in weeks and gets approved without drama. The moment it writes into a system of record you inherit approvals, rollback, reconciliation and audit, and the project changes league. Decide that checkbox first, not last, because the rest of the budget hangs off it.
AI agent write permissions are not a security decision: they are the most expensive line item
Security convenes the conversation, so it gets framed in security language: threats, attack surface, least privilege. That framing is correct and incomplete. The expensive part of letting an agent write is not the risk of somebody hijacking it — that risk is real and you bound it with access design, which is a different conversation. The expensive part is everything you have to build around the write so it becomes acceptable: a way back when the agent gets it wrong, a way to know that it got it wrong, and somebody with a name who answers for what ended up written.
That is the change of league. A read-only agent needs query access and somewhere to leave the output. An agent that writes needs, at minimum, four pieces that almost never make it into the budget: a way to undo each action, a periodic reconciliation that catches what was written badly without anybody noticing, an exception queue with a person watching it, and a per-action trail that lets you reconstruct what happened three months later. None of the four is the agent. All four get paid for anyway.
The access design itself — the matrix of what it reads, what it writes, what it executes and what it never touches — we lay out in what permissions to give an AI agent. What we add here is the layer above it, the one argued in the budget meeting rather than the architecture one: what each answer in that matrix costs you.
What a read-only agent actually delivers
The immediate objection is that an agent that cannot write is useless. It is false, and it is one of those beliefs that survives because nobody stops to list the opposite. With read access only, and without touching a single row in any system, an agent delivers things that today burn hours of expensive people:
- Preparing the decision instead of making it: the full case file, with history, attachments and the three numbers that matter, ready for a person to resolve in two minutes what used to take twenty.
- Spotting what nobody watches: contracts about to lapse, stalled orders, customers with forty days of no activity, mismatches between two systems that should be saying the same thing.
- Writing the draft: the email, the report, the tender response, the candidate summary. The text gets generated in full and a human sends it, which is exactly where the work was.
- Answering questions about scattered data: what lives in the ERP, in the CRM and in a network folder, answered in one line with a link to the source.
- Policing the quality of what other people write: comparing what was recorded against what was documented and raising a hand when they disagree.
Note what the five have in common: the agent produces and a person disposes. The saving is real — searching, gathering, comparing and drafting is the bulk of many processes — and the worst case is that somebody reads something wrong and fixes it before acting. That is why these projects get approved in one meeting instead of three: there is nothing to undo.
What shows up the minute the agent writes
The line is not gradual: you cross it all at once. The moment an agent action is recorded in a system the company answers for, five things change that were not in the project before.
| What changes | Read-only agent | Agent writing into a system of record |
|---|---|---|
| Who approves | The process owner, sometimes their boss | A committee: IT, risk, data protection and, if money is involved, internal audit |
| What you build besides the agent | Query access and somewhere to leave the output | Per-action undo, periodic reconciliation, exception queue and a reconstructable trail |
| What happens when it gets it wrong | Somebody reads something wrong and fixes it before acting | The error is already inside and has triggered whatever came next: a customer notice, a payment, a journal entry |
| How long until it is live | Weeks | Months, and the bulk of the calendar is not building the agent |
| What the EU regulator requires if the use case is high-risk | Little: the agent decides nothing on its own | Effective human oversight, with the ability to override the output and stop the system |
That last row is not rhetoric. In the European Union, Article 14 of the AI Act requires high-risk systems to be designed so that the people assigned to oversight can decide not to use the system, disregard, override or reverse its output, and can interrupt it through a stop button or an equivalent procedure. Source: Article 14 — Human oversight, Regulation (EU) 2024/1689. (Scope: the European Union, and only for systems classified as high-risk. If you operate in the EU market it reaches you wherever you are based. A read-and-propose agent rarely lands in that category; one that executes on people frequently does.)
Read backwards, that article is a technical shopping list: override, reverse, stop. If your agent writes and you cannot answer how each of the three is done, you do not have a compliance item for later. You have three pieces unbuilt and unbudgeted.
The three middle patterns almost nobody puts on the table
The discussion gets framed as a switch — reads or writes — and that is where the money goes, because between the two extremes sit three middle positions that deliver most of the value of writing at a fraction of its approval cost.
1. The draft a human confirms
The agent leaves the action ready and somebody presses the button. The email drafted in the outbox, the order created in draft status, the journal entry proposed and not posted. Technically the agent writes, but it writes into a state that has no effect, and that changes everything in the approval conversation: there is nothing to undo because nothing has happened yet. The cost is a person confirming, which is cheap at low volume and becomes expensive exactly when the system has already proven it gets it right. That is the moment to move up a rung, not before.
2. Writing into a staging area
The agent really does write, but into a table, a space or an environment that is its own and that nobody else depends on. Another process — often one that already existed — picks up from there and carries it into the real system with its own validations. It is the pattern proposed least often and the one that clears committees fastest, because the system of record keeps its entry controls intact: the agent is not a privileged user, it is one more data source, and companies already know how to treat data sources.
3. Reversible writes with an undo window
The agent acts directly, but only on actions with a way back that can be described in one sentence, and during a window in which undoing costs nothing. Changing an order status is reversible; issuing the invoice for that order is not. The working rule is blunt and useful: an action is only automated without confirmation if somebody can explain in one sentence how it gets undone. If the sentence does not exist, the action stays in pattern 1. The criteria for climbing — volume of cases seen, human correction rate and reversibility — are laid out in the autonomy levels of an agent.
How to negotiate the jump in phases
The most common negotiating mistake is asking for write access on proposal day, when the agent has proven nothing and the person who has to approve it has not one data point to decide with. You ask at the worst possible moment: maximum uncertainty, minimum evidence. The outcome is predictable — a committee, three weeks, a list of conditions — and it is usually the point at which the project starts dying of boredom.
The alternative is to start read-only and walk into the expansion meeting with three numbers that did not exist before: how many cases the agent has seen, what share of the time the human changed what it proposed, and how many of those corrections were judgment rather than data. With that, the conversation stops being about trust and becomes about evidence, which is terrain committees move well on. And what you ask for is not "let it write" but a short list of specific actions, each with its own sentence on how it gets undone.
It also pays to write down from day one the list of what never moves up, however much evidence piles up: anything irreversible, anything touching other people money, anything customer-visible without review, and anything affecting a person rights. Putting that limit in writing on day one is what lets you negotiate everything else comfortably, because it shows the proposal has brakes and not just an accelerator.
The market is already paying this bill
That this is not an architect hobby-horse is suggested by the size of the waste. Gartner predicts that over 40% of agentic AI projects will be cancelled before the end of 2027, and names three causes: escalating costs, unclear business value and inadequate risk controls. Source: Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027, Gartner, 25 June 2025. (Scope: the firm global forecast, not a result of ours. It sizes the problem; it is not what we deliver.)
The three causes are the same thing seen from three angles. A project that assumes writing discovers late what the controls that writing demands actually cost, and that late discovery is simultaneously the overrun, the delay that erodes perceived value, and the risk control that arrived after the design. The read-or-write decision, taken on day one and in writing, is what separates a project that ships from one that gets cancelled with the budget already spent.
Once several agents are live, this stops being a per-project decision and becomes a function: who authorises each scope expansion, on what evidence, what gets recorded and who answers for it. That continuous function is what we build in governing the AI agents in your company; this article is the specific decision that makes it necessary.
Decide first whether it writes
If you have an agent proposal on the table today, one question gets answered before the rest and before you look at a single price: does this agent write into any system we answer for? If the answer is no, the project is short, the risk is a reading risk and the approval fits in one meeting. If the answer is yes, the budget in front of you is incomplete, because it does not include undoing, reconciling, handling exceptions or leaving a trail. And if the answer is "well, later on", make it an explicit no for phase one and a list of specific actions for phase two.