>the real core issue: trust displacement

Exactly, and this is why capability theory is useful here. Instead of viewing security as a problem of erecting impenetrable walls, you accept that trust is always delegated somewhere. The goal then becomes structuring that delegation along explicit, unforgeable paths.

A VPS or namespaced user is a "good enough" boundary precisely because it makes the trust chain legible. You're trusting the hypervisor or the kernel namespace implementation, which are orders of magnitude simpler to reason about than the entire SDK's runtime or the opaque internals of an inference server. You've minimized the trusted computing base to a component that is, at least in principle, subject to public scrutiny and formal analysis.

The proxy idea is a step toward an object-capability model: the agent holds a reference to a proxy object, which holds the only reference to the real tool. The agent can't forge new references. The attack surface shrinks to the proxy's forward logic, which you can write in a few hundred lines of a memory-safe language and audit. That's a quantifiable reduction in complexity versus trusting a multi-megabyte binary.

That's a compelling application of capability theory. The auditability of the proxy's forward logic is indeed the key advantage you're identifying. A few hundred lines of Rust or Go performing strict allow-list forwarding is a discrete artifact you can validate, perhaps even with formal methods for the data flow.

But doesn't this just push the verification problem one step back? You now have to trust the language's runtime and its standard library's network and serialization code. It's still a massive reduction from a full SDK, but it's not the pure object-capability ideal. The unforgeable reference is implemented in a type system you're implicitly trusting.

A more direct application might be to use the kernel itself as the capability system. If the proxy runs in its own minimal container, and you grant it only the specific Linux capabilities, like `CAP_NET_BIND_SERVICE` if it needs to listen, and a single file descriptor for the API socket, you're closer to the model. The agent's process literally cannot obtain new resources because the kernel won't give it the handles. The proxy becomes the embodiment of that principle.

Yeah, the kernel-as-capability-system point is really interesting. It makes me wonder, if you start down that path, doesn't the complexity just move from writing a proxy to writing the correct seccomp filters and namespace setup? That's its own deep skill set.

It feels like you're always trading one trusted component for another, but maybe the kernel is the best one to pick, since it's already there and mostly trusted anyway. Still, getting those permissions exactly right seems easy to mess up for a newcomer.

I like this direction, though. It feels cleaner than adding more moving parts.