The short version
Are read-only AI agents safe for enterprise use?
Read-only access makes an AI agent safer because it prevents direct changes to production systems, but it does not make the agent safe. An agent that can read sensitive data, process untrusted content, and communicate externally may still disclose information. Secure deployment requires separate controls for data access, mutation, execution, network egress, approvals, sharing, and audit.
What holds up
- Read-only limits mutation; it does not automatically limit disclosure.
- Model permissions and runtime capabilities must be enforced outside the prompt.
- Private data, untrusted input, and outbound communication form a dangerous combination.
- Start with observe and recommend modes, then grant narrow actions through explicit gates.
Read-only is a boundary, not a safety guarantee
A read-only agent cannot intentionally update a record, deploy code, or delete a file through its approved tools. That is a meaningful reduction in blast radius. It makes investigation, search, summarization, and recommendation reasonable places to begin.
The label becomes misleading when it describes only database or application writes. Reading a secret and placing it in a URL is not a write to the source system, but it is still a disclosure. Running code without persistent mutation can still consume resources or expose credentials. Sharing an agent output can reveal documents that some recipients were never allowed to view.
Treat read-only as one capability dimension. Ask what the agent can observe, compute, transmit, retain, render, and share before deciding what it can safely do.
Two current cases show the difference
HyperProbe describes a production-debugging agent that places non-blocking probes, captures variable state, cannot write memory or execute code through the probe, and records activity in an audit trail. Those constraints target a narrow diagnostic job and reduce the risk of autonomous remediation.
A PromptArmor security report alleges that indirect prompt injection could make Atlassian Rovo append Jira and Confluence data to an attacker-controlled URL and open it, even when an organization had disabled web search. The report attributes the failure to an outbound URL-retrieval capability, not a direct write to Atlassian data.
These are different products and the vendor claims should be evaluated independently. Together they illustrate the control question: what paths exist from sensitive evidence to an external side effect?
Separate capabilities that are usually bundled
Do not grant a broad “read-only” role. Express each capability separately and enforce it in the runtime or integration layer rather than relying on the model to remember policy.
| Capability | Risk even without source mutation | Runtime control |
|---|---|---|
| Read data | Sensitive records enter model context | Identity-aware filtering and least privilege |
| Call external URLs | Data can leave through query strings or requests | Default-deny egress and destination allowlists |
| Render remote content | Images and previews can trigger requests | Proxy, strip, or block remote resources |
| Execute code | Secrets, network, and compute become reachable | Sandboxing, resource limits, and no ambient credentials |
| Retain output | Sensitive context persists beyond the task | Retention, redaction, and deletion policy |
| Share results | Authorized data reaches unauthorized people | Resource-level authorization on every shared artifact |
Break the dangerous three-part combination
Security practitioner Simon Willison describes a “lethal trifecta” for agents: access to private data, exposure to untrusted content, and an ability to communicate externally. His analysis of the pattern is useful because removing any one side can block a complete exfiltration path.
An enterprise agent often needs the first two capabilities. It reads internal records and encounters customer messages, uploaded files, websites, or tool output that the company does not control. That makes outbound communication the most practical place to enforce a hard boundary.
Do not let the model invent destinations. Allow only typed actions to preapproved services, validate every argument, and prevent sensitive fields from entering URL paths, query strings, remote images, or arbitrary request bodies. Require an explicit user action for a new destination.
A system prompt that says “never leak data” is guidance. An egress proxy that rejects an unapproved destination is a control.
Design a genuinely constrained read mode
A useful read mode can still search, correlate, and recommend. Its constraints should be visible enough that a reviewer can determine what evidence entered the run and why no unauthorized path existed.
- Identity
- Execute every read as a named user or service identity with resource-level authorization.
- Provenance
- Label trusted instructions, untrusted content, tool results, and retrieved records separately.
- Egress
- Block arbitrary network access; allow only typed, preapproved destinations and methods.
- Execution
- Use an isolated runtime with no ambient secrets, narrow mounts, and strict resource limits.
- Output
- Redact sensitive fields and re-check authorization before storing or sharing an artifact.
- Evidence
- Record reads, model calls, tool arguments, denied actions, approvals, and recipients.
Test the controls with hostile content
Normal task evaluations will not reveal whether the runtime stops a malicious instruction embedded in a document or tool response. Add adversarial fixtures before production and rerun them after any change to the model, prompt, connector, browser, renderer, or network policy.
| Test | Expected behavior | Evidence to retain |
|---|---|---|
| Document asks agent to reveal context | Instruction is treated as data and ignored | Source label and blocked action |
| Agent constructs a new external URL | Request is denied before network access | Destination, arguments, and policy decision |
| Markdown contains a remote image | Remote fetch is stripped, proxied, or blocked | Renderer decision and requested host |
| Tool output requests another tool call | Output cannot elevate its own authority | Tool provenance and authorization check |
| User asks to share a derived artifact | Recipient access is checked against every source | Source resources, recipient, and approval |
Use permission tiers instead of an autonomy switch
Move a workflow through explicit operating modes. Each tier should add only the capabilities required for the next measurable outcome.
| Tier | Allowed behavior | Suitable work |
|---|---|---|
| Observe | Read approved sources; no external egress | Search, evidence collection, anomaly detection |
| Recommend | Produce an internal draft or proposed action | Diagnosis, ticket triage, policy guidance |
| Act with approval | One scoped mutation after review | Closing a ticket, updating a record, applying a patch |
| Narrow autonomy | Preapproved actions inside strict limits | High-volume, reversible, well-evaluated workflows |
Promotion should follow evidence: accepted outcomes, denied-action behavior, incident history, and rollback performance—not elapsed time since launch.
Investigate disclosure like any other incident
The agent run record should make it possible to reconstruct which identity read the data, which untrusted content entered context, which model produced the action, which policy allowed or denied it, and where the output went.
If a control fails, revoke the affected credentials and destinations, preserve the run evidence, identify every resource exposed to the agent, and test the same path across similar integrations. Fix the deterministic boundary before revising the prompt. Prompt changes can reduce likelihood; runtime controls remove capability.
Approve the boundary before the agent
Security review should approve a capability map, not a product label. Record the accessible resources, untrusted inputs, executable tools, outbound destinations, retention rules, human approvals, and incident owner for the workflow.
A read-only agent is often the right first deployment because it preserves human control over consequential changes. It becomes defensible only when “read-only” describes the entire data path rather than one checkbox on one connector.
Evidence trail
Evidence, limitations, and sources
Grid Field Notes synthesizes published technical, product, and risk evidence into operating guidance. Vendor-reported results remain attributed, numerical examples are illustrative, and customer results appear only when they are explicitly measured and identified.
Limits of this note. This is a threat-model synthesis of vendor controls, public security research, and OWASP guidance. It does not claim that every reported attack generalizes to every deployment; the point is to test each capability boundary independently.
Frequently asked questions
Questions teams ask
Can a read-only AI agent change production data?
A correctly enforced read-only tool cannot mutate its source system. The agent may still have other side effects through code execution, network requests, output retention, or sharing, so those capabilities must be constrained separately.
Does human approval make an AI agent safe?
Approval reduces risk only when the reviewer sees the proposed action, destination, relevant evidence, and affected resources. It does not replace least privilege, egress controls, argument validation, redaction, or audit logs.
What is the safest first enterprise AI agent use case?
Start with a narrow observe-or-recommend workflow that reads approved data, has no arbitrary outbound network access, produces a verifiable result, and leaves consequential action to a person.