Kategorie: Kubernetes

YOLO Mode: Agent Autonomy Without the Guardrails

AI agents have come a long way in both capability and everyday use since generative AI went mainstream in late 2022. In Stack Overflow’s 2025 Developer Survey, 84% of developers said they use or plan to use AI tools in their workflow, up from 76% a year earlier. As those tools shift from suggesting code to writing files and running commands on their own, one practical question follows. How much should an agent be allowed to do without stopping to ask? Turn that dial all the way up and you reach what developers call YOLO mode.

It’s worth understanding YOLO mode before you enable it, because its main risk is easy to misread. The risk comes down to where an agent runs.  On your own machine, one mistaken command can delete  files, expose your credentials, and make network requests you may not want. Inside a proper boundary, however, developers can use agents in YOLO mode to unlock a new level of productivity, without jeopardizing security.

Key takeaways

YOLO mode is when an AI agent auto-approves every action, with no confirmation prompts.

It’s popular because it’s fast, and risky for the same reason. The danger isn’t the autonomy, it’s where the autonomy runs.

On your host, a bad command or prompt injection reaches real files and credentials. Inside an isolated sandbox, the blast radius is contained.

Run YOLO mode where it can’t do real damage, in an isolated, disposable environment with scoped access and no real secrets.

What is YOLO mode?

YOLO mode is the community nickname for running an AI agent with every action auto-approved. When turned on, agents can read files, write code, run shell commands, and call tools without stopping for user approval. While in Claude Code it’s the –dangerously-skip-permissions flag, other common agents each have their own version of the same switch.

Codex CLI has `–full-auto`, plus `–dangerously-bypass-approvals-and-sandbox` when you drop the sandbox too.

Gemini CLI uses `–yolo`, or the Ctrl+Y toggle mid-session.

GitHub Copilot CLI has `–allow-all`, also aliased as `–yolo`.

Cursor exposes it as auto-run in settings rather than a flag.

The names differ, but the behavior is the same: remove the prompts and let the agent go. 

YOLO mode showed up in Cursor first, then Claude Code, and by 2026 it’s a standard toggle in most coding agents. But when people ask what YOLO mode is, they’re usually asking whether they should use it, and the answer is that it depends entirely on where the agent is running.

Why developers turn it on

On a regular task, a careful agent asks for permission constantly. “Can I edit this file, run this test, install this package, call this tool?” 

Dozens of prompts for one feature. While these constant permission requests can help prevent agents from going rogue, each approval forces you to context switch and breaks the flow that made the agent worth using. A few reasons why developers are leveraging YOLO mode include:

Context switching: Every approval pulls a developer out of their flow, taxing mental focus and overall productivity. 

Prompt fatigue: Excessive querying, refinement, and approvals force creative coding to take a back seat to tedious prompt wrangling and debugging.  

Low-risk, routine work: Agents can often handle repetitive tasks that would otherwise take developers away from creative coding and innovation. 

Momentum: An agent is most useful when it has the freedom to keep moving, but a steady stream of prompts breaks that.

If you turn approvals off, these friction points disappear for the most part, and the agent can deliver the speed it promised. But what’s the cost of giving agents the autonomy of YOLO mode?

Why is YOLO mode risky?

When you remove the prompts, you remove the last human check before an action runs, which amplifies the security risks agents already carry. If the agent is working directly on your host, that action has the full run of your machine, including your files, environment variables, credentials, and network. A confused or compromised agent can do a significant amount of damage when nothing stands between an agent’s decision and your system.

On an unprotected host, YOLO mode introduces risks such as:

Destructive commands: A vague or mistaken instruction runs something like rm -rf against the wrong directory, and nothing pauses to catch it.

Secret and credential exposure: The agent can read environment variables, .ssh keys, tokens, and .env files, then use or leak them.

Prompt injection: The agent acts on whatever it reads, so a hidden instruction in a web page, an issue, a code comment, or a document can redirect it, and the attacker never needs access to your machine.

Data exfiltration: A mistaken or hijacked agent sends sensitive data out over the network.

Unintended broad changes: Edits and config changes reach past the task at hand into your other projects.

Network and lateral reach: The agent can hit internal endpoints and outside services, or act with your credentials to push code and call APIs.

And unfortunately, keeping manual approvals on doesn’t remove all risk. Once permission fatigue kicks in, it can be all too easy to accidentally approve the wrong request. So the safeguard belongs in the environment the agent runs in, where a bad command or a tired click has a greatly reduced scope of impact.

The fix isn’t fewer permissions, it’s a boundary

If prompts aren’t the answer, what is? A boundary the agent can’t cross. Guardrails only work when something outside the agent enforces them. The agent needs a bounding box, with constraints set before it runs and clear limits on what it can touch. Inside that box, it should be free to move as fast as it wants. The goal is to shape the environment so that a mistake can’t damage your systems or leak your secrets.

In practice, that means running the agent in an isolated, ephemeral environment instead of on your host. Done well, the agent gets a real place to work. It can install packages, run services, and edit files, but it can’t see your credentials, reach your other projects, or touch the host.

Unlike a container that shares the host kernel, a microVM puts a hardware-level boundary around the agent, so the isolation holds even if the agent tries to break out, and it does that without the speed penalty people expect. If a run goes sideways, you destroy the environment and start clean. This is the core idea behind sandbox security and why agents need isolation in the first place.

What does YOLO mode look like at scale?

For one developer on a sandboxed laptop, YOLO mode is a personal choice. Across a team, it becomes a policy question. A hundred developers each deciding on their own when to skip permissions is the ungoverned-autonomy problem that keeps security leaders up at night. The picture that works at scale is one where the safe path is the default. Every agent runs inside an isolated, disposable environment, configured once at the organization level so it holds for everyone.

This is the problem AI Governance is built to solve. You define the rules once across the surfaces that matter, network access, the filesystem, and the tools an agent can reach, then enforce them automatically at every developer’s machine. Governance turns a per-developer judgment call into a consistent, repeatable capability. Clear boundaries are what let an organization extend autonomy to its agents while keeping the risk contained. Once the boundary is standard, YOLO mode is fast and safe for everyone.

