You'd do that with a container and a layer 7 egress proxy rule e.g. mitmproxy.

Sure it's work to build such things, but building restraints into the app feels more reliable than playing whack-a-mole with scanner results.

Operating systems can probably do better to meet this need (e.g. capability based ones like fuchsia) but even as is their rules just feel so much more binding.

The scanner is just one part of the codebase, good for maintaining quality in a pipeline.

There is also @makerchecker/embedded, which has runtime permission primitives you wrap around the agent's actions, so the restraints live in the app exactly like you're describing

Less whack-a-mole, more wrap the risky calls and they're bound

Any LSM can stop that POST. SELinux, AppArmor, Tomoyo, etc. They are built-in to the kernel. You just need to know what you are doing to use them.

Yes, but they operate at the OS boundary, but we are defining application/business logic

OS controls answer "can this process make network requests?"

App-level policies answer "is this request, with these parameters, acceptable?"

Is that a real boundary? I mean if an application asks the kernel to enforce a rule, the kernel enforces that rule, regardless of whether it counts as business logic or not. Why have two languages for defining such things if they're not actually distinct?

I'll admit that OS interfaces could stand to improve in their ability to do so, there's a lot of stuff in plan9 and fuchsia that I'd love to see in widespread use, but despite that I still think the quickest route to sanity is improving existing tools that constrain arbitrary processes, not replacing them with tools that specifically constrain agents.