Agent Flare

A Hermes Agent for each person, in its own Cloudflare Container behind Access, on zero trust principles: access only to what it needs, short-lived, when it needs it.

An agent running unmanaged on a laptop runs with that person's credentials, with reach into the whole Windows system. That's an unacceptable risk, and it isn't zero trust. Agent Flare gives every person their own agent, running on infrastructure the organization controls, with access only to what it needs, short-lived, when it needs it.

Architecture

Diagram: the Hermes desktop app on a laptop connects through cloudflared, outbound only, to Cloudflare Access and then a per-person tunnel into that person's container on Cloudflare Containers. A client script signs in through Access to a Worker that provisions tunnels and wakes and stops containers. Each container snapshots its home directory to R2 as squashfs and calls models through AI Gateway with API keys and AI Gateway headers. Some credentials are kept in KV and Worker secrets. — The only way in is Cloudflare Access: sign in, then an outbound-only tunnel to your own container. The agent never runs on the laptop.

How it works

Sign in. A client script opens Cloudflare Access SSO. Nothing else works until that's done.
Provision. A Worker verifies the Access token, creates a Cloudflare Tunnel and hostname for that person through the Cloudflare API, and issues a dashboard session token. Some credentials are kept in KV and Worker secrets.
Wake. Each person has their own container, tied to their own Durable Object. On wake, the Worker restores the newest snapshot from R2 before Hermes starts. After 30 minutes idle, the container sleeps.
Connect. The Hermes desktop app talks to localhost, and cloudflared carries that connection outbound through Access to the person's tunnel. No inbound ports anywhere, and the container is never directly exposed.
Models. The agent calls models through AI Gateway, using API keys and AI Gateway headers on each request.
Persist. Every 10 minutes (configurable), and before a stop, the container's home directory is saved to R2 as a squashfs snapshot using the Sandbox SDK. Pruning keeps recent snapshots dense and older ones sparse.

Design decisions

Outbound only. The laptop opens no ports and neither does the container. Every connection starts from the inside and passes through Access.
Keep the install apart from the state. The container image holds Hermes itself; snapshots carry only what the person changed, so they stay in the tens of megabytes.
Wait for the restore. The image ships with an empty home, and Hermes waits for the restore before it starts, so a failed restore can't pass for a healthy fresh start.
Sleep when idle. Idle agents cost nothing to keep around and come back where they left off.

The squashfs persistence pattern and the install/state split build on Carter Morgan's open-source hermes-flare (Apache 2.0).

What's next

Diagram: planned design. A browser opens the Hermes webapp with Cloudflare Access as the first hop and no tunnel. The person's container has internet off and no credentials inside, and still snapshots to R2. The agent's terminal runs in a Sandbox per agent. All outbound traffic from the container and the sandbox goes through outbound handlers in the Workers runtime, then to AI Gateway with DLP for models, and through a Workers VPC binding into Cloudflare Gateway with DLP for web traffic. — Planned: a browser as the only client, a sandbox per agent, and every outbound request under Gateway and DLP.

Hermes webapp. The container runs the Hermes web app behind Access directly. A browser becomes the only client, and the tunnel goes away.
A sandbox per agent. Terminal access runs in a separate Cloudflare Sandbox per agent, outside the container that holds the agent's state. Its internet access is off by default, and its traffic takes the same path through the outbound handlers, Gateway and DLP.
Outbound handlers. All outbound traffic goes through outbound handlers in the Workers runtime: internet off by default, a host allow-list that can change while the agent runs, and credentials added to each request so the agent never holds them.
Gateway + DLP. Web traffic leaves the handlers through a Workers VPC binding into Cloudflare Gateway, with the same DNS, HTTP and network policies and logs as user traffic, and DLP on outbound content. DLP in AI Gateway scans prompts and responses.
Secrets out of backups. Credentials move out of the R2 snapshots into a dedicated secret store.
Container sizing. Currently 1 vCPU and 6 GiB; larger and smaller sizes to be tested.

Open source under the MIT license: nutmegitconsulting/agent-flare.