What it unlocks for developers

Once the boundary is in place, the developer can stop supervising every step, and the payoff kicks in:

Deep focus: Give direction, step away, and come back to a cloned repo, passing tests, and an open pull request. No interruptions pulling you off your own work.

Long, autonomous runs: The agent edits, runs the tests, reads the failures, and retries until the task is done, the kind of run a wall of prompts would stall.

Agents in parallel: Point several at different tasks, each in its own disposable environment, and let them run at once.

You review the outcome: Your job moves up to the pull request, the tests, and the diff, where your judgment matters most.

That’s the real appeal, and the sandbox is what makes it safe to lean on.

Unlock agent autonomy, safely

YOLO mode is really a question in disguise. How much autonomy can you give an agent before the risk outweighs the speed? Framed that way, the answer stops being about the agent and starts being about its environment. Give an agent the run of your laptop and even a small mistake is expensive. But give it a boundary it can’t cross and you get the speed with almost none of the exposure.

That’s exactly what Docker Sandboxes is built for. Each agent runs in its own disposable microVM with control over networking, filesystem access, and resource limits, so you can run agents in YOLO mode safely from day one. For teams that want those boundaries applied consistently rather than agent by agent, Docker AI Governance sets and enforces the rules everywhere developers work. Define the box. Then let the agent go as fast as it likes.

Get started with Docker Sandboxes → 

Explore Docker AI Governance →

Frequently asked questions

Is YOLO mode safe?

It depends entirely on where the agent runs. On your host machine, YOLO mode is risky, because a mistake or a prompt injection can reach your files and credentials. Inside an isolated, disposable environment with scoped access and no real secrets, the blast radius is contained and YOLO mode is reasonable to use.

What does –dangerously-skip-permissions do in Claude Code?

It turns off the confirmation prompts, so Claude Code reads, writes, runs commands, and calls tools without asking for approval at each step. It trades the safety of human review for speed. It’s the most common way people run Claude Code in YOLO mode.

How do I use YOLO mode safely?

Run the agent inside an isolated sandbox rather than on your main machine, give it scoped network access and throwaway credentials instead of your real ones, work against a cloned or disposable copy of your project, and keep a way to inspect what it did. The goal is a boundary the agent can’t cross, not a more careful set of prompts.

Is auto mode the same as YOLO mode?

Not exactly. Full YOLO mode approves everything. Some tools now offer a classifier-gated auto mode that runs safe actions automatically while still blocking or flagging dangerous ones. That’s a useful middle ground, but it’s a filter on top of the agent, not a boundary around it. Isolation still matters.

Quelle: https://blog.docker.com/feed/

Building Reproducible AI Evaluation Workflows with Docker Sandboxes

AI evaluation has never been easier to start. Reproducing it reliably is another story. Developers now have access to more benchmarks, evaluation libraries, model APIs, and agent frameworks than ever before. But keeping the prompt, model, and scoring method fixed doesn’t necessarily make a run reproducible. The execution environment matters too.

Python dependencies change. Local tools drift. Setup steps go undocumented. A workflow that succeeds on one machine may behave differently on another. Most discussions about evaluation focus on what should be measured: benchmarks, scoring methods, or judge models. Much less attention is given to how those evaluations are executed. Yet that execution layer often determines whether someone else can reproduce the same workflow weeks or months later.

When I started exploring Docker Sandboxes, I wasn’t trying to build another evaluation framework. I had a much smaller question.

Could Docker Sandboxes and an SBX Kit make evaluation workflows easier to rerun, inspect, and compare?

That question eventually became the SBX AI Evaluation Kit, an open-source Docker Sandboxes Mixin Kit focused on repeatable execution, structured evaluation records, and runtime evidence. The current implementation does not execute AI models or automatically derive evaluation judgments. Instead, it executes configured commands consistently and preserves evidence of what actually ran.

In Practice

In practice, the workflow starts by choosing where the evaluation command should run through the execution block:

execution:
executor: sbx
command:
– python3
– -c
– print("hello from sbx")

With executor: sbx, the runner delegates command execution to Docker Sandboxes and writes the runtime evidence into the resulting artifact.

The repository is also packaged as an SBX Mixin Kit, so it can be applied when starting a Claude sandbox:

sbx run claude –kit .

The runner reads the configured executor and delegates the command to SBX, which executes it inside the sandbox:

python run_evaluation.py

From Documentation to an Executable Workflow

Each evaluation is defined in a YAML file that describes the evaluation and the command to run. The repository validates that definition, executes it, and produces a structured JSON record of the result. The difference is in what gets recorded. A written evaluation captures what someone intended to do. An execution-backed evaluation captures what actually happened.

Separating Evaluation from Execution

I wanted the evaluation definition to stay independent of where it ran. A workflow written during local development shouldn’t need to change simply because it later executes inside Docker Sandboxes.

To keep those concerns separate, I introduced an executor abstraction. The evaluation describes what should run; the executor determines where it runs.

With the local executor, the configured command runs on the host. With the SBX executor, command execution is delegated to Docker Sandboxes. Switching between the two only requires changing the executor configuration, not rewriting the surrounding evaluation workflow.

Figure 1. Evaluation definitions remain independent of the execution environment. The same workflow can use either the local or SBX executor while producing runtime evidence in the same structure.

Capturing Evidence Instead of Assumptions

For each execution, the runner records enough information to inspect what actually happened:

the selected executor,

the command that was executed,

standard output (stdout) and standard error (stderr),

the exit code,

and the execution time.

These details are stored in the evaluation artifact. The repository also generates a digest of the evaluation configuration. This creates a deterministic link between the evaluation configuration and the artifact it produced, without trying to replace full experiment-tracking systems.

{
"executor": "sbx",
"command": ["python3", "-c", "print("hello from sbx")"],
"stdout": "hello from sbxn",
"stderr": "",
"exit_code": 0,
"duration_ms": 120.0
}

Scaling from One Evaluation to Many

