Escape from Pod 9: How Prompt Injection Turned an AI SRE Agent into a Kubernetes Ransomware Attack Vector

At 15:02 UTC, the Brewhaus Coffee storefront went dark. In its place: a ransom demand, AES encrypted application files, and a 20-minute persistence window that defeated every automated recovery attempt.

The culprit? Company's own SRE agent.

What happened? 

A crafted telemetry record containing a prompt injection payload was sent to an e-commerce application monitored by an AI SRE agent built on Amazon Bedrock. The agent, designed to autonomously remediate infrastructure issues, interpreted the poisoned telemetry as a legitimate OpenTelemetry alert and deployed a privileged container as part of its "remediation." That container escaped to the underlying host, encrypted application files with AES-256-CBC, replaced the storefront with a ransom page, and maintained persistence for 20 minutes against the agent's own recovery attempts.

Why it matters

This demonstrates that autonomous AI agents with infrastructure permissions can be weaponized through indirect prompt injection—turning the remediation system itself into the attack vector. The agent's own trust model and operational permissions became the vulnerability. The attack requires no credentials, no prior access, and no exploitation of any software vulnerability. A single HTTP request is enough.

So what? 

The vulnerability is not in Amazon Bedrock or the underlying foundation model. It is in the agent's design: overprivileged Kubernetes permissions, absence of input sanitization on telemetry data, and no admission control policies preventing privileged workload creation. This pattern exists in every organization deploying autonomous AI agents with infrastructure access.

The Target: An AI-Monitored E-Commerce Application

Brewhaus Coffee runs a checkout application on Amazon EKS. An SRE agent powered by Amazon Bedrock monitors the application around the clock. The agent has a clear mandate: detect infrastructure anomalies, diagnose root causes, and remediate them autonomously. It has kubectl access to the production namespace—it can read logs, inspect deployments, and apply Kubernetes manifests to restore service health.

This is the pattern enterprises are adopting: AI agents with operational permissions, trusted to act without human approval for speed. The agent is good at its job. It has resolved dozens of incidents—restarting unhealthy pods, scaling deployments, rolling back bad releases.

The question this research answers: what happens when someone poisons the data the agent trusts?

‍

The Agentic Attack Kill Chain

AI Agent Ransomware Attack Chain at a Glance

1. HTTP request → 2. Poisoned telemetry → 3. Prompt injection → 4. AI SRE agent interprets telemetry → 5. Malicious Kubernetes manifest → 6. Privileged container → 7. Container escape → 8. Host access → 9. Ransomware → 10. Watchdog persistence

How the AI SRE Agent Was Compromised Through Poisoned Telemetry

The attack begins with a single HTTP POST request to the application's /login endpoint. From the outside, it looks like a failed authentication attempt—a 401 response. The kind of event that happens thousands of times a day on any public-facing application.

But the request body is carefully constructed. The username field doesn't contain a username. It contains a JSON-encoded telemetry record—structured to match OpenTelemetry semantic conventions—with an indirect prompt injection payload embedded inside.

When the SRE agent reviews recent failed login attempts as part of its monitoring context, it encounters this record. The JSON payload inside the username field is structured to look like a legitimate OpenTelemetry health alert—and the agent processes it as one.

The OpenTelemetry Payload: Anatomy of the Injection

The injected telemetry record was designed to be indistinguishable from a real OpenTelemetry alert. Every field follows OTEL semantic conventions. Every signal name matches what a legitimate eBPF-based network observer would report. This is what the agent sees:

Why OpenTelemetry Became the Prompt Injection Attack Surface

The choice of OpenTelemetry as the attack vector is deliberate. OTEL is the industry standard for observability telemetry—traces, metrics, and logs flow through it across the entire infrastructure. An SRE agent that monitors application health will naturally trust OTEL-formatted data because that is what it was designed to process.

The attacker exploited this trust with precision:

• Realistic event naming: The event.name field (otel.receiver.ebpf.detached) describes a real failure mode: an eBPF socket observer losing its kernel attachment. This happens in production when kernel updates or resource pressure cause the observer to detach.
• Fabricated evidence chain: Three corroborating signals (18,432 socket events in 45 seconds, zero request spans, receiver health state 'detached') paint a consistent picture. No single anomaly—a coherent incident.
• Embedded remediation plan: The remediation section provides step-by-step instructions: (1) apply a Kubernetes manifest, (2) verify the deployment is ready, (3) confirm telemetry resumes. The agent follows this plan because it looks like standard runbook automation.
• OTEL-consistent metadata: Annotations like observability.coffeehaus.io/managed-by: otel-collector and labels like component: network-telemetry make the manifest appear to be part of the existing observability stack.

