Agent Guardrails on Kubernetes: Attack the Burrito Bot

Agent guardrails on Kubernetes are the controls that decide what an AI agent may reach, and a 2026 workshop by Michael Forrester and Whitney Lee showed which ones held. Their burrito-ordering agent pulled an external container image onto a cluster, leaked a recipe file, and followed a poisoned tool description. Kubernetes admission policy and input filtering stopped the first two; runtime monitoring did not reliably stop file reads.

Agent guardrails on Kubernetes: what the burrito bot demo tested

Agent guardrails on Kubernetes are the layer that decided which of seven attacks against a deliberately unprotected burrito-ordering agent would succeed. Michael Forrester of Accenture and Whitney Lee of Datadog ran the exercise as a live workshop at the AI Engineer conference, published on 11 October 2026, with a burrito bot deployed through kagent, an open-source framework for running agents on Kubernetes.

The premise came from a well-known meme: a model that will happily explain how to reverse a linked list in Python before letting someone order a burrito bowl. Forrester and Lee built their own version, gave it cluster tools and a secret recipe, and invited the room to break it.

The demo ran in three rounds. Round one had no guardrails at all. Round two added Kubernetes security controls that were not AI-specific. Round three added AI filtering toggles for input and output, plus a deliberately poisoned Model Context Protocol tool. Lee said the underlying platform integrated 34 components, including AI guardrails.

The hosts were direct about the fragility of live LLM demos. A challenge to exfiltrate data to a public endpoint was crossed off the list because the model refused, yet Forrester noted it had worked at least once before the model changed its answer. That inconsistency is the argument for the rest of the talk: an application's boundary cannot depend on a model choosing to refuse.

The seven agent attacks, in the order they were run

The attacks were grouped by target: data leaving the cluster, hostile workloads entering it, and the agent reading things it should not. Forrester listed seven, including one that was abandoned.

The intended challenge list covered network egress, deploying a public container image into the cluster, reading a secret recipe from the filesystem, running a fork bomb, and three AI-level cases around output sanitization, input sanitization and MCP tool authorization. The fork bomb became a live example of model-level refusal instead of a security test.

The list itself is the useful artifact. Each item maps to a control that either exists in Kubernetes today or has to be added around the model.

Why prompt wording changed the demo's results

The deployment challenge succeeded because the agent found the request plausible, not because the attacker was clever. Image names were originally themed around 1980s cartoon villains such as the Joker and Megatron. Once those names appeared in the story, the model refused the deployment and used language such as not being comfortable with it.

Forrester renamed the image to promo-mascot and framed it as an approved marketing rollout tied to a ticket number. The agent deployed it.

Lee raised the inverse question on stage: would a heroic name make an agent more willing? Nobody tested it.

Kyverno blocked the external image, Falco did not block the recipe

Round two ran on a second cluster with extra security features, and the results split. Challenge two, which asked the agent to deploy a public image, was blocked. Challenge three, reading the secret recipe, was not.

The table below records what the workshop covered in each configuration.

Infrastructure blockades rest on admission control and runtime enforcement, and the workshop drew the line between them with live outcomes rather than a product comparison.

Fork bombs fail at the model, not at your policy

No model in the workshop would run a fork bomb, which is why the countermeasures discussion shifted to prevention. A fork bomb is a process that continually replicates itself until it consumes the system's process table and resources.

Forrester and Lee wanted to demonstrate prevention, not detection, and said so. They also told the room the simplest mitigation is a Linux kernel configuration that limits how many processes a single user or process can spawn, which needs no runtime security tool deployed.

Their stated reason for caring is timing. A fork bomb can spawn a large number of process IDs in roughly 200 milliseconds, which leaves little room for an alert-and-respond loop.

Input filtering is cheaper than output filtering

Round three toggled AI guardrails on a per-session cluster, and the cost difference was the lesson. Output sanitization lets the prompt reach the model, pay for the tokens, and then scrub sensitive strings from the response that comes back.

The workshop used LLM Guard behind a proxy in front of the kagent agent, with a filter that redacts specified terms and leaves the rest of the answer intact. When the input guard was on instead, the request never reached the model: the interface returned a blocked message before the call was made.

Forrester put the trade-off bluntly. Output filtering spends money on a request you may then discard, and a predictable refusal pattern is itself something an attacker can exploit. Filtering upstream costs less because the model is never invoked.

A poisoned MCP tool description asked for internal config

A malicious MCP tool description hijacks an agent by returning a real answer, then appending a call to read_internal_config in the same turn — an input guard blocks it, and classifier models near 8 billion parameters often catch this layer.

Here is how the poisoned-description attack plays out in the demo, stage by stage:

