Prompt injection in telemetry: how an SRE agent deployed the wrong fix

An AI agent investigating an application fault needs evidence: logs, traces and health signals. Those records can also contain text supplied by someone outside the organisation. When that text includes a plausible repair plan, the agent can mistake an attacker's suggestion for permission to change infrastructure.

Eduardo Arrucha of Straiker STAR Labs explored that failure in research published on 24 August 2026. In a controlled demonstration, poisoned telemetry steered an Amazon Bedrock-powered SRE agent into deploying a privileged Kubernetes workload. The researchers then reported host access, encrypted application files and a storefront replaced with a ransom page.

The setting was a lab. The article does not report a customer breach or an Amazon Bedrock service vulnerability, and states no CVE or vendor patch. Its subject is the combination of untrusted context, operational permissions and missing enforcement around an autonomous agent.

How telemetry acquired apparent authority

The demonstration used a coffee-shop application running on Amazon EKS. Its site reliability engineering agent could inspect the application and apply Kubernetes manifests to resolve infrastructure problems. That gave it a legitimate reason to read monitoring records and a powerful means of acting on them.

The attacker-controlled content entered through application input that appeared in the agent's monitoring context. It imitated an OpenTelemetry health record, combining a fabricated observer failure with apparently corroborating signals. Alongside the diagnosis sat a remediation plan and a proposed workload definition.

That packaging mattered. An operational record already belonged in the agent's investigation. Familiar telemetry structure, consistent-looking evidence and observability labels made the proposed repair appear related to its task. The trust boundary failed when content describing an incident became authority for the response.

This is indirect prompt injection: an adversary influences an agent through material it encounters while serving a legitimate user. Here, the material was monitoring context. The embedded instructions redirected the agent's infrastructure tools towards the attacker's objective.

A proposed repair became a privileged workload

According to Straiker, the agent accepted the apparent remediation and created the supplied workload. The workload's permissions exposed the underlying host, while the namespace lacked admission policies that would reject the dangerous configuration.

The demonstration therefore crossed two consequential boundaries. First, externally influenced telemetry shaped a tool action. Second, the Kubernetes environment admitted a workload capable of reaching beyond its ordinary application container. The agent's existing permissions connected those boundaries.

Straiker also describes the workload using the application's legitimate container image, with malicious behaviour introduced at runtime. That detail matters for defenders: approving an image leaves other deployment properties to inspect, including startup behaviour, requested privileges and host access. An image allowlist alone cannot express all those decisions.

Our prompt injection examples cover other ways ordinary agent inputs can carry hostile instructions. Telemetry deserves the same scrutiny as retrieved pages, documents and repository files, even when it arrives through a familiar monitoring pipeline.

What the ransomware demonstration established

The reported lab chain reached the host and encrypted application files. It also replaced the storefront with a ransom page. A persistence mechanism repeatedly interfered with the SRE agent's attempts to restore service for approximately 20 minutes. The researchers deliberately ended that mechanism to allow demonstration recovery.

Straiker says the ransomware was confined to pods within one Kubernetes namespace as a lab constraint. The article separately discusses a possible wider cloud compromise involving node credentials, cloud storage and additional nodes. Those extensions are hypothetical scenarios. Their feasibility would depend on the environment's actual permissions and controls.

The published account provides a concrete example of a prompt injection attack reaching infrastructure through an agent. It does not establish a universal success rate, prove that every SRE agent is vulnerable, or show a compromise of the Bedrock service. The results discussed here are the researchers' reported demonstration; we have not independently reproduced it.

Put checks between a diagnosis and its side effects

The defensive question is specific: what may this agent change after reading attacker-influenced evidence? Teams can answer it at several boundaries.

• Preserve input provenance. Keep externally supplied application values distinguishable from operator instructions and approved runbooks. Validate and inspect telemetry before it enters agent context, while assuming some hostile content can still reach the model.
• Separate investigation from execution. Give diagnostic agents read-only access where possible. Expose narrowly scoped remediation operations for the changes they genuinely need to make.
• Enforce workload restrictions at admission. Limit Kubernetes permissions and apply policies that reject prohibited host access and dangerous security settings. Kubernetes RBAC governs which operations an identity may request; admission policy can constrain the workload being requested.
• Review the exact change. Require approval for high-impact operations, showing the affected resources and requested privileges. An incident summary or reassuring repair label is insufficient context for that decision.
• Check the resulting state. Record the proposed action, policy outcome and execution result separately. Monitor for unexpected workloads and repeated interference with recovery.

These controls complement the practices in our guide to securing LLM agents. They reduce the authority available to a mistaken decision and provide independent checks before it changes the environment.

Operational data needs an explicit trust boundary

The Amazon Kiro prompt-injection case involved repository content influencing local actions. Straiker's SRE demonstration applies the same boundary question to infrastructure monitoring: can material the agent is meant to inspect also tell it what to execute?

For teams deploying autonomous remediation, inventory every externally influenced field the agent reads, then trace the actions it can initiate. A telemetry record may justify further investigation. Permission to deploy a privileged workload needs a separate, enforceable decision.

Sources

• Escape from Pod 9: How Prompt Injection Turned an AI SRE Agent into a Kubernetes Ransomware Attack Vector, Eduardo Arrucha, Straiker STAR Labs, 24 August 2026.