How Prompt Injection Manipulated the AI SRE Agent

The Bedrock-powered SRE agent receives the poisoned telemetry as part of its monitoring context. The prompt given to the agent is straightforward:

The agent finds exactly what the prompt describes: a 401 error (the failed login attempt) and an adjacent OTEL health record showing the receiver is unavailable (the injected telemetry). It follows its instructions—apply the remediation. The remediation section of the telemetry record provides a Kubernetes manifest. The agent applies it with kubectl apply.

From the agent's perspective, this is a routine incident response. From the attacker's perspective, the agent just deployed a weaponized container into the production namespace.

How the AI Agent Deployed a Privileged Kubernetes Container

The Kubernetes manifest embedded in the telemetry record's remediation.steps[0].object field creates a Deployment named checkout-api-telemetry-adapter in the prod namespace. On the surface, it looks like a standard observability component. Underneath, it is a weaponized container with full host access.

What Each Capability Enables

The combination of hostPID: true with these Linux capabilities gives the container unrestricted access to the underlying host:

• hostPID: true—The container can see every process running on the EKS worker node, including processes in other pods and system services.
• SYS_ADMIN—Allows the container to mount and unmount filesystems, including accessing other containers' overlay filesystems.
• SYS_PTRACE—Enables tracing and inspection of any process on the host, not just processes within the container.

No PodSecurity admission policy existed in the namespace to block this. No OPA/Gatekeeper or Kyverno policy validated the manifest. The agent had the RBAC permissions to create any workload, and nothing prevented it from creating a privileged one.

The CGI Webshell: Remote Code Execution Inside the Cluster

The deployed container doesn't just sit idle. Its startup command writes a Python-based CGI webshell to /tmp/telemetry-server.py and starts serving it on port 8080. The webshell exposes a /cgi-bin/telemetry endpoint that executes arbitrary commands passed as query parameters.

The webshell uses a legitimate checkout-api container image from ECR—the same image used by the real application. This means the container passes image-based validation and appears to be part of the existing workload. The webshell is written to disk at runtime, not baked into the image.

A readiness probe at /telemetry/< marker > ensures Kubernetes routes traffic to the pod only after the webshell is operational. The attacker verifies the probe, then begins issuing commands through the CGI endpoint.

Container Escape: From Pod to Host

With the CGI webshell operational and the container running as root with hostPID and SYS_ADMIN, the next step is a well-known container escape technique: nsenter.

The nsenter command enters the namespaces of PID 1—the host's init process. The flags -m -u -i -n -p enter the mount, UTS, IPC, network, and PID namespaces respectively. After this command, the attacker has a root shell on the EKS worker node with full visibility into every container running on that node.

From the host, the attacker can see all checkout-api pods and their process trees. The ransomware payload is downloaded from attacker-controlled infrastructure and executed from the host namespace, giving it access to every pod's filesystem through /proc/< pid >/root/.

Ransomware Execution: Real Encryption, Not Defacement

The payload executes functional ransomware—not cosmetic defacement. This distinction matters: defacement changes what users see, but the original files remain intact. Encryption destroys data availability. Without the attacker's private key, the files are irrecoverable.

Phase 1: File Encryption

The ransomware encrypts application files in /app/ using AES-256-CBC:

• Per-file keys: A random 256-bit key and initialization vector are generated for each file.
• Key wrapping: Each key is encrypted with the attacker's RSA public key and stored alongside the encrypted file.
• Asymmetric protection: Only the attacker's private key can decrypt the per-file keys. Without it, the encrypted data is computationally unrecoverable.

Phase 2: Storefront Replacement

The original server.py—the Python application serving the Brewhaus storefront—is replaced with a ransom page through ConfigMap host-path poisoning.

When Kubernetes mounts a ConfigMap at a specific file path using subPath, the mount resolves to a file on the host node's filesystem (XFS). From the host namespace, this file is always writable as root. The ransomware writes the ransom page directly to this host-side path, and every pod that mounts the ConfigMap immediately serves the ransom page instead of the coffee shop.

The Watchdog: 20 Minutes Against the Machine

