What a workstation does not prevent

The limits of a workstation's boundary, in one place.

A key you place on the workstation yourself is readable by everything that runs there, whether it arrives through environment, a file, a script’s env, an MCP server in local mode or, in this release, an llm Integration’s gateway key. If a key has to stay off the workstation, use a credential injection rule instead.

With no egress block, the workstation reaches anything your network routes. Leaving it open is a choice, so make it on purpose: start with audit to see what the workstation needs, then move to strict.

A lima workstation, which is what a Mac runs when vz is unavailable, and a wsl2 workstation enforce nothing outside the machine. A bestEffort policy on either is recorded but not in force, with the reason ProviderCannotEnforce, and strict and audit are refused outright. A lima workstation can reach anything on your Mac’s own 127.0.0.1, and a wsl2 workstation sees your Windows drives, can start Windows programs, and gets no injected key. Use vz, hcs, qemu or a cloud instead.

An audit policy is accepted only where whoever runs the control plane has turned audit on; until then the apply is refused with a message that says so. On your own machine, a one-shot rl refuses it until a daemon that supports it is running.

What a key may do at its API is decided by that API, not by the rule, which sets headers and nothing else. The same goes for models: a policy’s model list judges only the model written in the Integration, and a program on the workstation can still ask the gateway for another. Make a key narrow before it goes into a Secret.

A request to an allowed host is read only where a rule asks for it. For a host no rule injects into or inspects, the Edge decides on the name the connection presents and decrypts nothing. If you want each request’s Host header checked against that name, set inspect: true on the rule.

DNS is a slow way out. Any name resolves, including one the policy does not list, so data encoded into names can leave through your resolver. On a cloud you can control that in your cloud’s DNS configuration; an egress policy cannot.

A policy is not what keeps a GCP workstation away from its own cloud credentials. Google Cloud serves the metadata endpoint at 169.254.169.254 underneath the firewall, so narrow the service account the VM runs as, as the Google Cloud onboarding page describes. On AWS and Azure the same thing is a property of those clouds.

On a local workstation the injected key is held on the machine that runs it, so whoever uses that machine could read it. A rule’s allowDaemonPlacement gate decides which local workstations may hold it, and by default that is only the author’s own.

The local container runtime, the workstation that serves your docker commands, shares your Mac’s folders on purpose. Run an agent in a workstation of its own, not in the runtime.

A writable share trusts the workstation with that folder: everything inside can change it exactly as your Mac user can, while a read-only share holds even against root. Share a project folder, never your home folder, which holds ~/.ringleader and the SSH key for every local workstation.

Where to go next

These pages hold the mechanisms behind each limit: