Hacker News Reader

Comment by ekorondy | Hacker News Reader

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.

View on HN

The broker point is the part I keep coming back to as well. Short-lived credentials help, but an agent can do a lot in five minutes if the scope is still broad, so the interesting boundary is really per-action rather than per-session. A broker that can say this task may read mail but not send it, or may create a draft but not charge a card, feels much closer to how you would delegate to a person. The tradeoff is friction: once every unusual call needs approval, you lose a lot of the hands-off benefit that made the sandbox cheap to run in the first place. I would be curious where people are landing on audit logs here: is a clear record of what the broker allowed after the fact enough for most work, or do you want approval before anything irreversible?

How do you see this fitting with AWS’s Strands Box from last week? Box isn’t hosted compute. It’s an open-source sandbox plus a policy engine that checks shell, Python, egress, and MCP calls, and swaps credential placeholders for real secrets at the gateway. That’s the broker layer ekorondy and talkarimli are asking about.

Two questions: Could a policy layer like Box run inside your gVisor sandboxes, or would it need your full-VM tier? And on price, have you compared against AgentCore Runtime? It bills CPU only while active, which targets the same bursty pattern you’re optimizing for.

This matches what I ended up doing with my own agent setups. The agent never gets a key that can move money out. I fund a separate wallet, the agent gets delegated spending that I can revoke, and withdrawing is just not something it is able to do. Same idea with an API key I use for automation at work: it can edit and reject drafts, but publishing comes back as a 403 and stays a human click. The thing I worried about was never the agent breaking out of a box. It was the agent doing something allowed but dumb with a grant that was too broad.

We’re building Stashbase.dev around this. The agent makes API calls through a proxy that holds the upstream credentials, with access restricted by host, method and path. Revoking the session cuts off further proxy access even if the agent is still running.

The awkward part is deciding how narrow to make those rules. An allowed endpoint can still do something you didn’t want. Are method/path restrictions enough for your use case?

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.

With MCP we let you allow or deny individual tools, so separate draft/send tools work for this. But if it’s one tool with an action argument, we can’t distinguish them today.

Do you think it would make sense to add something like rules for JSON content for plain HTTP requests and argument rules for MCP tool calls?

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.

Hey, we’ve added HTTP body and MCP argument rules now, including value checks and an allow_fields list to reject unknown fields. Your feedback and input from others helped shape this!

Implementation and examples: https://github.com/stashbase/cli/releases/tag/v0.22.0

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.

Feel free to test it out!

> 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.

I am actively working on exactly this. Once its ready, will post here on HN.

Reply on news.ycombinator.com