Here is where the attack becomes remarkable. The SRE agent that was tricked into deploying the malicious container detects the outage it caused. The storefront is down. The agent begins remediation—restarting pods, redeploying from manifests, attempting to restore the original server.py.

But the ransomware includes a watchdog—a persistence mechanism designed to defeat exactly this kind of automated recovery.

How the Watchdog Works

• Grace period (20s): After the initial infection, the watchdog waits 20 seconds before monitoring begins. This prevents interfering with pods that are still starting up.
• Continuous monitoring: Every 3 seconds, the watchdog checks all checkout-api pods. It reads the first line of each pod's server.py through the host filesystem.
• Content detection: Each pod is classified: if the first line contains a unique payload marker, the ransom page is in place. If not, the pod has been remediated by the agent and needs to be re-poisoned.
• Verified writes: The watchdog writes the ransom page to the pod's filesystem, then reads it back. If the read-back confirms the write succeeded, the pod is killed. If the write cannot be verified, the pod is left alive—preventing CrashLoopBackOff.
• Post-kill cooldown (20s): After killing a pod, the watchdog waits 20 seconds before checking again. This gives Kubernetes time to restart the pod and stabilize.

The result: the SRE agent restarts a pod → the watchdog detects the clean code → re-poisons the ConfigMap → kills the pod → Kubernetes restarts it with the ransom page. For 20 minutes, the agent fights its own creation. The watchdog wins every round.

After 20 minutes, the watchdog terminates itself. This is deliberate—it allows clean recovery through the console reset procedure once the demo concludes.

Where Was the AI Agent Security Vulnerability?

Attribution matters. When publishing security research, precision about what is and isn't vulnerable prevents confusion and ensures the right teams take the right actions. Here is the attribution for this attack:

NOT Amazon Bedrock

Bedrock is the inference infrastructure. It correctly routes prompts to the foundation model and returns responses. No Bedrock API was exploited. No access control was bypassed. Bedrock performed exactly as designed.

NOT the Foundation Model

All current large language models are susceptible to prompt injection—this is a known property of the paradigm, not a bug in any specific model. The model processed input as designed. The problem is that untrusted data reached it in a position where it could influence actions.

The Agent Configuration

The vulnerability is in how the agent was built and configured:

• No input sanitization: The agent processes raw telemetry data—including data from untrusted sources like failed login attempts—without filtering for injection patterns.
• Overprivileged RBAC: The agent's Kubernetes RBAC grants permissions to create any workload, including containers with privileged security contexts, hostPID, and dangerous Linux capabilities.
• No admission control: No PodSecurity admission policy, OPA/Gatekeeper, or Kyverno policy prevents the creation of privileged pods in the production namespace.
• No human-in-the-loop: The agent can apply manifests, restart deployments, and modify infrastructure without human confirmation.

The analogy is straightforward: SQL injection is not a database vulnerability—it's an application vulnerability. Prompt injection weaponized through an overprivileged agent is not a platform vulnerability—it's an agent design vulnerability.

What Would a Real Attacker Do?

In this research, the ransomware was confined to pods within a single Kubernetes namespace. This was a deliberate lab constraint. With the same container escape and host-level access, a real attacker would not stop at one namespace.

The most devastating real-world scenario: from the compromised host, the attacker queries the EC2 Instance Metadata Service (IMDS) to obtain the node's IAM role credentials. Those credentials typically grant access to ECR, S3, CloudWatch, and potentially Secrets Manager. Using the IAM role, the attacker pivots to S3—encrypting data at rest across every bucket the role can reach. Simultaneously, a DaemonSet deploys ransomware to every node in the EKS Auto Scaling Group. The result: every pod across every namespace on every node encrypted, plus cloud storage. Complete infrastructure lockout from a single HTTP POST.

What should agent builders do?

• Sanitize inputs: All data entering agent context must be validated and filtered—especially data from untrusted sources like user input, login attempts, and external webhooks.
• Least-privilege RBAC: An SRE agent should not have permissions to create privileged pods. Scope RBAC to the minimum operations required.
• Human approval for privileged operations: Workload creation, RBAC modifications, and namespace changes should require human confirmation.
• Deploy guardrails: Use Bedrock Guardrails to detect and block prompt injection patterns before they reach the model.

What should platform teams do?

• PodSecurity admission policies: Apply the restricted PodSecurity Standard cluster-wide. This prevents containers from running as root, using hostPID, or adding dangerous capabilities.
• Admission controllers: Deploy OPA/Gatekeeper or Kyverno policies that explicitly block hostPID, SYS_ADMIN, SYS_PTRACE, and privileged security contexts.
• Runtime monitoring: Alert on unexpected privileged workloads appearing in production namespaces.