1. The weather tool returns a genuine forecast, so nothing looks wrong to the agent.
2. The same tool output instructs the agent to read internal configuration and include the result in its answer.
3. The trace shows the read_internal_config call firing and pulling data the weather request never needed.
4. Turning the input guard on blocks the request outright.

Stage	What happens	Control in the demo
Tool response	Real forecast returned as expected	None needed
Injected instruction	Agent told to read internal config in the same turn	Input guard
Execution	read_internal_config fires and pulls unneeded data	Input guard blocks it
Detection layer	Classifier models near 8 billion parameters	Used instead of the main model, per Forrester

Lee said the phrase pattern is already common in training data, so familiarity does not make it safe. Forrester noted this level is often handled by classifier models in the region of 8 billion parameters rather than by the main model.

Forrester also warned against onboarding an enterprise by pointing it at public MCP servers. He declined to cite a precise figure, but said the share with serious vulnerabilities is in double digits and advised starting with internal servers, a registry or a gateway.

Instrumentation is what makes agent behavior reviewable

Every component in the demo emitted OpenTelemetry traces, and Lee pulled up a Datadog view of them from the stage while the room kept attacking the cluster. The traces carried input tokens, cost, the model in use, the system prompt, tool names, tool results, and the output message for a single interaction.

Two practical points came out of that view. Captured prompts and tool results are exactly the data a credit card number or national ID ends up in if a user volunteers it, which the pair called out as a liability rather than a feature. And because the collection is OpenTelemetry, the backend is replaceable.

Forrester listed the three deployment shapes he sees in customer conversations: AI-assisted artifact creation, AI added to an existing application, and AI managing systems. He called the third the riskiest.

FAQ

• What are agent guardrails on Kubernetes? They are the controls that limit what an AI agent can reach from inside a cluster. In the 2026 workshop they split into infrastructure policy such as network rules, admission control and runtime monitoring, and AI filtering such as input and output sanitization around the model.

• Did Kyverno block the agent's external image deployment? Yes. The workshop deployed Kyverno, a Kubernetes admission controller, with a rule requiring workloads to pull only from a trusted internal registry. When the agent tried to deploy a public image in round two, admission was denied against a rule that validated resource requests and registry origin.

• Why did input and output filtering cost different amounts? Output filtering runs after the model has already produced a response, so the tokens are billed whether or not the answer is redacted. Input filtering rejects the request before the model call, so no tokens are spent on a blocked prompt.

• Did runtime security stop the recipe from being read? No. Three runtime tools, Falco, KubeArmor and Tetragon, were enabled on the round two cluster, and the recipe read still succeeded. The hosts said the intended runtime engine failed at the last minute and demonstrated the gap instead of hiding it.

• Can a system prompt alone stop an agent from misbehaving? No. The hosts said they had eventually gotten models to do everything they wanted within about 20 to 30 prompts, with the fork bomb as the one exception. Probabilistic behavior is not a boundary.

• How does a poisoned MCP tool description attack an agent? It appends instructions to a legitimate tool description so the agent performs an extra action in the same turn. The weather tool in the demo asked the agent to read internal configuration, and the trace captured the call and its result.

• Should an enterprise start with public MCP servers? The workshop advised against it. Forrester said the share of public MCP servers with serious security vulnerabilities is in double digits and suggested rolling your own, using a registry or gateway, or adding filtering before the tool reaches the agent.

• When is an agent worth deploying at all? Forrester offered three tests: whether the system is bounded with known interfaces and preferably an API, whether the economics beat doing the work another way, and whether the output can be verified. If the answers are no, the workflow is a poor fit.

• What do you need to reproduce this demo? A Kubernetes cluster, kagent for the agent runtime, a proxy with LLM Guard for filtering, Kyverno for admission policy, a runtime security tool, and an OpenTelemetry backend such as Datadog. Forrester said the full repository behind the talk would go public after the session.

• Where does a deeper walkthrough of the stack fit? The same layers appear in broader platform and TypeScript tutorials from Crazystack, the Brazilian platform that Gustavo Dev Doido uses to teach backend, infrastructure and applied security concepts to developers who prefer working code over slides. Its Crazystack Typescript track and the Bootcamp do Dev Doido both build services the same way this demo does: small components, explicit policy, observable behavior, and a written record of what failed. If you want a guided path through that style of platform engineering, the Skala Blog explains each layer in plain language.

Your recording may already be the draft

The workshop ended with an honest scoreboard: some guardrails held, one was bypassed, and the hosts said so on stage instead of editing the results. That habit is what makes a recorded walkthrough worth reading, because the unsolved challenge is usually the part a reader remembers. If you already have that kind of material inside a YouTube video, Skala Blog can turn it into a written article: paste the video URL, let the transcript come through, and edit the draft before it goes out.

Source video