Read-only MCP access reduces damage, not telemetry exfiltration risk

At a glance

What this is: Repello AI argues that read-only MCP servers reduce destructive actions but do not stop sensitive observability data from being read, recombined, and forwarded through an agent session.

Why it matters: IAM and NHI teams should treat read-only access as a partial control only, because the governance problem shifts from write prevention to session containment, redaction, and outbound-path control.

Context

Model Context Protocol changes the control plane for AI agents by letting them connect to tools and data sources through explicit servers, rather than through ad hoc integrations. That creates a governance problem when the same session can mix sensitive read access with outbound-capable tools, because the boundary is no longer the server but the whole interaction path.

Read-only design is often treated as a safety feature, but it only limits what the server can do back to the source system. In this article's case, the real question is how an agent can read production telemetry from one system and then move it into another, which is the same containment problem that appears across MCP security and multi-tool agent workflows.

Key questions

Q: What breaks when an MCP server is read-only but connected to outbound tools?

A: 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.

Q: Why does read-only access not eliminate exfiltration risk in agent sessions?

A: Because exfiltration is usually a read followed by a forward. The agent can legitimately pull logs, traces, topology, or findings from one system and then pass that material into another connected tool. The security boundary therefore has to include the session and the connected-tool set, not just the original server.

Q: How should teams decide what telemetry an AI agent is allowed to see?

A: Start with least-necessary observability, not full-fidelity access. Limit the fields, services, and environments the agent can query, and treat any data that can reveal identity, privilege, incident detail, or architecture as sensitive. If the information would be dangerous in a ticket or chat transcript, it is dangerous in agent context too.

Q: How should security teams reduce prompt injection risk in AI agents?

A: Security teams should reduce prompt injection risk by constraining what enters the context window, limiting tool permissions, and separating untrusted retrieval content from privileged instructions. The practical goal is not perfect detection. It is to ensure that a successful injection cannot trigger wide data access, uncontrolled writes, or irreversible actions through a delegated identity.

Technical breakdown

Why read-only MCP servers still enable data exfiltration

A read-only MCP server prevents state changes on the source system, but it does not constrain how an agent uses what it reads. If logs, traces, topology, and findings are pulled into the model context, the data can then be forwarded to any other connected tool with outbound capability. In other words, the server is a source of information, not a security boundary. The critical issue is that exfiltration often looks like normal use: a legitimate read followed by a legitimate action elsewhere.

Practical implication: Treat the whole agent session as the trust boundary, not the individual server.

How observability data becomes high-value machine identity material

Observability systems often contain more sensitive material than teams assume. Logs can include email addresses, tokens, hostnames, and request bodies. Traces expose parameters and service relationships. Topology views reveal internal architecture, while incident history and security findings expose weak points and remediation gaps. For an attacker, that combination can replace weeks of reconnaissance with a documented tool call. For an agent, it creates a structured data source that is both operationally useful and highly sensitive.

Practical implication: Classify telemetry and findings as sensitive input to the agent, not as harmless debugging metadata.

Why prompt injection also applies to logs and traces

Observability data is not purely machine-generated. Application logs and traces frequently contain text chosen by outsiders, such as user agents, request paths, submitted values, and error messages that echo input. If an agent reads and acts on that content, then an attacker can place instructions or misleading text directly into the agent’s context. That makes logs a prompt-injection surface, even when the underlying server is behaving exactly as designed.

Practical implication: Filter untrusted text before context ingestion and treat logs as adversarial input.

Threat narrative

Attacker objective: Obtain sensitive production telemetry and structural security insight without needing to compromise the observability system itself.

1. Entry occurs when an agent is connected to a read-only observability server alongside one or more outbound-capable tools in the same session.
2. Credential or data access occurs when the agent legitimately retrieves logs, traces, topology, incident history, or security findings from the observability platform.
3. Exfiltration occurs when the agent forwards that information into another connected tool, turning the session into a data-movement path rather than a containment boundary.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Read-only design is a control, not a boundary. The article is right to separate destructive actions from information disclosure, because those are different failure modes. A server that cannot write still remains a high-value source if it exposes production telemetry, security findings, or incident history. That means governance has to move from permissions alone to session containment, data classification, and tool-pairing review.

