Hacker News: radim_h

New comment by radim_h in "Launch HN: Agent37 (YC F26) – Low-cost agent sandboxes for running agents"

radim_h — Mon, 19 Oct 2026 15:15:45 +0000

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/pull/79

New comment by radim_h in "Emu Concept – Make AI Follows Your Rules. (Feedback Wanted)"

radim_h — Sun, 18 Oct 2026 06:33:05 +0000

How would Emu enforce a denial when the other agent runs in the cloud?

We are building https://stashbase.dev for coding agents, and that’s been the tricky part: a rule needs a place where access can actually be blocked. With local processes you can restrict filesystem and network access; with external services you need control over the credentials or even request path.

Also I think that most "hard" agent permissions and rules should be enforce outside of the model because if the agent is "self-learning" there's a chance it can learn to do something that should not be done. This is a direction we are taking, permission profiles and access that wrap the agents.

New comment by radim_h in "Show HN: rStation – A shared research lab for your AI agents"

radim_h — Fri, 16 Oct 2026 17:13:14 +0000

We’re building Stashbase for this (repo: https://github.com/stashbase) You can run your coding agent in Docker-based sandbox with explicit workspace mounts and outbound network rules. It supports your own Dockerfile or image too, so you can keep whatever research tools and dependencies you need (default Dockerfile installs Claude Code and Codex). The access rules live in a TOML profile.

New comment by radim_h in "Launch HN: Agent37 (YC F26) – Low-cost agent sandboxes for running agents"

radim_h — Fri, 16 Oct 2026 14:32:27 +0000

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?

New comment by radim_h in "Launch HN: Agent37 (YC F26) – Low-cost agent sandboxes for running agents"

radim_h — Thu, 15 Oct 2026 08:16:44 +0000

We’ve taken the outside-broker approach in Stashbase.dev too. You manage the actual secrets in Stashbase and the proxy adds them to permitted requests. The agent gets a revocable session with host/method/path rules rather than the upstream key.

Still leaves the problem of an allowed request being a bad idea. Giving an agent access to a send-mail endpoint is a fairly big grant, even if it never sees the token. Which Google operations would you actually want to give it?

New comment by radim_h in "Launch HN: Agent37 (YC F26) – Low-cost agent sandboxes for running agents"

radim_h — Thu, 15 Oct 2026 08:15:57 +0000

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?