Gatesi lockdown kit
======================
Goal: an agent that CANNOT skip Gatesi, even if it wants to.

Gatesi only controls what goes through it. An agent that also has its own passwords or open internet access can
simply go around. Lockdown closes both doors:

  Door 1 - credentials. Do not give the agent real passwords or API keys. Put them in the Vault tab and let the agent
           call gate.request("service", ...). It never sees them, so it has nothing to misuse.
  Door 2 - network. Run the agent where the ONLY place it can reach is your Gatesi address.
           This kit does that with Docker: the agent sits on a network with no internet route, and a small proxy
           (squid) lets it talk to your Gatesi Worker and nothing else.

Needs: a Linux server, VPS or desktop with Docker + Docker Compose. This does not run on a phone; it is for the machine
where your agent runs. (Docker Desktop on Windows/Mac also works.)

Files in this folder (download each from https://YOUR-WORKER/lockdown/<file>)
  docker-compose.yml   the agent container (no internet) + the proxy container (allowed to reach only Gatesi)
  squid.conf           the proxy rules: allow your Gatesi host, deny everything else
  check.py             proves the lock works: run it INSIDE the agent container

Steps
 1. Make a folder, put the three files in it.
 2. Edit squid.conf: replace agentgate.YOURNAME.workers.dev with your Worker's host name (no https://).
 3. Put your agent's code in this folder as agent.py (or change the command in docker-compose.yml).
    Give it a per-agent key from the Keys tab through the AGENTGATE_URL and AGENTGATE_KEY lines in docker-compose.yml.
 4. Run the proof:   docker compose run --rm agent python /app/check.py
    You want to see:  OK  Gatesi reachable  and  OK  example.com blocked  and  OK  direct connection blocked.
 5. Start the agent:  docker compose up agent

How it works (so you can judge it)
 - The "inside" network is marked internal: Docker gives containers on it no route to the internet at all.
 - The proxy container is on both networks. The agent is told (HTTPS_PROXY) to use it. squid allows CONNECT only
   to the Gatesi host on port 443 and denies everything else.
 - If the agent ignores the proxy and tries to connect directly, there is no route, so it fails. That is what the
   "direct connection blocked" check proves.

Honest limits
 - Written to standard Docker/squid behaviour but NOT tested by Claude here (no Docker in the build environment).
   Run check.py: it tells you whether the lock really holds on your machine.
 - An agent that can run arbitrary code on the host (outside this container) is not contained. Do not mount the
   Docker socket or your home folder into the agent container.
 - The allowed host is the Gatesi Worker. Anything the agent is allowed to do THROUGH Gatesi is governed by your
   policy, so keep your policy and vault rules tight.
 - If you also use Cloudflare's *.workers.dev for other things, they stay blocked: only the exact host is allowed.