Observability data is now an identity and privilege asset. Production logs, traces, and topology views are no longer just operational records when an agent can query them at machine speed. They encode service relationships, exposed tokens, and unresolved weaknesses, which makes them part of the machine-identity and access-control problem, not just the monitoring problem. Teams should treat telemetry as governed security data, not as a free debugging substrate.

Prompt injection is not limited to chat interfaces. Any system that ingests attacker-chosen text into an agent context can become an instruction channel, including logs, traces, ticket bodies, and alert payloads. That widens the agent threat surface well beyond the usual “tool misuse” conversation and places untrusted telemetry squarely inside the identity and trust boundary discussion. The practical conclusion is that content sanitisation must happen before the model sees the text.

MCP risk is now session-shaped rather than server-shaped. The dangerous unit is not a single integration, but the combination of a rich read source and an outbound destination in the same live context. That is why per-server audits miss the issue and why operator controls need to reason about the whole session graph. Practitioners should review connected-tool combinations as first-class security objects.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Telemetry governance is becoming an access-control problem. As more agents are allowed to inspect production logs and traces, teams will need to classify observability data with the same seriousness they apply to credentials and source code. The issue is not just what the agent can see, but where that information can be forwarded next, which is why connected-tool design now belongs in security reviews.

Session-level controls will matter more than per-tool approvals. A single tool can look safe on its own and still create a data path when paired with another tool in the same runtime. That shifts the programme focus toward session monitoring, egress constraints, and prompt-safety controls that apply across the full chain of agent actions.

Exfiltration path design should be treated as a named concept. In agentic environments, the danger is not merely exposure. It is the creation of an exfiltration path, where a legitimate read surface is coupled to an untrusted outbound destination. Teams should design controls to break that path before sensitive telemetry reaches context.

For practitioners

• Scope the MCP application key to the minimum telemetry surface Use a read-only key limited to the specific services or environments the agent actually needs, rather than granting broad observability access that turns debugging into wholesale telemetry collection.
• Redact sensitive fields before telemetry enters context Strip tokens, customer data, and other sensitive values on the response path so the model never receives them in the first place, rather than trying to clean them up after ingestion.
• Review connected tools as a single session graph Assess which outbound-capable tools sit beside observability access in the same agent session, because the exfiltration path is created by the combination, not by either server alone.
• Monitor for telemetry-to-outbound movement patterns Look for sessions that pull security findings, then service topology, then production logs, and then call another tool, because that sequence is the behavioural signature of data movement rather than normal troubleshooting.

Key takeaways

• Read-only MCP access reduces destructive change risk, but it does not stop an agent from moving sensitive telemetry into another tool.
• The most sensitive material in observability stacks often includes logs, traces, topology, incident history, and unresolved security findings.
• The control answer is session containment: narrow access, pre-context redaction, connected-tool review, and behavioural monitoring for read-then-forward patterns.

Related NHI Mgmt Group resources: MCP Security Guide · NHI Authentication Guide · AI Agent Observability, Audit and Incident Response Guide · Smithery.ai MCP hosting breach 2025

Key terms

• MCP session boundary: The effective security perimeter created by an AI agent session that connects multiple tools and data sources. When one tool can read sensitive material and another can send data outward, the session itself becomes the control object, not any individual server or API connection.
• Telemetry exfiltration: The movement of operational data out of its intended environment through a legitimate read and a subsequent forwarding action. In agentic workflows, the data may leave without a breach of the source system, which makes governance and monitoring harder than conventional compromise scenarios.
• Prompt injection in logs: A failure mode where attacker-chosen text inside logs, traces, or alerts influences an AI agent’s reasoning or actions. The content may look like ordinary operational output, but it is still untrusted input and must be sanitised before the model sees it.
• Observability data classification: The practice of assigning sensitivity and handling rules to logs, traces, topology data, and incident records. For agentic use cases, this classification should reflect what can be inferred from the data, not just what the system originally intended to store.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.