Read-only defaults reduce post-launch damage, but they do not stop code that runs before the main permission model applies. Teams often assume the permission banner is the control, when the real risk is any helper process or parser that executes first.
Why This Matters for Security Teams
Read-only defaults are often treated as a safe operating mode for agentic tools, but that assumption only holds after the full execution path is already trustworthy. The practical risk is not just what the agent can do after permission is denied, but what helper code, parsers, connectors, or retrieval layers can do before the main policy gate is reached. That gap matters because attacker-controlled input can still shape execution, exfiltrate data, or trigger side effects in adjacent components.
Current guidance from the NIST AI Risk Management Framework is clear that organisations should manage AI risk across the full lifecycle, not just at the point of user-visible action. For agentic systems, that means security teams need to assess tool invocation, message routing, file handling, and output processing as part of the control surface. The OWASP Agentic AI Top 10 also reflects this broader threat model by focusing on failure modes that appear before or around agent decision-making, not only on direct action permissions.
Security teams frequently get this wrong when they equate “read-only” with “no impact,” then discover that an apparently passive workflow still touched secrets, network services, or downstream automation. In practice, many security teams encounter damage only after a helper process has already executed, rather than through intentional agent action.
How It Works in Practice
Read-only defaults usually constrain the agent’s final action set, but they do not automatically constrain every component in the request path. An agent may still parse documents, resolve links, call retrieval services, inspect local files, or assemble prompts from untrusted content before the control layer decides whether a command is allowed. That is why the real question is not “Can the agent write?” but “What executes before the write check is enforced?”
In practice, teams should map the full chain: input ingestion, parsing, retrieval, tool selection, policy evaluation, execution, logging, and post-processing. Each step may have different trust assumptions. A read-only system can still leak data if a parser expands embedded references, if a connector returns overly broad context, or if prompt injection changes what the agent asks a tool to fetch. The MITRE ATLAS adversarial AI threat matrix is useful here because it frames the attack surface around adversarial influence on AI behaviour and supporting systems, not just model output.
- Separate policy checks from parsing and retrieval so untrusted content is never executed by helper logic.
- Apply least privilege to every connector, token, and service account used by the agent.
- Treat logs, caches, and memory stores as data-handling paths, not harmless telemetry.
- Validate tool inputs and outputs before downstream automation consumes them.
The NIST SP 800-53 Rev 5 Security and Privacy Controls remains relevant because access control, system integrity, audit logging, and information flow enforcement still need to be implemented at component level. These controls tend to break down when agent frameworks auto-wire plugins, parsers, and retrieval services into a shared runtime because the permission boundary becomes too late in the execution chain.
Common Variations and Edge Cases
Tighter read-only enforcement often increases operational overhead, requiring organisations to balance safer defaults against slower workflows, more exceptions, and extra review effort. That tradeoff is real, especially in environments where agents must inspect large document sets, ticketing systems, or code repositories to be useful.
One common edge case is a system that is read-only with respect to business applications but still highly permissive with respect to local files, temporary storage, or outbound network calls. Another is delegated execution, where the agent itself cannot write, but a paired service account, webhook, or automation runner can. Best practice is evolving here, and there is no universal standard for how much pre-execution parsing should be permitted before a request is considered trusted.
For higher-risk deployments, CSA MAESTRO agentic AI threat modeling framework is useful for identifying where control boundaries should sit across tools, memory, orchestration, and external dependencies. The strongest pattern is to make “read-only” one layer of a broader containment model rather than the headline control. Where the workflow includes untrusted documents, code interpretation, or externally supplied prompts, read-only defaults should be paired with strict sandboxing and explicit approval for any side-effecting helper.
Security teams also need to be careful with incident response assumptions. If a read-only agent can access sensitive data, then exfiltration and disclosure remain live risks even when modification is blocked. Current guidance suggests treating these systems as potentially interactive data processors, not passive viewers, especially when the agent can chain retrieval, summarisation, and external calls in one run.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | AI RMF addresses lifecycle AI risk, including pre-action controls. | |
| OWASP Agentic AI Top 10 | Agentic AI risks include prompt injection and tool misuse before action gates. | |
| MITRE ATLAS | AML.TA0001 | ATLAS covers adversarial influence on AI systems and supporting components. |
| NIST CSF 2.0 | PR.AA-1 | Identity and access governance still matter for agent connectors and service accounts. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege limits damage from helper processes and delegated automation. |
Threat model agent pipelines for adversarial input shaping, retrieval abuse, and tool manipulation.
