--- title: What read-only AI agents can still break canonical: "https://subarashi.dev/posts/2026-05-27-what-read-only-ai-agents-can-still-break/" pubDate: "2026-05-27T00:00:00.000Z" author: Cara description: "Cara explains why read-only AI agents still need safety design around data exposure, rate limits, stale context, and trust." tags: [AI, Workflow] --- Read-only is safer. It is not harmless. That distinction matters because "just give the agent read access" has become the easy answer when a team wants AI help without the anxiety of write permissions. It is a good starting point. It is not the end of the design. A read-only agent can still leak information, overload systems, misread stale context, and create bad decisions that humans treat as reviewed work. The agent did not write to production. Fine. It can still break the workflow around production. ## The problem Teams often treat read access as if it has no blast radius. That works only if the data is boring, the system is small, the agent never calls external tools, and nobody trusts the output too much. Real workflows are messier. A read-only agent might inspect: - repository files - customer notes - logs with secrets - CI output - vulnerability reports - invoices or usage data - internal roadmaps - private email or support threads None of that requires write access to become sensitive. If the agent summarizes the wrong thing into the wrong channel, stores snippets in the wrong place, or sends context to a tool that should not see it, read-only just became a data-handling problem. ## What read-only can still break The first risk is exposure. An agent that can read too broadly can quote too broadly. It can pull credentials from logs, paste private customer details into a report, or include internal implementation notes in a public draft. The damage comes from movement, not mutation. The second risk is volume. Read-only tools can still hammer APIs, exhaust rate limits, trigger abuse detection, or make a build system noisy. A crawler with no write permission can still behave like a small denial-of-service if it reads without restraint. The third risk is stale context. An agent can confidently summarize an old file, cached page, outdated branch, or closed issue. If the team treats that summary as current, the workflow breaks at the decision layer. No files changed, but the wrong plan moved forward. The fourth risk is authority laundering. When a report says "the agent reviewed this," humans may relax. The result can sound more complete than it is. Read-only agents are especially good at producing confident summaries of partial evidence. That is a workflow risk, not a model personality flaw. ## The rule of thumb Read-only agents still need scope, budgets, and provenance. A safer read-only agent should answer three questions every time: 1. What was it allowed to read? 2. What did it actually read? 3. What did it not verify? That third line is the valuable one. If an agent says "I checked the repo," the statement is too broad. If it says "I checked the Astro pages, content collection, smoke test, and latest build output, but not production analytics," the team can reason about the finding. This is the same permission logic behind [designing AI agent permissions before tools](/posts/2026-05-27-how-to-design-ai-agent-permissions-before-you-give-them-tools/). Reading is a permission too. ## A practical review checklist Before giving an agent read-only access, define the boundaries. Check: - Which directories, mailboxes, repos, or dashboards can it inspect? - Which paths are excluded even for reading? - Can it quote raw text, or only summarize? - Can it send context to external tools? - Are secrets, tokens, and personal data filtered before the agent sees them? - Is there a request budget or rate limit? - Does the report name the sources it used? - Does the report name the sources it did not check? This is not bureaucracy. It is how read-only work becomes reusable instead of spooky. ## What to watch for The most dangerous phrase is "it only reads." That phrase can hide a lot: - it only reads the whole repository - it only reads production logs - it only reads private support mail - it only reads every issue and PR - it only reads a billing dashboard Scope still matters. Another trap is treating read-only agents as reviewers. A reviewer is responsible for judgment. A read-only agent can assist review, but it should not become the review boundary unless the organization has explicitly designed that role. The final trap is letting summaries replace evidence. Good summaries should point back to sources, uncertainty, and next checks. If they do not, they become confident fog. ## Verdict Read-only is the right default for many AI agents. It reduces the chance of direct mutation. It makes exploration easier. It lets teams get value before handing over write permissions. But read-only is still access. It needs scoping, rate limits, data-handling rules, source trails, and honest uncertainty. The safe version is not "the agent cannot write, so we are done." The safe version is "the agent can read this much, report this way, and stop here."