ekorondy

Nice, that was fast. Failing closed when the body isn't readable JSON is the part I'd have worried about most, and you covered it. Naming the field but not the value in the 403 is a good call too. The agent learns what to fix without the log leaking a recipient or an amount.

One thing I'd be curious about over time is GraphQL, since one endpoint can do everything. An exact-query allowlist is the safe default, but it'll get painful fast on big APIs. Thanks for following up.

Yes, I think that's the right next layer. On a lot of real APIs the risky part lives in the body, not the path. A messaging API where the same call drafts or sends. A payment call with a capture flag. A bulk update whose filter happens to match every record.

Two things I'd watch. First, default-deny on fields the rule doesn't know about, so a new argument can't slip through. Second, let rules check values, not just whether a field is present. Amount over a limit, recipient outside an allowlist, an empty filter. That's where most of the "in policy but still wrong" actions live.

For MCP I'd also let the tool author tag each action as read, write, or irreversible, and treat anything untagged as irreversible. Then argument rules are the override, not the only line of defense.

Method and path help, but they are not enough on their own.

The same POST /messages can mean "save a draft" or "send to the customer." The same invoice endpoint can list or charge. Host and method filters stop random hosts. They do not encode intent.

What I want on top is an effect class per call: read vs write vs irreversible. Irreversible stays human-gated or hits a hard deny. Everything else can keep a budget and an audit trail. Revoking the proxy session is good. Stopping a bad action that was still in policy is better.

The host isolation everyone is comparing on price is not the hard problem.

gVisor vs a full VM is a real tradeoff. Most agent failures that actually hurt are not sandbox escapes. They are the agent acting as you with a coarse OAuth grant, or reading a secret that was sitting in the environment. A cheaper box does not fix that.

You still need an egress allowlist the guest cannot rewrite, credentials that never enter the guest, and a hard call budget per task. I would pay more for that broker layer than for another 2x cheaper sandbox.

The uncomfortable part is that "easy to turn on" and "enough for the threat" get sold as the same thing.

Self-sandbox APIs like this are real progress for trusted apps. You declare the paths and ports you need, call enable, and the process sheds everything else. For a static file server that is a clean win, even when the container is already locked down. Defense in depth should be cheap.

It is a different story for agent runtimes. An agent that can write code, install packages, and talk to the network is closer to "untrusted code with a goal" than "my service with a bug." Landlock and Seatbelt reduce filesystem blast radius. They do not give you a separate kernel, a clean network policy, or a place to kill the session when it starts escalating around a deny.

What I want from a sandbox API next is not more sugar on unveil. It is an honest matrix: which threats this layer stops, which ones it only slows, and which ones still need a microVM or a disposable host. Ease of use matters. So does not letting people confuse a good default with a security boundary.