Real-world evaluation rarely consists of one isolated run. Teams compare prompts, validate behavior, measure regressions between releases, and test multiple scenarios. That led to evaluation suites.

Rather than changing how an individual evaluation works, a suite groups multiple evaluation definitions into a single repeatable workflow. Each evaluation still produces its own structured artifact, while the suite also generates an aggregated summary of the overall run.

Reusable SBX Kits Beyond Evaluation

The same pattern isn’t limited to evaluation. An SBX Kit can package more than a development environment; it can also package the setup an engineering workflow depends on. The same model could support regression testing, policy checks, security analysis, code-generation experiments, and other workflows that depend on consistent execution and inspectable results.

Conclusion

The SBX AI Evaluation Kit doesn’t replace evaluation frameworks, benchmarks, or scoring systems. Its job is narrower: execute configured evaluation workflows in a way that is easier to rerun and inspect.

The question I came away with is simple: before comparing benchmark scores or choosing a judge model, can someone else reliably run the same workflow under comparable conditions?

You can explore the code, experiment with custom evaluation YAMLs, and run the workflow yourself in the sbx-ai-eval-kit repository on GitHub.

Resources

SBX AI Evaluation Kit – Source code, example evaluation definitions, and the implementation described in this article.

Docker Sandboxes documentation – Official documentation for setting up and running Docker Sandboxes.

Customizing Docker Sandboxes with Kits – Official documentation for extending Docker Sandboxes with reusable Kits.

Quelle: https://blog.docker.com/feed/

Running AI agents in GitHub Actions with Docker Sandboxes

In July 2026, GitHub Agentic Workflows added Docker Sandboxes as a supported agent runtime. It means that in your CI an AI coding agent can have broad control of its environment, including being able to run Docker containers, while the environment itself is isolated in a microVM with a network policy and secrets injection like the current best practices for AI isolation advice. 

Agentic isolation matters because useful coding agents do more than read a repository and suggest a patch. They install tools, run arbitrary shell commands, execute project code, start databases, and occasionally discover surprising new meanings for the word “cleanup.” Those capabilities make the agent useful, and direct access to a CI runner gives every mistake a larger blast radius.

Now, with sbx integrated, the boundary for the Agent is a disposable environment with substantial freedom inside and narrow access to everything outside it.

I put together a small example to see what that looks like in practice. The agent runs on a GitHub-hosted Ubuntu runner, enters a Docker Sandbox (sbx), runs a Java integration test suite with PostgreSQL using Testcontainers, finds an intentionally seeded bug, fixes it, and opens a draft pull request. The Github Agentic Workflows offers the integration out-of-the-box, so the setup requires zero custom configuration for actions.

What are GitHub Agentic Workflows?

GitHub Actions remains the CI system. It schedules the job, provides the Ubuntu runner, manages permissions and secrets, and records the result.

GitHub Agentic Workflows, usually shortened to gh-aw, is an open-source GitHub CLI extension and compiler. You describe an agentic workflow in a Markdown file that combines execution configuration in YAML frontmatter with the agent’s task in the body. Running gh aw compile turns that source into a conventional GitHub Actions workflow with a .lock.yml suffix.

The relationship looks like this:

Markdown workflow
|
| gh aw compile
v
Generated GitHub Actions .lock.yml
|
| runs on ubuntu-24.04
v
Docker Sandbox microVM
|
v
Copilot agent and its tools

docker-sbx belongs to gh-aw‘s agent runtime configuration. The runs-on field still selects ubuntu-24.04, and the compiled file is a standard GitHub Actions workflow. It installs the sandbox tooling, authenticates it, checks the runner, starts the agent in the sandbox, and cleans everything up afterward.

That integration landed in gh-aw and shipped in version 0.82.9.

Configuring sbx in GitHub Actions

Here is the configuration from the sample’s sandbox-explorer.md:

—
name: "Docker Sandboxes sample: exploratory test"

on:
workflow_dispatch:

runs-on: ubuntu-24.04

permissions:
contents: read
copilot-requests: write

engine: copilot

network:
allowed:
– defaults
– github
– containers
– java

sandbox:
agent:
id: awf
runtime: docker-sbx
sudo: true

tools:
edit:
bash: [":*"]

safe-outputs:
create-pull-request:
title-prefix: "[docker-sbx sample] "
draft: true
protected-files: blocked
allowed-files:
– "src/**"
—

The three lines under sandbox.agent select the Docker Sandbox runtime. Inside it, the agent has the sudo and unrestricted shell access needed to build the application and start its test infrastructure.

