samkim

Ultimately a prompt injection attack is trying to get the agent to do something it wasn't intended to do and if you have the appropriate sandboxing and authorization in place, a compromised agent won't be able to actually execute the exploits

Agreed, sandboxing is only part of agent security. Authorization (what data the agent can access and what tools it can execute) is also a big part of it.

I've found primer on agent sandboxes [0] is a great reference on sandboxing options and the trade-offs

For agents there's a tension between level of restriction and utility. I think a large part of OpenClaw's popularity is that the lack of restriction by default has helped people see the potential utility of agents. But any agent that isn't just for trying things out requires consideration of what it should and should not be able to do and from there the decision around the best combination of sandboxing and authorization.

At work, we've found it helpful to distinguish coding agents vs product agents. Coding agents have the ability to add new execution paths by pulling in external code or writing their own code to run. Product agents have a strictly defined set of tools and the runtime prevents them from executing anything beyond that definition. This distinction helps us reason about what sandboxing is required.

For data permissions it's trickier. MCP uses OAuth for authentication but each server can have different expectations for access to the external service. Some servers let you use a service account where you can narrow the scope of access but others assume a token minted from an admin account which means the MCP server might have access to things beyond what the agent using the server should.

So for that, we have an MCP proxy that lets us define custom permissions for every tool and resource, and at runtime makes permission checks to ensure the agent only gets access to the subset of things we define ahead of time. (We're using SpiceDB to implement the authorization logic and checks) This works well for product agents because they can't add new execution paths. For coding agents, we've tinkered with plugins/skills to try to do the same but ultimately they can build their way around authorization layers that aren't part of the runtime system so it's something we're still trying to figure out.

---

[0] https://www.luiscardoso.dev/blog/sandboxes-for-ai

One of the discussions we had in our slack was that the introduction of the New Enemy Problem on page 21 may be oversimplified. It currently relies on an unwritten assumption that the contents of the room change between days or that the previously granted permission was revoked. However, we figured setting the scenario and leaving a note that grownups could easily google for more info would be an ok tradeoff.

Here's a Dibs sculpture in real life: https://photos.app.goo.gl/JgqEa5Go7t7m3wAB9

My team happened to win one of the hackathon prizes and can confirm they turned out really well.

Hi! I'm one of the contributors to the project and this was an idea that bounced around during development. Can you create an issue in the repo and add any details you have in mind for how this would work?

https://github.com/authzed/zanzibar-annotated/issues

I've recently gone through the process of getting our stack, which includes python, go, and docker, running on an M1. Docker for Mac only recently released M1 support but it runs well enough. We upgraded to Python 3.9 to incorporate some M1 compatibility updates as well.

Overall, developing on the M1 Macbook Pro has been great so far.

Went through the same process except with an M1 Macbook Pro. My coworkers volunteered me to see if we could get our dev stack building and running on ARM with hopes they could eventually dump their older x86 Macbook Pros, which run loud and hot.

It was a bit of a process but once we got it working, developing on the M1 has been great. Captured notes on the process here in case it's helpful for anyone later: https://authzed.com/blog/onboarding-with-an-m1/

Since you mentioned Google docs style sharing, does Sharewith support abilities for different users eg viewer vs commenter vs editor?