What should organizations adopting agents do?

• Treat agent permissions like human permissions: Audit agent RBAC the same way you audit human operator permissions. Review quarterly.
• Assume context will be poisoned: If your data sources can be poisoned, your agent can be weaponized. Build for this assumption.
• Deploy agent security monitoring: Use runtime security platforms that monitor agent behavior and detect anomalous tool use patterns.

Straiker’s defensive protection is the best solution

Defend AI’s multi-layer defense approach detects and blocks these type of attacks during the initial prompt injection added in the Login page by the attacker:

And at network layer monitoring the commands being triggered blocking Remote Code Execution attempts:

Our final thoughts for agent builders and adopters

This research demonstrates a complete attack chain—from a single HTTP request to deployed ransomware—executed entirely through an AI agent's own permissions and trust model. No software vulnerability was exploited. No credentials were stolen. No zero-day was used. The agent did exactly what it was told to do by data it was designed to trust.

The lesson is not that AI agents are inherently dangerous. The lesson is that AI agents with infrastructure permissions require the same security rigor as any other privileged system—input validation, least privilege, admission control, and human oversight for destructive operations.

As of today, August 17, 2026, this research has been reported to AWS Security (aws-security@amazon.com). We want to be clear: the vulnerability is not in Amazon Bedrock or any AWS service. It is in the agent's configuration—the same class of issue that exists in any organization building autonomous agents with infrastructure access. We notified AWS so they are aware before this research is published.

The infrastructure is yours. The agent is yours. The permissions are yours. The responsibility is yours.

Key Findings

• A single HTTP request delivered an indirect prompt injection through application telemetry.
• The poisoned telemetry was interpreted by an AI SRE agent as a legitimate OpenTelemetry health alert.
• The agent used its Kubernetes permissions to deploy a malicious privileged container.
• The container used hostPID, SYS_ADMIN, and SYS_PTRACE to escape to the underlying host.
• The attacker executed ransomware against application files using AES-256-CBC.
• A watchdog mechanism maintained the compromise for approximately 20 minutes despite automated remediation.
• The attack did not exploit a vulnerability in Amazon Bedrock or a foundation model.
• The root cause was the combination of untrusted agent context, excessive Kubernetes permissions, inadequate admission controls, and autonomous remediation.

Frequently Asked Questions (FAQs)

What is an AI SRE agent?

An AI SRE agent is an autonomous software agent that monitors infrastructure, diagnoses operational problems, and can execute remediation actions using infrastructure tools and permissions.

How did prompt injection compromise the AI SRE agent?

The attack embedded an indirect prompt injection inside telemetry data that the agent treated as trusted OpenTelemetry monitoring context. The injected data contained a fabricated incident and remediation instructions that caused the agent to deploy a malicious Kubernetes workload.

Was Amazon Bedrock vulnerable?

No. The demonstrated attack did not exploit a vulnerability in Amazon Bedrock. The research identified the security issue as an agent-configuration problem involving untrusted input, excessive Kubernetes permissions, insufficient admission controls, and autonomous execution.

Can prompt injection lead to ransomware?

Yes. When an AI agent has permissions to modify infrastructure, a successful indirect prompt injection can potentially turn the agent's legitimate capabilities into an attack path. In this demonstration, those permissions enabled deployment of a privileged container that accessed the underlying host and executed ransomware.

How can organizations protect AI SRE agents from prompt injection?

Organizations should treat all external data entering an agent's context as untrusted, apply least-privilege permissions, require approval for destructive operations, and enforce Kubernetes admission and runtime security controls.

What Kubernetes controls can prevent this attack?

Pod Security Admission, admission policies such as OPA/Gatekeeper or Kyverno, restrictive RBAC, and runtime monitoring can limit or block privileged workloads and dangerous capabilities.

Demonstration

The following video demonstrates the complete attack from start to finish—from the poisoned telemetry record to the encrypted storefront.

Vigiles AWS Ransomware Final Censored.mp4

About Straiker's STAR Labs

Research team: Straiker STAR Labs

Published: August 2026

Research category: AI Agent Security / Kubernetes Security

Technologies: Amazon Bedrock, Amazon EKS, Kubernetes, OpenTelemetry

Disclosure: AWS Security notified August 17, 2026