| I don't think there is a single ideal setup yet, but the direction seems fairly clear: treat the agent as an untrusted process and give it explicit capabilities rather than unrestricted shell access. I ran into a similar problem while building a text-to-SQL agent. The useful controls were: - a read-only database role
- access only to selected views
- predefined queries where possible
- validation and limits before executing generated queries
- logging every query and result I think the same pattern applies to local coding agents: - run the agent as a separate OS user or inside a container/VM
- mount only the project directory, preferably read-only by default
- deny network access by default and allowlist required destinations
- wrap commands as typed tools with explicit permission checks
- require confirmation for package installation, credential access, destructive commands, or writes outside the workspace
- keep secrets behind a separate broker rather than exposing them directly to the agent A container alone is not much of a boundary if the agent can access the home directory, Docker socket, SSH keys, or broad network credentials. The important boundary is the set of capabilities exposed to it. For teaching beginners, perhaps the practical answer is to provide security profiles such as "safe", "project trusted", and "unrestricted", with the safest profile as the default. |