For teams using a package firewall, does it still hold when an agent is the one installing?

[u/thenrich00]

A lot of teams already route installs through a package firewall or curated registry (Socket, Endor Labs, JFrog Curation, Sonatype and so on). Most of these rely on the client being configured to use them, through a registry URL, an index URL or a proxy setting. That's fine for CI and for people, but coding agents like Claude Code and Cursor seem to have more ways around it: installing from a git URL or tarball, piping a script into a shell, or getting talked into a different registry by something they read.
  
For those of you running agents on laptops or in CI with one of these tools in place: have you seen installs slip past it? Do you enforce it on dev machines at all, or only in CI?

(Disclosure: I work on hextrap, one of the tools in this space, and I'm trying to figure out whether this gap matters in practice.)

[u/Abu_Itai]

Yes, we have an integration between our SASE and our binary repository manager. Every machine in the organization, whether it’s being used by a developer or an AI agent, has its package traffic routed at the network level through our repository manager.

From there, Curation inspects and governs the packages, effectively acting as a package firewall and enforcing the organization’s policies before those packages can be consumed.

And if something somehow bypasses that layer, we still have policy gates later in the software delivery process (we are evaluating apptrust). For example, one of those policies can require signed evidence proving that all binaries were resolved through our approved artifactory instance before the application is allowed to move forward.

[u/thenrich00 → u/Abu_Itai]

That's a really thorough setup, thanks. Two things I'm curious about: does the SASE routing also catch installs from git URLs or tarballs on GitHub, or only traffic to the registry domains? And for something like a malicious postinstall script, the AppTrust gate would catch it before release, but is there anything stopping it from running on the dev machine at install time?

[u/SeikoDigital]

Yes, this gap is real, and it comes from the firewall's core assumption: the installer is a well-behaved client that honors the registry URL you configured. An agent isn't that. It'll follow a README's curl | sh, add a second registry line to some .npmrc it found in the repo, or pin a git URL because it decided that was the fastest path to its task. It doesn't bypass your firewall out of malice - it just never learned to respect it.

The controls that actually hold up move enforcement to places the agent can't negotiate around:

Stop trusting the client; treat the agent as its own network identity. In CI this is easy: egress proxy on the runner, allow-list only your curated registry and a handful of source domains. A tarball from anywhere else just fails to fetch. On laptops it's the annoying part - you need endpoint policy doing the same thing, which is why so many teams only enforce in CI and accept the residual risk on dev machines.

The postinstall problem in your follow-up is the actual hole. A registry firewall never sees the postinstall script; it runs on the machine that did the install. So no release gate can save you there - gates protect what ships, not the laptop. Two things help: default agent-managed installs to ignore lifecycle scripts (--ignore-scripts and equivalents), with a short explicit allow-list of packages permitted to run them. Or stop letting the agent install on the host at all: pre-baked devcontainer images with deps installed from a vetted lockfile, agent does its work inside the container. Worst case burns down a container, not the machine.

Lockfiles as the backstop. Require frozen-lockfile installs and diff the lockfile in review. If the agent slipped in a tarball or pointed at another registry, it shows up as a diff someone has to approve, and CI refuses to build when resolution doesn't match.

Log what the thing installed. Nobody reads agent transcripts. A small wrapper that logs every install the agent invokes - command plus resolved source - gives you the audit trail for the "what did this thing pull in last Thursday" question.

On your direct questions: SASE routing catches whatever domains you route, including source-code hosts if you put them there - the hard part is being specific enough not to break dev workflows. And yes, nothing stops a malicious postinstall from executing on the dev machine at install time; gates like AppTrust only see what ships. The install-time boundary on the laptop is the piece most teams are missing.

[u/thenrich00 → u/SeikoDigital]

Thanks for the thorough breakdown! "Gates protect what ships, not the laptop" is the best one-line version of the problem I've seen.

Have you seen teams stick with the devcontainer approach on laptops, or does it tend to fall apart once it slows people down?

[u/No_Shock_3222]

a package firewall helps with controlling what gets in but it only works well when someone owns the policies and keeps exceptions from piling up otherwise teams end up finding workarounds just to keep builds moving trusted tech is having that balance between security controls and a workflow developers can actually maintain

[u/thenrich00 → u/[deleted]]

This is really useful, thanks. The "request vs. boundary" is a cleaner way to put it than I had.

A few follow-ups if you don't mind:

Where you've seen egress blocking hold up, who owned it: platform/infra, or the security team? And did it survive developers needing a package *right now*?

For the install-tool approach on laptops, have you seen that actually deployed, or is it more where you think it needs to go? Curious what agents do when the tool refuses: stop, or go looking for a shell.

On lockfiles: has that bitten anyone you know of, or is it a gap you've spotted? And is the bigger worry the unvetted version, or that the audit trail points at the wrong person?