Every access control system ever built rests on one distinction so basic that nobody questions it. Read is safe, write is dangerous. Reading data does not change anything, so read access is the privilege you hand out freely. Writing changes the world, so write access is the one you guard. Analysts get read access to the warehouse. Integrations get read access to the records. Dashboards get read access to everything. It is fine, because reading cannot hurt you.
For AI agents, this distinction has quietly collapsed, and almost nobody has noticed. An agent with read access to sensitive data is not holding a safe privilege. It is holding, for every purpose that matters to your risk, write access. Read access is write access now, and continuing to treat the two as different tiers is one of the most dangerous assumptions in the way enterprises are deploying agents today.
This piece is about why the read write distinction breaks for agents, what it means that your "read-only" agent is not read-only in any way that protects you, and why the only thing that still governs risk is not the permission level but the action.
Why Read Was Ever Safe
It is worth being precise about why read access was considered safe in the first place, because the reason is exactly what agents remove.
Read access was safe because of who, and what, was doing the reading. A human analyst with read access reads slowly, reads what they need, and is bounded by their own intentions and their own throughput. A traditional integration with read access reads a fixed set of fields in a fixed way, its behaviour pinned by code. In both cases, the reader is a bounded actor whose reading leads to a small, predictable set of downstream effects. The data is read, and then something narrow and foreseeable happens with it.
The safety of read access was never a property of reading. It was a property of the reader. Reading is safe when the thing doing the reading cannot easily turn what it reads into consequential action. For humans and traditional software, that was true enough to build an entire security model on. The reader read, and the world did not change, because the reader had no fast, open ended path from information to action.
An agent is a fast, open ended path from information to action. That is the entire description of what an agent is. And the moment the reader becomes that, the safety of read access evaporates, because it was the reader's limitations that made reading safe, and the agent has none of them.
Read Access Is Exfiltration Access
Start with the most direct collapse. An agent that can read sensitive data and take any outbound action can exfiltrate that data, and almost every useful agent can take some outbound action.
The traditional assumption is that reading and leaking are separate problems. Reading is granted freely, and leaking is prevented by controlling the write and send paths. But an agent is a single actor that holds both. It reads the sensitive records, and it also has a tool that sends email, or calls an external API, or writes to a shared location, or posts to a channel. The read privilege and the outbound privilege live in the same actor, and the actor decides, at runtime, what to do. The wall between reading data and moving it, which in traditional systems was the separation between two different components with two different access grants, is gone. It is all one agent.
So the read grant you handed out casually, on the theory that reading is safe, is now one manipulated decision away from becoming a data breach. The agent reads the sensitive data, decides to send it somewhere, and sends it, all within its granted permissions, none of which included "write to the sensitive store," all of which felt safe. The exfiltration used only read access and a perfectly ordinary outbound tool. Nothing in the permission model flagged it, because the permission model still believes reading is safe.
Read Access Is Action, Because Agents Act on What They Read
The second collapse is subtler and worse. An agent does not just hold the data it reads. It reasons over it and acts on it. The data it reads becomes the input to its decisions, which means whoever controls what the agent reads controls what the agent does.
This is the mechanism behind indirect manipulation, and it turns read access into a control surface. If an agent reads a document, a record, a web page, or a message as part of its normal work, and that content can be influenced by an attacker, then the attacker can steer the agent's actions through the data the agent reads. The read is not passive. It is the channel through which instructions reach the agent. Grant an agent read access to a source an attacker can touch, and you have not granted a safe privilege, you have granted the attacker a path to the agent's behaviour.
Notice what this does to the read write distinction. The write, the consequential action, is still performed by the agent, but the thing that drives the write is the read. The dangerous action and the safe privilege are causally linked through the agent's reasoning. You guarded the write and gave away the read, and the read is how the attacker reaches the write. The tiers you separated are joined inside the agent, and the one you thought was safe is the one that carries the attack.
| Assumption from human and traditional systems | Reality for an AI agent |
|---|---|
| Reading does not change anything | Reading feeds decisions that change everything |
| Read and write are separate privileges | The same actor holds both and links them |
| Leaking is controlled at the write path | Read plus any outbound tool is a leak |
| Read-only is a safe default | Read-only is exfiltration and manipulation surface |
| The reader's intent bounds the risk | The agent's intent can be steered by the read |
Every row is the same collapse seen from a different angle. The distinction between read and write assumed a gap between information and action. The agent closes that gap. Once information flows straight into action through a manipulable reasoner, the privilege that grants information is a privilege over action.
Read Access Is Reconnaissance
There is a third collapse that matters even when no single read is sensitive on its own. Broad read access is reconnaissance, and reconnaissance is most of an attack.
Give an agent wide read access on the theory that reading is harmless, and you have given it, or whoever manipulates it, the ability to survey your entire environment, find the one valuable target, understand its context, and set up the single consequential action that matters. The classic security intuition that reading a lot of low value data is low risk assumes the reader cannot cheaply turn a survey into a targeted strike. The agent can. It reads everything, identifies what is worth taking or corrupting, and acts, and the reading was the part you did not guard because reading felt safe.
Aggregation compounds this. Data that is innocuous field by field becomes sensitive in bulk. A human reading records one at a time rarely assembles the aggregate. An agent reading at machine speed assembles it trivially. The read access you granted per record adds up to an exposure you never granted, because you were thinking about each read as safe and the agent was thinking about all of them at once.
the read grant you thought you gave what the agent can do with it
"just read the customer records" ─► survey every record at once
find the valuable target
aggregate the innocuous into sensitive
feed it all into its next action
send, act, or be steered by it
────────────────────────────────────────────────────────────────────────
a "safe" read-only grant an exfiltration, manipulation,
and reconnaissance surface
The Permission Model Cannot See This
Here is why this is not fixable by being more careful with permissions. The read write distinction is a property of the permission model, and the permission model operates at the wrong level to see the collapse.
A permission model grants access to resources. This actor may read this data, may write to that store, may call this API. It reasons about capabilities in the abstract, before any specific action happens. And at that level, read genuinely does look different from write. The problem is that the danger does not live at the level of capabilities. It lives at the level of specific actions taken in a specific context, and the permission model is blind to that level by design.
The permission model can tell you the agent is allowed to read the records and allowed to send email. It cannot tell you that this specific email, right now, contains the records it just read and is going to an external address. That is not a question about capabilities. It is a question about a specific action and its context, and the permission model, having granted both capabilities as individually safe, has nothing more to say. The two safe grants combine into an unsafe action, and the layer that hands out grants never sees actions at all.
This is why you cannot solve the collapse by tightening read permissions. Narrower read scopes help at the margin, but the fundamental issue is that any read access an agent holds is convertible into consequential action through the agent, and the permission model cannot govern the conversion because it does not operate where the conversion happens. It governs access. The risk is in the action.
Govern the Action, Not the Tier
If read and write are no longer meaningfully different as permission tiers, what does govern agent risk? The action itself, evaluated in context, at the moment it is taken.
The question that actually protects you is not "is this agent allowed to read this" or "is this agent allowed to write that." Those are the questions the collapsed model asks, and they pass the dangerous action, because each capability was granted as safe. The question that protects you is "should this specific action, with this specific content, in this specific context, given what this agent just did, be allowed to execute." That question sees the email that contains the records it just read. It sees the outbound call that follows a broad survey. It sees the write that was driven by a manipulated read. None of these are visible as permission grants, and all of them are visible as actions.
| Permission model (read vs write) | Action-level authorisation | |
|---|---|---|
| Governs | Access to resources, in the abstract | Specific actions, in context |
| Sees | Capabilities granted ahead of time | What the agent actually does |
| Read access | A safe tier, granted freely | An input to be judged by what follows |
| Catches exfiltration | No, read and send were both allowed | Yes, the action carries read data outbound |
| Catches manipulation | No, the write was permitted | Yes, the action traces to an untrusted read |
This is the shift the collapse forces. As long as you govern by tier, read access will keep being treated as safe, and it will keep being the privilege through which agents leak, get steered, and reconnoitre, because the tier cannot see what the read becomes. Only a control that evaluates the action, after the read has happened and before the consequence lands, can govern a world where reading and acting are the same motion.
The Distinction Was Never About Reading
Step back and the whole thing resolves into a single correction. The read write distinction was never really about reading versus writing. It was about a gap between knowing and doing, a gap that existed because the actors we built the model for could not easily cross it. Reading was safe because the reader was slow, bounded, and could not turn information into action at will. We attached the safety to the word read, but it belonged to the reader.
Agents are readers that cross the gap instantly. They turn what they know into what they do, at machine speed, driven by inputs an attacker can shape, holding both the read and the act in a single decision. For that kind of reader, there is no safe side of the old distinction. Reading is the first half of acting, and the privilege to read is a privilege to set the second half in motion.
Stop handing out read access to agents as though it were the safe tier. It is not a tier at all anymore. Every read an agent can perform is a read it can act on, send, aggregate, or be steered by, and the only place that danger is visible, and the only place it can be stopped, is at the action, evaluated in context, before it executes. Read access is write access. Govern it like it.
Xybern is the authorisation layer for enterprise AI agents. Every agent action is enforced, audited, and governed before it executes. Learn more at xybern.com or read the technical documentation at docs.xybern.com.