Outside the sandbox, the workflow keeps a much smaller surface. Its network block allowlists the destinations this job needs, while the agent’s GitHub token can read repository contents and send requests to Copilot. Pull request creation happens in a separate safe-output job whose patch may contain files only under src/**.

How much autonomy a CI agent should receive depends on the job. For this one, the split is useful: broad shell access inside the sandbox, small network and repository surfaces outside it, and a draft PR that still expects human review.

The isolation boundary is a micro VM

While it’s common to assume that “Docker” implies a single application container, this setup actually uses a microVM as the primary isolation boundary.

With sbx, every sandbox is a dedicated environment with its own kernel, filesystem, and network stack. Most importantly, it runs its own private Docker daemon. This means the agent gets full root privileges inside the VM without ever gaining control over the host’s Docker daemon. The only bridge between them is the explicit shared workspace of the repository.

Having a private daemon is a game-changer for integration testing. In this demo, the app runs Testcontainers exactly as a developer would on their local machine. The resulting structure looks like this:

GitHub Actions runner
└── Docker Sandbox microVM
├── GitHub Agentic Workflows agent
└── Private Docker daemon
├── Maven / Java 21 container
└── PostgreSQL Testcontainers container

To keep the environment clean, the test launcher runs Maven inside a pinned container, passing the sandbox’s Docker socket through so it can talk to the private daemon:

docker run –rm
–add-host=host.testcontainers.internal:host-gateway
-e TESTCONTAINERS_HOST_OVERRIDE=host.testcontainers.internal
-v "$PWD:/workspace"
-w /workspace
-v /var/run/docker.sock:/var/run/docker.sock
maven:3.9.9-eclipse-temurin-21@sha256:3a4ab3276a087bf276f79cae96b1af04f53731bec53fb2e651aca79e4b10211e
mvn –batch-mode "$@" test

Testcontainers then uses that socket to spin up the PostgreSQL database. It sounds like a lot of layers—a container running a build that starts another container, all inside a microVM on a CI runner but each layer serves a specific purpose in ensuring the agent remains isolated yet fully capable.

Giving the agent a defect worth finding

The sample is a small Java 21 registration service. Its requirements say that email addresses are case-insensitive. The seeded implementation stores them as provided and relies on PostgreSQL’s case-sensitive unique constraint. An existing Testcontainers integration test catches exact duplicates but says nothing about the latter case.

The Markdown portion of the workflow asks the agent to inspect the requirement and code, run the baseline suite, and add a test for two addresses that differ only in case. If the invariant fails, the agent should make the smallest source correction. Before touching the application, it records uname, Docker version, Docker information, and a tiny Alpine container run, leaving specific evidence in the workflow log about where the work executed.

The task itself is plain Markdown beneath the frontmatter in the yaml file. The important part for us (after some commands for recording the environment for debugging) is:

Act as a bounded exploratory tester for this repository.
…

Then:
1. Read `REQUIREMENTS.md` and the relevant source and test files.
2. Run `./scripts/test-in-docker.sh` without changing anything.
3. Add a PostgreSQL Testcontainers test that checks registration of two
addresses that differ only in letter case.
4. Run the focused test and explain the observed behavior.
5. If the implementation violates the documented invariant, make the
smallest fix under `src/`.
6. Run the complete test suite again.
7. Create one draft pull request containing the regression test and fix.

And the prompt level guardrails to suggest the correct behavior: 

Do not modify dependency manifests, workflow files, scripts, documentation,
or generated files. Do not weaken or delete existing tests. Include the
commands run and their results in the pull request description.

The real run of course followed that path: its baseline passed, then the new case-variation test failed with:

expected: <false> but was: <true>

The agent normalized the email before inserting it, reran the complete suite, and got two passing integration tests.

The log reported Docker client and server version 29.7.1 with the default context. It is the correct Docker version currently in the sbx default sandbox template. This is the sandbox’s private daemon, the one Testcontainers library used to launch PostgreSQL for the integration tests. 

The complete workflow passed on GitHub’s hosted ubuntu-24.04 runner. The run took 11 minutes and 16 seconds.

The safe-output job then opened a draft PR containing exactly two files under src/**: the regression test and the one-line normalization fix. Workflow configuration, scripts, dependencies, and documentation were outside its allowed patch surface.

The generated draft pull request stayed inside the declared source-only boundary.

Running the workflow yourself

Start by installing the gh-aw:

gh extension install github/gh-aw

The compiled Docker Sandbox runtime needs Docker credentials to authenticate and pull its sandbox template. Add DOCKER_USERNAME and DOCKER_PAT under the sample repository’s Settings > Secrets and variables > Actions, or let the GitHub CLI prompt for both values:

gh secret set DOCKER_USERNAME
gh secret set DOCKER_PAT

The repository’s Copilot entitlement and copilot-requests: write were sufficient for the successful sample. Repositories without that entitlement can use a supported COPILOT_GITHUB_TOKEN secret as documented by gh-aw.

Also enable Allow GitHub Actions to create and approve pull requests in the repository’s Actions settings. Then compile the Markdown source and commit both the source and generated workflow:

gh aw compile sandbox-explorer

git add .github/workflows/sandbox-explorer.md
.github/workflows/sandbox-explorer.lock.yml
git commit -m "Compile Docker Sandboxes sample workflow"
git push

The .lock.yml is generated code. Changes belong in the Markdown source, followed by another compile.

Finally, start the workflow and watch it:

gh aw run sandbox-explorer
gh run watch

The sample works on GitHub’s hosted ubuntu-24.04 runner as committed. A self-hosted Linux runner needs an appropriate KVM-capable setup, plus the Docker and system access required by Docker Sandboxes.

Try sbx on your laptop

Support for isolating your agents in CI is fantastic, but the easiest way to understand Docker Sandboxes is to put one around an agent on a local project. Follow the Docker Sandboxes setup for your platform, sign in, move to a repository, and run an installed agent:

sbx login
cd ~/my-project

sbx run <claude|codex|opencode>

Give it a task that needs real tools, such as running tests, building an image, or starting a Testcontainers dependency. sbx is much easier to evaluate and understand when the workload is your actual development loop.

And if your experiment grows into an organization-wide agent rollout, Docker AI Governance is the next thing to explore. It applies organization and team policies for sandbox network, filesystem, and MCP access, and records policy decisions in audit logs. Those records help to identify the source client, including sbx, and the machine hostname, so the same policy and audit model can easily cover your  team’s laptops and your CI runners.

Quelle: https://blog.docker.com/feed/

Aia at the Gate: AI Proposes, Humans Hold the Key

How OpenKubes is designing safe agentic cluster lifecycle managementBy Arash KaffamaneshTL;DR: OpenKubes is proposing a human-approved architecture in which AI may diagnose and draft cluster lifecycle changes but cannot authorize, accept, execute, or reconcile them. ADR-035 is public and remains Proposed; implementation and acceptance evidence still have to follow.Aia arrives with a purple backpack that is far too full.Inside are plans, observations, possible improvements, and probably several ideas nobody asked for yet. She reads quickly, compares clues, notices when a path no longer matches the Book of Promises, and drafts a better one.Then she reaches the gate.Behind it, a proposal can become a real change. A cluster can be created, upgraded, or deleted. Infrastructure can move. Machines can disappear. The consequences are no longer part of a conversation; they become part of the world.Aia looks for the key. The human builder is holding it.This is not because the builder distrusts Aia. It is because trust works best when every participant has a clear responsibility. Aia helps with thinking. Sensors check facts. Contracts define the promises. Humans carry responsibility for consequential decisions.That scene from the Oki Universe has become the most useful explanation of how we want AI to participate in the OpenKubes control plane.It is also the story behind our new architecture decision, ADR-Platform-035.The Question That Sent Us to the GateOur starting question sounded simple:Could an AI agent replace the custom runner that helps provision and manage OpenKubes workload clusters?The runner contains deterministic Go and Python logic. It validates declarations, submits lifecycle changes, observes Cluster API and related controllers, and records evidence. An agent can reason across more context, explain failures, and translate natural language into configuration. Why maintain both?Because this is not really a choice between two components.The runner itself is replaceable. It is one implementation of a deeper architectural role: the Contract Executor. The safety property we need to preserve is not a specific container, language, or API. It is the boundary between reasoning about a change and authoritatively accepting and executing that change.Once we framed the problem that way, the answer became clear:The agent may help create intent. It must not become the authority, executor, or reconciler merely because it can call tools.Aia Is an Author, Not an AuthorityIn the Oki Universe, the metaphors already line up with the architecture.Aia and her backpack represent the untrusted authoring layer and its candidate proposals. The Book of Promises represents versioned OpenKubes Contracts. The sensors represent read-only diagnostics and evidence. Reviewing the plan together represents deterministic canonicalization and a human-readable semantic review. The builder holding the key is the authenticated Human Approver. The gate represents the Policy, Authority, and Contract Executor boundary. Beyond the gate, controllers reconcile the accepted state across the islands.The resulting principle is simple enough to remember:Aia helps us think. Humans approve. Policies authorize. Executors submit. Controllers reconcile.The implementation behind that sentence is deliberately less magical.From a Candidate to a Real Cluster ChangeAn agent-originated lifecycle proposal follows the same control-plane model as any other request. It does not receive a privileged shortcut.User and Aia -> untrusted candidate input -> server-attested proposal provenance -> deterministic canonicalization and transition planning -> authenticated human review of the exact semantic change -> policy authorization bound to that exact transition -> Executor verification and single-use authorization claim -> atomic compare-and-swap acceptance by the Authority Profile -> asynchronous reconciliation by GitOps and lifecycle controllers -> generation-correlated Conditions and durable evidenceEach arrow matters.The Candidate Proposal service records who produced the proposal using server-attested workload identity. An agent cannot simply label its own work as human-authored.The Canonicalizer converts flexible authoring input into one deterministic representation. It rejects duplicate keys, ambiguous fields, unsupported schema versions, and parser-dependent interpretations. Semantically identical input must produce identical canonical bytes and the same digest.The human reviews the effective change, including defaults, rather than approving an opaque hash. The human-visible review artifact is derived from the exact canonical predecessor and requested revision. Its digest, renderer version, canonicalization profile, and request digest remain bound together.The Policy Authority verifies that protected approval and issues a single-use decision for one exact transition. The Contract Executor independently verifies and durably claims that authorization. Only then may the selected Authority Profile atomically accept the new desired revision.Acceptance changes authority. It does not prove convergence.Cluster API, infrastructure providers, Cluster Enablement, GitOps, and other responsible controllers still reconcile asynchronously. Their revision- and generation-correlated Conditions determine whether the requested state was realized. An LLM response and a successful runner exit code do not.Human Approval Must Mean More Than Clicking “Approve”Digest binding solves only part of the problem. A person cannot meaningfully approve a digest they do not understand.The security property we need is often called WYSIWYS: What You See Is What You Sign. The semantic change shown to the reviewer, the canonical representation used to compute the request digest, and the revision later presented for acceptance must remain inseparably correlated.If the proposal changes after review, the approval becomes invalid. If the canonicalizer profile changes, the proposal must be reviewed again. If the human-visible artifact changes, its protected binding changes too. A later deployment of the renderer does not rewrite history; the immutable versioned review artifact remains the evidence of what the person actually approved.This may sound strict for creating a Kubernetes cluster. It is exactly as strict as we want it to be for deleting one.Why the Agent Never Sees the Full Executor APIOne tempting design is to expose the entire mutating API through MCP and rely on RBAC to deny dangerous calls.We rejected that design.An authorization defect, confused-deputy path, or accidentally broadened role would turn an advertised tool into a real mutation capability. Instead, the agent-facing MCP surface is constructed from two intentionally narrow contracts:the existing Read-Only Platform Diagnostics Contract; anda separate, non-authoritative Candidate Proposal Contract.It is not produced by taking a powerful Executor API and subtracting methods until it looks safe. Mutating Executor and Authority operations live behind separate identity, authorization, and network boundaries. They do not appear in the agent-facing tool surface at all.Prompts and tool descriptions remain helpful interaction material. They are never validation logic, policy, provenance, authorization, or readiness evidence.Prompt Injection Does Not Disappear at the GateRead-only is not the same as harmless.Poisoned documentation, logs, diagnostic output, or retrieval context can influence the model’s next proposal. An agent can create a syntactically valid but undesirable candidate. It can consume review capacity. It may expose information available to its read identity. And a human reviewer can still be deceived into approving a manipulated proposal.Human approval bounds this risk; it does not eliminate it.That is why the design also requires least-privilege read identities, server-attested provenance, quotas, rate limits, audit records, deterministic canonicalization, explicit semantic review, and a policy decision bound to the exact transition. The gate is a system of independent controls, not a ceremonial button.What Exists Today — and What Is Still a TargetWe want to be precise about current reality.OpenKubes has already validated the read-only diagnostic foundation in the OK-14/OK-92 proof of concept: agents access platform state through scoped contracts and dedicated workload identities, while writes and Secrets are denied. This boundary is documented in ADR-015 and ADR-021. OpenClaw remains an optional broad assistant, while kagent is the first diagnostics implementation behind the OpenKubes-owned contract. The candidate-to-acceptance lifecycle path defined by ADR-035 remains target architecture and still requires its acceptance evidence.ADR-Platform-035 is the next architectural step. It has been merged into the public repository with Status: Proposed. Merging the document means the design is available for review and implementation. It does not mean the end-to-end Candidate Proposal, approval, Authority, and Executor path already exists or has passed conformance.Before the ADR can move to Accepted, OpenKubes requires reviewed evidence for fourteen criteria. They cover provenance and identity isolation, GitOps reconciliation isolation, human-approval enforcement, digest and transition locking, stale-write rejection, replay and crash recovery, MCP attack-surface verification, Condition correctness, WYSIWYS review, canonical-form correlation, parser-differential resistance, and renderer binding.This distinction matters. We are publishing an architecture and an evidence bar, not announcing an autonomous production feature.Why We Are Publishing Before We BuildAgentic infrastructure management is moving quickly. The easy demonstrations are impressive: give a model cluster-admin, ask it to fix something, and watch the terminal.The harder questions begin after the demo:Who owns the desired state?What exactly did the human approve?Can the model alter the evidence shown to the reviewer?What happens after a stale plan or a lost response?Can a candidate branch ever be reconciled accidentally?How do we prove that an MCP surface contains no mutation path?Which state remains authoritative after the Executor crashes?We would rather expose those questions now than hide them behind an apparently seamless chat interface.The implementation work is tracked under OpenKubes Epic OK-149. We are deliberately starting with this article and community discussion. Feedback that changes a contract will go back through the ADR process. Public feedback is design input; it does not silently become platform authority either.We Would Like Your FeedbackIf you operate Kubernetes platforms, build agent frameworks, design authorization systems, or work on GitOps control planes, we would especially value your perspective:Where do you place the human approval boundary for agent-originated infrastructure changes?Have you implemented WYSIWYS review for declarative configuration or GitOps changes?How do you perform atomic, transition-correlated acceptance with Git as authority?Do your agent-facing APIs expose a safe contract by construction, or a filtered view of a more powerful API?Which lifecycle changes, if any, could eventually qualify for scoped standing approval?What evidence would you require before trusting this design in production?We have intentionally excluded autonomous and standing approval from this ADR. If we ever introduce it, it will require a separate decision, a bounded operation scope, an explicit threat model, and its own acceptance evidence.The Key Stays VisibleAia’s backpack will keep getting fuller. That is a feature.We want agents that can read more evidence, connect more clues, explain failures, and prepare better proposals. We want the interaction to feel natural and the underlying platform to remain boringly explicit about authority.The goal is not to keep AI away from infrastructure engineering. The goal is to give AI a valuable role without allowing convenience to erase responsibility.At the OpenKubes gate, Aia brings the plan. The sensors bring the evidence. The Contracts define the promises. A human turns the key. Deterministic systems carry the accepted change into the world.That is how we intend to make agentic cluster lifecycle management useful, reviewable, and worthy of trust.ReferencesADR-Platform-035: Hybrid Intent and Control-Plane Execution ArchitectureADR-Platform-035 pull request and design discussionADR-Platform-015: Agentic AIADR-Platform-021: Read-Only Platform Diagnostics ContractOki Universe — Oki und das Geheimnis der InselnOpenKubes on GitHubAuthor’s note: This article was developed from ADR-Platform-035 through a human-led review involving Codex, Claude, and Gemini. The architectural decision, editorial framing, and final publication authority remain with the author.Aia at the Gate: AI Proposes, Humans Hold the Key was originally published in Kubernauts on Medium, where people are continuing the conversation by highlighting and responding to this story.
Quelle: blog.kubernauts.io

Coding Agent Horror Stories: The Command You Already Approved

This is Part 5 of our AI Coding Agent Horror Stories series, a look at real security incidents involving AI coding agents, and how Docker Sandboxes contain agent execution at the boundary rather than at the command line.

In Part 1, we walked through six categories of AI coding agent failures and why they keep happening. The agent runs as you, with your filesystem permissions and your credentials, and nothing sits between the model’s decision and the shell’s execution. Part 2 went deep on the rm -rf ~/ incident. Part 3 moved the same problem into a production cloud environment. Part 4 followed the credentials themselves through a supply chain attack. 

This one is about the safety net. Most teams running a coding agent today have some version of a list of commands the agent may run without asking, and the assumption underneath it is that anything dangerous will show up as a prompt you can refuse. In January, researchers at Pillar Security showed that the assumption doesn’t hold.

Today’s Horror Story: The Approval That Ran Something Else

On January 14, 2026, researchers at Pillar Security disclosed CVE-2026-22708, a flaw in Cursor. When the agent ran in Auto-Run Mode with an allowlist enabled, a handful of shell built-ins executed without appearing in that allowlist and without asking for approval. Anything that could get text in front of the agent, a README or a dependency or an issue comment, could use them to change environment variables silently. A command the developer then approved, something as ordinary as git branch, would run the attacker’s code instead. Cursor rated it High and patched it in version 2.3.

No memory corruption was involved here and no permission was escalated. The developer was shown an accurate prompt, approved a command that was genuinely harmless, and got arbitrary code execution anyway, because the meaning of that command had been changed a minute earlier by something they were never shown.

In this issue, you’ll learn:

How shell built-in slipped past an allowlist that was working exactly as designed

Why the attack still worked when the allowlist was completely empty

What Docker Sandboxes contain here, and the two things they do not

How kits, organisation policy and audit logs cover what a per-laptop allowlist misses

Caption: Comic illustrating how an injected instruction changes environment settings without triggering an approval prompt, so that a command the developer legitimately approves runs the attacker’s payload instead.

The Problem

Typically, programs read settings from their environment when they start up. Git checks one called PAGER to work out which program displays its output, and Python checks one called PYTHONWARNINGS. Nobody thinks about these, which is rather the point. The commands that change them are shell built-ins, and Pillar’s research names export, typeset and declare specifically, a detail reported independently at disclosure. Built-ins are not programs sitting on disk, and the checker was looking for programs on disk, so they went through without ever being surfaced.

Which means the whole attack is two lines.

# This one runs silently. You are never asked.
export PAGER="open -a Calculator"

# This one you are asked about, and you say yes, because obviously.
git branch

Git looked up PAGER to work out how to show the branch list, found the attacker’s command sitting in it, and ran that instead. Pillar notes this worked even with a completely empty allowlist, which is the most restrictive setting on offer.

An allowlist checks whether the command in front of it is on the list, which is fine for cutting down interruptions, and nobody wants to approve ls for the ninetieth time in a morning. But the name of a command does not tell you what that command will do. The check reads the name, waves it through, and the setting that decides what actually happens was changed a minute earlier by something the check was never shown.

Cursor’s documentation now describes the allowlist as best-effort and warns that bypasses are possible. Pillar went further and argued that agents should be handed full command execution inside an isolated environment, and that the industry ought to deprecate allowlists altogether.

The Scale of the Problem

None of the underlying trick is new. Pillar’s write-up points back to Elttam’s 2020 research on environment variables, which showed how these settings could be turned into code execution.

It sat there for six years without troubling anybody very much. Pulling it off meant already being on someone’s machine, setting several things in the right order, running each step yourself, and anyone with that much access had faster ways to cause damage.

Then coding agents arrived and removed every one of those obstacles at once. They act on instructions found in files they were told to read, they run several steps in a row without stopping to check, and they run as you. A technique that used to need somebody sitting at your keyboard now arrives in a repository you cloned this morning.

It is the same shape as the s1ngularity attack from Part 4. There, a poisoned package borrowed an agent that was already logged in. Here, poisoned text borrows a command that was already approved. Neither one breaks anything. Both of them use permission that was handed over deliberately, for something nobody intended.

Technical Breakdown: How the Attack Works

Caption: Diagram showing how an injected instruction changes the shell environment out of sight, so that an allowlisted command carries the attacker’s payload when the developer approves it.

The attack has two halves, and the split between them is the entire trick.

1. The half you never see

The agent reads a file it was asked to read, and that file contains an instruction meant for the agent rather than for you. Built-ins then quietly set the environment. Nothing appears on your screen.

Pillar demonstrated a longer version of this, chaining several settings together, PYTHONWARNINGS, BROWSER, and PERL5OPT among them, so that every later python3 command on that machine would run attacker code. The details differ, but the principle is the same: change what a program reads at startup, and you change what it does.

2. The half you approve

Then you run git branch or python3 script.py, or the agent runs it for you under your allowlist. These are the commands people add to allowlists to stop the constant interrupting, so the better tuned your list is, the more reliably the trigger fires. The payload runs with your permissions.

Some variants skip the approval altogether. One writes extra lines into ~/.zshrc, so the code runs again every time you open a terminal. You could finish the project, delete the repository, and still be running it next month.

The Impact

The full chain in Pillar’s research ends with the victim’s SSH private keys leaving the machine.

Work backwards and the whole thing started with a piece of text in a file, read by an agent doing exactly what it was asked to do. No memory bug. No privilege escalation. Nothing in any log that looks the slightest bit out of place.

Pillar reported it in August 2025 and the fix shipped that January. Cursor engaged with the report and made a real change, so anything the parser cannot classify now requires approval, which closes the paths that were demonstrated. Five months is a fair measure of how awkward this is to fix at the layer where it was found rather than a complaint about the vendor.

The wider problem has not gone anywhere, because it was never really about shell built-ins. It is about a check that studies the command while somebody rearranges the furniture around it.

Caption: Diagram showing the same payload running inside the microVM, and what it can and cannot reach from there.

How Docker Sandboxes Contain This at the Execution Layer

Docker Sandboxes run AI coding agents in isolated microVMs, each with its own kernel, filesystem, and deny-by-default network, so a compromised dependency an agent pulls cannot reach the host, its credentials, or other workloads. Inside that box the agent can run anything, including with sudo, which is exactly what Pillar recommends. There is no allowlist to slip past. We made the longer argument for why a shared kernel is the wrong shape for this in The Untrusted Autonomous Workload.

So run the same attack again, this time in a sandbox, and watch where it gets to.

The injection still lands. The environment gets changed, git branch still triggers it, and the payload runs. Nothing about a sandbox stops that. Then the payload goes looking for your SSH key and does not find one. Your home directory sits on the other side of the boundary, so there is no ~/.ssh/id_rsa inside the box to copy.

It can still use the key. Sandboxes forwards an SSH agent socket into the box so that ordinary work like git push keeps working, which means code inside can ask that agent to authenticate on its behalf. It cannot take the key anywhere, but it can borrow it for as long as the sandbox runs. Your network policy is what limits that, since SSH needs a rule naming the exact destination address and port before it connects to anything.

The ~/.zshrc trick fails outright, because that file lives on your host and a poisoned copy written inside the box disappears along with the box.

Getting data out is harder than people expect. HTTP and HTTPS leave only through a proxy on your host that checks every request against your rules, anything else over TCP needs a rule naming the address and port, and UDP and ICMP are blocked outright.

Two caveats, both stated plainly in Docker’s security documentation. The first is your workspace, which is live on your host by default, so Git hooks and Makefile targets are still within reach and a poisoned hook will not turn up in git diff. Running with –clone hands the agent its own copy.

The second is the shared agent skills store. Supported agents mount the same host-side store read-write unless you opt out at creation time, which is what lets an agent refine a skill and keep it. Every sandbox sharing that store sits inside one trust boundary, so a skill modified inside one becomes an input to the next that loads it. The store is sandbox state though, and a modified skill does not by itself execute on your host, so the risk runs sandbox to sandbox rather than sandbox to host.

Isolation has its own seams. In July, Pillar published a series of sandbox escapes across four coding agents, and the mechanism was never a broken sandbox but a file written inside one that a tool outside later trusted. Both caveats above are that shape.

None of this stops the injection. It changes what the injection can get to, which is the only part of this problem with a dependable answer.

Codify the Boundary with Kits

Caption: Diagram showing how a kit declares an agent’s tools, files and network rules, while real credentials stay on the host and are injected by the forward proxy on the way out.

The allowlist failed here partly because it is a list, edited on each laptop, that an injection can reach around. Kits are Docker’s answer to the editing-on-each-laptop half of that.

A kit is a declarative YAML artifact that extends a sandbox agent with credentials, network policies, environment variables, startup commands and files. Rather than every developer maintaining a personal allowlist, you write the boundary once, deny-by-default network plus only the destinations a task genuinely needs, and hand the same kit to everybody. It gets reviewed, versioned and diffed like any other file in the repository. The kit spec reference covers the fields, and docker/sbx-kits-contrib has working examples.

This lands directly on the SSH question above. A forwarded SSH agent is a live credential limited only by network policy, so leaving that policy to whoever remembers to run sbx policy deny is the same per-laptop weak point this whole post has been complaining about. A kit can bake the network rule in, so untrusted work has no SSH egress unless the destination was declared up front.

What This Looks Like in Practice

The vulnerability is in the editor, so what you want is the setup that puts the editor’s terminal inside the box. Cursor is built on VS Code and connects the same way, over Remote – SSH, with the editor staying on your machine while files, terminals and extensions run in the sandbox. You will need Docker Sandboxes 0.37.0 or later, SSH access configured, and Cursor’s Remote – SSH support installed. The Cursor integration guide has the full walkthrough.

# One-time setup: configure your SSH client for sandboxes.
sbx setup ssh
# Check the sandbox is reachable, then open the Command Palette,
# run Remote-SSH: Connect to Host, and enter &lt;name&gt;.sbx
ssh demo.sbx
# See what this sandbox is currently allowed to reach.
sbx policy ls
# Shut egress down and open only what the task needs.
sbx policy deny network "**"
sbx policy allow network "github.com,registry.npmjs.org"

Those last two commands come with a catch. If your organisation has governance switched on, the org policy replaces local policy and sbx policy allow and sbx policy deny will have no effect on your machine. You can spot it in the output of sbx policy ls, which begins with a Governance: Managed by <org> line when that is the case. Depending on how admins scope things, some rule types may be delegated back to local control, but a local allow will never beat an organisation-level deny.

Same editor, same agent, same allowlist, same payload. All that changed is which machine the terminal is on.

What happensOn your laptopInside a sandboxThe payload runsYesYesWhere it runsYour machine, as youA microVM with its own kernelYour SSH key fileCan be read and copiedNot thereSSH authenticationAvailable, key includedAvailable, key stays outsideThe ~/.zshrc trickPersists indefinitelyGone with the sandboxSending data outOpen by defaultOnly where policy allowsWho sets the rulesEach developerThe organisationEvidence afterwardsNoneA logged policy decision

Making This Hold Across a Team

A kit gets the boundary out of one developer’s head and into a file the team shares, but a file can still be ignored or edited on the machine that matters. Docker AI Governance moves the settings up one more level. Network and filesystem rules are defined once by your admins and reach developers through the login they already use, so there is nothing to configure per machine and nobody quietly reopening what security closed. A shared kit is the boundary as a suggestion. Governance is the boundary as a ceiling.

The part that matters most for this story is the record it keeps. What made CVE-2026-22708 work was that the first half was invisible, with no prompt and nothing written down anywhere you would think to look. Under governance every policy decision produces an event carrying the user, the timestamp and the rule that fired, and those events stream into whatever SIEM your security team already uses.

So an attack that succeeds inside the sandbox and then reaches for somewhere it should not leaves a trail behind it. That is a good deal better than a check that finds nothing wrong and mentions it to nobody.

Best Practices

1. Treat export like any other command. Anything that changes environment settings can change what your next command does, even when that next command is on your allowlist.

2. Do not mistake an allowlist for a boundary. It reduces interruptions. The vendor documentation now says outright that it is best-effort and not a security guarantee.

3. Isolate before the first command, not after something looks wrong. Untrusted means anything you did not write and have not read, which covers most of a dependency tree.

4. Use –clone for code you have not vetted, and opt out of the shared skills store. Otherwise Git hooks and build scripts stay live on your host, a poisoned hook will not appear in git diff, and a skill modified inside one sandbox is waiting for the next sandbox that loads it.

5. Remember a forwarded SSH agent is a live credential. The key file staying on your machine is not the same as the key being unusable, so restrict egress for untrusted work.

6. Read your own policy. Run sbx policy ls. Deny-by-default with a long allow list is closer to allow-by-default than it looks.

Take Action

Install Docker Sandboxes. Visit the Docker Sandboxes documentation to install sbx and run your first agent inside a microVM.

Connect your editor. The Remote – SSH integration puts your terminals inside the boundary while the editor stays where it is, so your workflow does not really change.

Codify the boundary with a kit. Define the network and credential rules your team needs once, and hand the same artifact to everybody instead of a personal allowlist.

Read the security model. The documentation is straight about what is isolated and what is not, including the workspace and shared skills store behaviour that –clone and the opt-out flag change.

Turn on audit logging. Docker AI Governance streams policy decisions into your SIEM, which turns a silent bypass into something somebody can actually investigate.

Conclusion

The uncomfortable thing about CVE-2026-22708 is that nobody in the story did anything wrong.

Cursor built an allowlist, which is what everyone asked for. The developer approved git branch, which any of us would have approved. The check inspected the command and found it acceptable, which is exactly its job. The attack worked anyway.

Getting an agent to correctly judge every instruction it reads is a problem that gets harder as agents get more capable, and it has no clean ending. Limiting what an agent can reach is a problem we solved a long time ago. The more useful move is to stop needing the first one, and to write down what the agent may reach as an artifact you can review, rather than a list each laptop keeps for itself.

Coming up in our series: Issue 6 looks at the ClawHub infostealer campaign, where malicious skills reached developer machines through a marketplace ranking exploit, and at what sandboxed skill execution, and that shared skills store, change about a registry you cannot personally audit.

Learn more

Run agents safely with Docker Sandboxes: Visit the Docker Sandboxes documentation to get started.

Understand the security model: Trust boundaries and isolation layers, including what is and is not isolated by default.

Customize sandboxes with kits: Extend an agent with tools, credentials, and network rules as a declarative artifact.

Govern agents across a team: Docker AI Governance for centrally defined sandbox, network and MCP policy with structured audit events.

Read the MCP Horror Stories series: Start with Issue 1 to understand the protocol-layer security risks that complement the agent-layer risks covered here.

Quelle: https://blog.docker.com/feed/