Building a hardened, image-based foundation for AI agents

This week, I developed a community operating system image for running AI agents: an agentic OS prototype. It is built using fedora-bootc, a community project that allows for defining a bootable Linux OS directly in a Containerfile. The creation of this agentic OS spotlights a critical evolution: By providing a hardened, image-based environment, it establishes a robust community template for what an agentic OS can look like in practice. It explores how a dedicated runtime built with open source tools could look – an example of open source’s profound ability to deliver a reliable infrastructure layer necessary to move from theoretical agent behavior to production-ready systems.  

What is fedora-bootc?

To run any application in containers, you typically craft a Dockerfile, build an image, push it to a registry, pull it somewhere else, and run it. fedora-bootc takes that same ubiquitous workflow and extends it across entire operating systems. 

As a Fedora community project, fedora-bootc uses Open Container Initiative and Docker containers as the transport and delivery format for base operating systems. A fedora-bootc image includes the Linux kernel and can be converted into a full disk image (QEMU Copy On Write version 2 (QCOW2), Amazon Machine Image (AMI), ISO 9660 Image, Google Cloud Image, etc.). Once booted, the container image is the system – owning the kernel, init process, and root filesystem. Most of the filesystem is read-only. You define your OS at build time, and at runtime, you’re limited to what you explicitly allow to change. I refer to these as “image-based systems,” providing the peace of mind that comes with a reproducible, hardened environment.

The agentic OS: Why I built this image

I think an agentic OS should be an opinionated, image-managed Linux system where the agent’s runtime is a first-class concern, and the host’s attack surface is minimized by design. I wanted a way to run OpenClaw that was reasonably sandboxed and easy to replicate across a fleet. My usual setup – spinning up a virtual machine and manually installing packages – can lead to system drift. With this agentic OS, the OpenClaw service, helper scripts, user accounts, and systemd units are all declared at build time. 

To update the environment, you simply push a new image to your registry. Any running machine pulls it, compares digests, and reboots into the new update via sudo bootc upgrade. Updates are transactional, like checking out a new git commit, making rollbacks trivial. This can allow your secrets, OpenClaw state, and SSH keys to remain untouched and intact even as the core OS evolves.

Compare this to traditional systems where the agent’s runtime, OS packages, config files, and secrets are all tangled together in a single mutable filesystem. When something goes wrong in a mutable system, figuring out what changed is difficult. In this image-based architecture, the separation of concerns is built into the architecture. 

The power of the fleet

For fleets of systems, this image-based approach prevents drift. Picture a lab with a dozen machines. Each one boots the same agentic OS image and each one comes up with OpenClaw running exactly as expected. Versions and configurations are kept in perfect sync. When it’s time to update, every machine checks the registry, pulls new layers only if the digest doesn’t have a match, and reboots.

Or consider edge devices. These are often small boxes running AI agents for specific tasks, each with its own OpenClaw interface. In this scenario, the host OS is locked down and mostly read-only. With image-managed, transactional updates, the agent has exactly what it needs and nothing more. What this set up ultimately allows is an AI agent running on a built-for-purpose, image-managed, and hardened OS with scoped credentials and transactional updates.

How it works using fedora-bootc

This agentic OS provides a stable runtime that is designed for predictable operation by default, and the OS layer is read-only and image-managed. I used quay.io/fedora/fedora-bootc:latest as the base OS. The Containerfile installs Podman, cloud-init, SSH, and Python, then creates a dedicated openclaw  user. Here’s what happens next:

• Non-root isolation: The agent runs as a non-root user. OpenClaw operates as a rootless Podman container managed by Quadlet.
• State management: While the OS layer is read-only, the agent’s mutable state lives in a single directory (~/.openclaw).
• Scoped access: I added service-gator, a light-weight personal gateway tool that sits between the agent and external services (GitHub, JIRA, etc.) to enforce permission scopes rather than using raw personal access tokens. While this is ideal for individual set ups, MCP Gateway is designed to fill this role at scale and in production for cluster deployments.
• Native feel: A CLI wrapper on the host allows you to run openclaw commands naturally, while the logic executes inside the container.

Secrets stay out of the image

Security is paramount in an agentic OS. No secrets are baked into the image. Instead, you need to SSH in as the openclaw user and create Podman secrets after the boot: 

printf '%s' "$OPENAI_API_KEY" \
  | podman secret create openai_api_key -
printf '%s' "$OPENROUTER_API_KEY" \
  | podman secret create openrouter_api_key -

Then run tank-openclaw-secrets, a helper that wires those secrets into the Quadlet drop-ins and OpenClaw's config as secret references. OpenClaw’s SecretRefs avoid plaintext environment variables by wiring those secrets into the configuration. They also support file and exec options, providing a path to wire in external providers like 1Password or Vault CLI. This allows you to stamp out identical machines from one public image while injecting unique, per-instance credentials via cloud-init, SSH or whatever provisioning you prefer. The service restarts, picks up the keys, and you're running.

What could the future look like?

This pattern demonstrates the potential of image-based agent hosting through its combination of fedora-bootc for the OS lifecycle, rootless Podman for isolation, Quadlet for service management, and OpenClaw agent runtime as the primary workload. 

The project serves as an example of community innovation for exploring agentic OS, and it also reflects Red Hat’s broader enterprise roadmap. Earlier this year, we shared our plans for a more secure, production-ready foundation for the agent-ready workforce with NVIDIA. Specialized agent sandboxes like OpenShell introduce advanced guardrails, including network egress filtering, filesystem restrictions, and process constraints. 

In a production environment, these two layers could complement each other quite well: an image-managed operating system layer handles the reliable, image-managed operating system layer, while OpenShell enforces the fine-grained security policies for the agent itself. To me, imagining the potential for a community project like this one helps me realize its real-life value and application – serving as the stable, repeatable foundation upon which the next generation of secure, autonomous AI solutions can be built. 

Want to get involved? Try out the image at quay.io/redhat-et/tank-os:latest. Pull it, build a disk image, boot it! And don’t forget to check out the project repository for documents on building, provisioning, and configuring.

The projects discussed in this blog represent early-stage research and development from the Red Hat Emerging Technologies team. These are upstream open source projects and are not official Red Hat products. There is no guarantee that these projects will become products or be integrated into existing Red Hat offerings.