Read-only stops the server from making changes back to its source system, but it does not stop the agent from forwarding what it reads somewhere else. The failure is not destructive action. It is uncontrolled data movement across a session that combines sensitive telemetry access with an outbound path.
What stays safe, and what still escapes through an outbound tool chain?
The read-only boundary only protects the source system the mcp server is attached to. Once the server can hand data to outbound tools, the real trust boundary moves to the tool path, the session, and whatever external system receives the read. That means the control problem shifts from write protection to data egress control, session scope, and tool permissioning.
In practice, the server can be harmless to its source of record and still be risky as a relay. A read-only MCP server may expose logs, tickets, configs, status pages, or other sensitive telemetry, and an agent that can call outbound tools can package that material into prompts, API requests, files, chats, or tickets elsewhere.
Why read-only is not the same as non-exfiltrating
Read-only limits state change, not disclosure. If the agent can see data and has an outbound path, it can still forward secrets, identifiers, incident details, environment data, or operational context to another destination with very different trust and retention rules. That is why the dangerous part is often the combination of read access, transformation, and egress, not the write capability at the original server.
The key design question is whether the outbound tool is scoped to the same sensitivity boundary as the input. If not, the system can create an accidental export channel even when every individual component appears low risk on its own. This is especially relevant when tool output is copied into long-lived systems, shared workspaces, or vendor services.
Which control boundary actually needs to hold
The safest interpretation is that the MCP session is a data-handling workflow, not just a connector. MCP Security Guide is the practical place to anchor that model: authorization, token handling, gateway design, and the danger of token passthrough all matter when a server can read sensitive material and still reach out through tools.
Outbound tools should be treated as separate destinations with their own authorization and data-minimisation rules, not as a free extension of the read-only server. Where the path includes agentic tool use, AI Agent Tool and Plugin Security Guide is relevant because the practical failure mode is scoped tool abuse, excessive tool permissions, or unvalidated tool output carrying sensitive data onward.
When the tool chain is part of an agentic application, the broader risk pattern also aligns with OWASP Agentic AI Top 10, especially the interaction between identity, privilege, and tool use rather than any destructive change at the source server.
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 OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Outbound tool use makes privilege boundaries central to the leakage path. |
| ASI02 — Tool Misuse | The issue is a tool-driven forwarding path, not source-system modification. | |
| Recommendation — Constrain agent permissions so read access cannot be repurposed into uncontrolled data egress. Validate tool targets and outputs before allowing agents to pass sensitive data onward. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | An overly permissive outbound path can expose data despite read-only source access. |
| Recommendation — Harden API and tool endpoints so data cannot leave the session without explicit control. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege must cover both what is read and where read data may be sent. |
| AU-6 — Audit Review, Analysis, and Reporting | Session logging is needed to detect when read data is forwarded out of bounds. | |
| SC-7 — Boundary Protection | The outbound tool path is the real trust boundary that needs enforcement. | |
| Recommendation — Limit each tool and destination to the minimum permissions needed for the workflow. Review logs for sensitive data forwarding and abnormal tool destinations. Segment and control session egress so read access does not become unrestricted export. | ||
Practitioner Guidance
What to verify: Confirm whether the agent can send raw read results to any external tool, and whether that tool is allowed to store, log, or redistribute the content. A read-only server with an unrestricted outbound path is still an exfiltration-capable design if sensitive data can cross the session boundary.
Decision rule: If the server can read sensitive telemetry, require a separate approval point for every outbound destination that can receive that data. If you cannot explain where the data may go after it leaves the source system, treat the workflow as uncontrolled egress.
What practitioners underestimate: The failure usually shows up as indirect leakage, not obvious vandalism. The source system stays unchanged while the sensitive material is forwarded into a lower-trust system, which makes the problem harder to spot in normal change-management or integrity checks.
Practitioner takeaway: Read-only is only a safe property when the session cannot repurpose what it reads. Once outbound tools exist, the control objective becomes containment of disclosure, not prevention of writes.
Related resources from NHI Mgmt Group
- What breaks when MCP tools are exposed through one shared server?
- What breaks when DLP does not cover generative AI workflows and MCP-connected tools?
- What breaks when MCP tools rely on the UI instead of server-side authorization?
- What breaks when MCP tools are approved at the server level but not at the tool level?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org