The Scarier Permission Was Reach, Not Write: Locking an Agent's Outbound Traffic to an Allowlist

Implementation: a small gate that tunnels only allowlisted CONNECTs

It's about 80 lines of standard-library-only forwarding proxy. It matches the CONNECT host against the allowlist and, if it's absent, returns 403 and logs it.

# egress_gate.py — a deny-by-default gate that limits an agent's outbound traffic to allowed hosts
import asyncio, fnmatch, time
 
def load_allow(path="egress_allowlist.txt"):
    with open(path) as f:
        return [ln.strip() for ln in f if ln.strip() and not ln.startswith("#")]
 
ALLOW = load_allow()
LOG = open("egress_denied.log", "a")
 
def allowed(host: str) -> bool:
    # exact match, or a *.example.com wildcard
    return any(fnmatch.fnmatch(host, pat) for pat in ALLOW)
 
async def pipe(reader, writer):
    try:
        while data := await reader.read(65536):
            writer.write(data)
            await writer.drain()
    except Exception:
        pass
    finally:
        writer.close()
 
async def handle(client_r, client_w):
    try:
        head = await client_r.readuntil(b"\r\n\r\n")
    except Exception:
        client_w.close(); return
    line = head.split(b"\r\n", 1)[0].decode("latin1")
    parts = line.split(" ")
    # handle only CONNECT (HTTPS tunnels) so we never see payloads
    if len(parts) < 2 or parts[0] != "CONNECT":
        client_w.write(b"HTTP/1.1 405 Method Not Allowed\r\n\r\n")
        await client_w.drain(); client_w.close(); return
    host, _, port = parts[1].partition(":")
    port = port or "443"
    if not allowed(host):
        LOG.write(f"{time.strftime('%F %T')}\tDENY\t{host}:{port}\n")
        LOG.flush()
        client_w.write(b"HTTP/1.1 403 Forbidden\r\n\r\n")
        await client_w.drain(); client_w.close(); return
    try:
        up_r, up_w = await asyncio.open_connection(host, int(port))
    except Exception:
        client_w.write(b"HTTP/1.1 502 Bad Gateway\r\n\r\n")
        await client_w.drain(); client_w.close(); return
    client_w.write(b"HTTP/1.1 200 Connection Established\r\n\r\n")
    await client_w.drain()
    await asyncio.gather(pipe(client_r, up_w), pipe(up_r, client_w))
 
async def main():
    server = await asyncio.start_server(handle, "127.0.0.1", 8899)
    print("egress gate on 127.0.0.1:8899 / allow:", ALLOW)
    async with server:
        await server.serve_forever()
 
asyncio.run(main())

On the agent side, you just route through the gate with environment variables. Pass these to the Antigravity task/terminal config, or to the shell the agent launches.

export HTTPS_PROXY="http://127.0.0.1:8899"
export https_proxy="http://127.0.0.1:8899"
# for tools that speak plain HTTP (keep this minimal; prefer 443)
export HTTP_PROXY="http://127.0.0.1:8899"

Because CONNECT is the request to open an HTTPS tunnel, the gate decides on the hostname alone. Once it lets a connection through, it simply relays both directions and never inspects the contents. That is what "don't decrypt" means in practice.

Growing a per-project allowlist from empty

My habit is to not write a big allowlist up front. Run one night nearly empty, read the denials in egress_denied.log the next morning, and add back only the legitimate ones, one line at a time. Starting from the denial log is what makes deny-by-default pay off.

# egress_allowlist.txt — one allowed host per line
# code fetch / packages
github.com
*.githubusercontent.com
registry.npmjs.org
# the generative API I use
generativelanguage.googleapis.com
# my own app-ops API (spelled out precisely because it holds a key)
androidpublisher.googleapis.com

The procedure folds into four steps.

The discipline that matters is resisting the urge to "just add it." Left denied, a host shows up again the next morning. One host appeared three days running before I finally understood it (a tool's version check) and added it deliberately.

What 21 nights taught me

I ran the gate across 21 nights of automation around my four apps. Against the total connection attempts, 41 were denied, spread over 9 unique hosts. The breakdown says more about the policy than the raw count does.

The numbers look modest, but the payoff for me was being able to say, with evidence, that across those 41 denials there was zero sign of a payment or ad key reaching an unexpected host. Before, it was "probably fine." Now I just read egress_denied.log. The three forgotten hosts did stall a legitimate step temporarily, but a five-minute edit the next morning cleared each one, and the unattended run itself never fell over.

Where this approach can't protect you

Let me draw the line honestly. It filters at host granularity only, so it can't distinguish an allowed path from a forbidden path within the same host. That's the cost of not decrypting TLS.

It also won't catch tools that ignore the proxy variables and dial an IP directly, or binaries that open their own sockets. For the processes I most want to contain — the heavy ones holding keys — I layer a second measure: isolate them in a separate network namespace, or drop all outbound except port 8899 at the host firewall. Restricting DNS to allowlisted hosts helps too. But for indie-scale work, just making the reach visible with this gate already changed the ground my judgment stands on.

Wrapping up

When we delegate real work to an agent, we tend to squint at what it can change. But for something you've handed a key to, the quieter and less reversible permission is where it can reach.

Your next step can be small. On one project, cut the allowlist down to a few code-fetch hosts and slip the gate in front for a single night. The names that line up in egress_denied.log the next morning will probably tell you, more honestly than anything else, what was actually leaving your machine.