I agree, I do see static analysis and runtime sandbox as complementary tools. Do you see static analysis tools performed by the agent itself inside the sandbox or via CI tools in the pull request itself (like github actions or buildkite)?
Nori looks really cool, will set up sometime to exchange notes. But with regards to your questions:
- Proxying keys: We allow users to setup keys in the sandbox and use CLIs for some cases but we also support an egress gateway that intercepts and injects keys on the way out, which supports the major api integrations we offer.
- We still allow fly.io for deployments (so after a sandbox has a final app, you can deploy it and move out of the ephemeral sandbox). We never used them for sandboxing, but we will integrate into https://sprites.dev/ soon.
- For the CLI, we allow you to SSH into the remote sandox since a lot of workload add too much stress to local machines
Curious about what sandbox provider you use to power Nori and how you are handling the secrets/keys issue?
we're on fly, going to add modal support soon. I dont think our users care all that much, but we care for dev ergonomics.
keys are tricky. We don't have a great answer. I mean the proxy inject works well enough for mcp, but there is just such a long tail of tools that do something like 'read a key from disk and encrypt it before sending it out' which makes proxy management just a pain
The sandbox’s lifecycle is independent of the PR so that the same user or someone else in your team, like an engineer can come back to the same session and keep building until the result is ready to merge. So you can choose to iterate on the first drafts on the same sandbox. Curious, what flow you envision in your case?
reply