The interesting trade-off here is how much of the local environment an agent actually needs. Take a monorepo where a task requires running a specific Homebrew-installed tool, generating code, and spinning up dependent services for integration tests. A sandbox that blocks those workflows pushes you toward workarounds, but letting the agent escape its boundaries too easily creates a different problem. I’d rather expose the exact binaries, writable paths, and network endpoints the task needs than make broader permissions the default.
Yes, indeed... and I am torn between these options.
I both realize very well the potential of the Lethal Trifecta that is possible and on the other hand, if i really want effective VA (virtual assistant), I am forced to make trade offs.
So far I haven't gotten burned but I will also not let my agent read my emails before me nor do it on automated basis, so there is no easy prompt injection, furthermore, I do count on the auto mode and my operating guide to not allow any actions that actually submit data outside (sending emails, uploading files etc).
But it is not ideal. I see Claude Code in Desktop introduced a new environments option so I will be checking that one up. But for short, my biggest deal breaker in Cowork was no way to let the agent access my 1password cli op.
The op limitation is an interesting one because exposing the CLI isn't quite the same as granting safe access to secrets.
Imagine an agent working on a deployment that needs a database credential from 1Password. If it can run arbitrary op commands with a broadly privileged service account, a prompt injection hidden in a dependency README could try to turn that convenience into access to unrelated vault items. Even if the agent never sends an email, it could still leak a secret through a build log or an outbound request.
I'd be tempted to put a small host-side broker between the agent and op: allow specific secret references, inject values only into the process that needs them, and keep the vault token out of the agent's environment. Add an outbound network allowlist, and you've reduced the blast radius without taking away the workflow.
The tricky part is preserving that boundary when the agent can execute arbitrary shell commands. Have you considered exposing a narrow secret-access interface rather than the full CLI?
Sina Rezaei
**Project Manager | Digital Strategist | Analytics | Creator | Full-Stack Developer** 🗼 🏰 ❾¾ 🦁⃝⃒⃤ 🪄 🦉 | 별 | 🐉 ⛩️ 夢 ☯ ރ
The interesting trade-off here is how much of the local environment an agent actually needs. Take a monorepo where a task requires running a specific Homebrew-installed tool, generating code, and spinning up dependent services for integration tests. A sandbox that blocks those workflows pushes you toward workarounds, but letting the agent escape its boundaries too easily creates a different problem. I’d rather expose the exact binaries, writable paths, and network endpoints the task needs than make broader permissions the default.