Matthew Slipper

@jjackyliang You don’t! Inject them at the network so the agent never gets the secret. We’re building this at iron.sh.

in all seriousness what's the best way to secure env vars for agents?

This is available in iron-proxy v0.23.0+. Release notes here: github.com/ironsh/iron-pr…

iron-proxy now supports MCP inspection and policy enforcement. Whitelist exactly the tools your agent needs, and audit every call. This is where other tools like Squid fall short. They understand URLs, but not the protocols agents are actually speaking.

Pin versions, set a minimum release age, and run an egress proxy in front of anything running potentially untrusted code. Do this now, before this happens again next week.

@FUCORY @AFDudley0 Good take except for the Ruby hate

This is the real reason I don’t use typescript as much anymore We used to use typescript because of how fast devs ship with it. But agents ship faster with go. So why are we using typescript?

Seeing more and more folks opting to bring their own compute rather than using sandboxes. Boring EC2 instances / k8s pods often work just fine.

The deletions will continue until egress control improves

@alexellisuk Thanks! I love Squid but it's limiting with agents. Very impressed with Slicer btw... the CA injection + network config makes it really easy to set up egress proxies.

@mslipper Finally someone’s innovating instead of cloning Squid

New in iron-proxy v0.15: the judge transform. Give your config a prompt, and it'll evaluate matching requests against it via an LLM. Support both Anthropic and OpenAI backends. Default-deny still applies: the judge can only reject. Release notes: github.com/ironsh/iron-pr…

@derekdfulton @utpalnadiger You probably could but I opted to remove it instead. 70% of boot was systemd; the rest was kernel init.

@mslipper @utpalnadiger Really? Did not know that. Could you install systemd async after first boot in a bg job or something?

Firecracker is 83K lines of Rust that boots in 125ms (and runs AWS Lambda fwiw) QEMU is 1.4M lines of C that can emulate a Sound Blaster 16. It's a beast. Most agent sandboxes picked Firecracker. We picked QEMU. Agents are about to get 100x more ambitious. Function runtimes won't cut it. We're building the computer they'll actually need.

5/ This matters especially for coding agents. Even if the agent gets prompt-injected into posting a "comment" full of secrets, the comment still has to pass the judge. If your agent can reach GitHub, today's a good day to secure it. iron.sh

4/ At this point everything left looks legitimate. As a final layer of defense, add a judge transform to read the request body in flight and classify it against a policy you write in English:

1/ Malware continues to dump secrets on GitHub. Today's Bitwarden CLI backdoor is just the latest of many examples. Hostname allowlists can't tell good GitHub traffic from bad. You need a filter that actually understands the GitHub API. Here's how.

Hat tip to @brexhq's CrabTrap, which inspired this design: github.com/brexhq/CrabTrap

@tsenart Working on it! I just added an LLM judge transform, will be documenting + releasing that later this week. This is will slot in there nicely: github.com/ironsh/iron-pr…

Great, now put this in iron-proxy @mslipper

@nicklaassen SPIFFE and workload identity are awesome for your own services, but secrets are here to stay for everything else.

@mslipper Secrets themselves are an antipattern. Ideally you want every workload to have a verifiable identity tied to the platform or a TPM. With a SPIFFE-like system to distribute trust and issue certificates, services can auth with mTLS. Identity cannot be stolen

IMO putting secrets in env vars is an antipattern. The Vercel thing makes that clear. Workloads shouldn't have secrets at all. Keep them in a vault instead and have an egress proxy inject them on the way out. This will seem obvious in a year.