This is the right framing: secrets access is an execution capability, not an ambient convenience. The strongest version makes the policy visible before launch—what paths are denied, what credentials are available, and how an exception is approved—so the agent and operator can reason about the boundary before an incident.
Agreed. Right now xyno-sandbox only does the enforcement part: denied paths, stripped env vars, and it won't start if the sandbox fails. Showing that policy before launch, and a logged way to approve exceptions, is the missing half. I'll open an issue for it. Thanks!
Analyst focused on AI security
Adversarial evaluation of local LLMs, censorship and rejection rate, prompt injection testing, log analysis and defensive automation. Visit: sammideblas.com
Failing closed is the right default and the README that admits the limits is more trustworthy than a claim of containment. The next step for local agents is closing the network too, a read-only filesystem still lets an agent exfiltrate through an allowed egress path.
Thank you for your appreciation!
Hmm... That's pretty interesting, actually. A read-only filesystem doesn’t stop exfiltration over an open network, and the network is still open today. Closing it, or restricting it to an allowlist, is the next layer, and it’s going in the issue. Thanks!
Building AI systems and fixing AI-generated apps before they collapse in production.
Working with agentic AI, RAG pipelines, AI orchestration, and startup MVP scaling at IT Path Solutions.
The fail-closed approach is the part I appreciate most here. A sandbox that silently falls back to unrestricted execution can create a false sense of security, especially when agents inherit the developer's privileges. One additional layer worth considering is restricting network access or routing it through an explicit allowlist, since filesystem isolation alone doesn't prevent an agent from sending accessible project data elsewhere. The README's clarity about the limitations is equally important: developers need to understand exactly which risks the sandbox reduces and which ones remain. Great example of treating agent execution as a security boundary rather than just another editor feature.
Thanks! You’re right that filesystem isolation alone doesn’t stop data leaving over the network. The network is still open today, and the README says so. An allowlist is the obvious next layer, so I’ll add it to the issue.
Analyst focused on AI security
Adversarial evaluation of local LLMs, censorship and rejection rate, prompt injection testing, log analysis and defensive automation. Visit: sammideblas.com
Analyst focused on AI security
Adversarial evaluation of local LLMs, censorship and rejection rate, prompt injection testing, log analysis and defensive automation. Visit: sammideblas.com
A technologist working in automation. Here I write up what I actually learn building tools, engineering AI agents, and keeping systems running, along with the workflows and habits that stick.
Running the agent under a dedicated user or subuid with an empty home directory is the cleanest seatbelt I've found on Linux. The moment an agent has read access to your actual home directory, path blacklists always leak through temp files, shell history, or subshells. Swapping out ~/.ssh and ~/.aws with empty mounts inside bubblewrap is a solid middle ground when you can't run a full separate user.
Agreed, a dedicated user with an empty home is cleaner. Blacklists leak, and I say so in the README. The empty mounts are the middle ground for when you can’t set up a separate user. Have you found a way to make the dedicated user easy to launch from the editor?
Analyst focused on AI security
Adversarial evaluation of local LLMs, censorship and rejection rate, prompt injection testing, log analysis and defensive automation. Visit: sammideblas.com
Analyst focused on AI security
Adversarial evaluation of local LLMs, censorship and rejection rate, prompt injection testing, log analysis and defensive automation. Visit: sammideblas.com
Analyst focused on AI security
Adversarial evaluation of local LLMs, censorship and rejection rate, prompt injection testing, log analysis and defensive automation. Visit: sammideblas.com
I wrote this because I asked myself what stops an agent from reading my ~/.ssh, and the answer was nothing. How do you handle coding agents with access to your home directory?
We're a place where coders share, stay up-to-date and grow their careers.
This is the right framing: secrets access is an execution capability, not an ambient convenience. The strongest version makes the policy visible before launch—what paths are denied, what credentials are available, and how an exception is approved—so the agent and operator can reason about the boundary before an incident.
Agreed. Right now xyno-sandbox only does the enforcement part: denied paths, stripped env vars, and it won't start if the sandbox fails. Showing that policy before launch, and a logged way to approve exceptions, is the missing half. I'll open an issue for it. Thanks!
Failing closed is the right default and the README that admits the limits is more trustworthy than a claim of containment. The next step for local agents is closing the network too, a read-only filesystem still lets an agent exfiltrate through an allowed egress path.
Thank you for your appreciation!
Hmm... That's pretty interesting, actually. A read-only filesystem doesn’t stop exfiltration over an open network, and the network is still open today. Closing it, or restricting it to an allowlist, is the next layer, and it’s going in the issue. Thanks!
The fail-closed approach is the part I appreciate most here. A sandbox that silently falls back to unrestricted execution can create a false sense of security, especially when agents inherit the developer's privileges. One additional layer worth considering is restricting network access or routing it through an explicit allowlist, since filesystem isolation alone doesn't prevent an agent from sending accessible project data elsewhere. The README's clarity about the limitations is equally important: developers need to understand exactly which risks the sandbox reduces and which ones remain. Great example of treating agent execution as a security boundary rather than just another editor feature.
Thanks! You’re right that filesystem isolation alone doesn’t stop data leaving over the network. The network is still open today, and the README says so. An allowlist is the obvious next layer, so I’ll add it to the issue.
Yes. A read-only filesystem stops local writes, not traffic. An egress allowlist is the layer that closes it.
Exactly. Never too cautious, when talking about AI and permissions.
Agreed. Default deny plus a short allow list is the boring fix that works most of the time.
Running the agent under a dedicated user or subuid with an empty home directory is the cleanest seatbelt I've found on Linux. The moment an agent has read access to your actual home directory, path blacklists always leak through temp files, shell history, or subshells. Swapping out ~/.ssh and ~/.aws with empty mounts inside bubblewrap is a solid middle ground when you can't run a full separate user.
Agreed, a dedicated user with an empty home is cleaner. Blacklists leak, and I say so in the README. The empty mounts are the middle ground for when you can’t set up a separate user. Have you found a way to make the dedicated user easy to launch from the editor?
Right. Read-only stops writes, not traffic. The next layer is an egress allowlist, and that one is harder to get right.
Read-only root and a network allowlist are the pair that limits damage. One alone leaks.
This is one of the cases where real control is needed, even though we "trust" the agents up to some limits.
Trust is not a control. The question is what the agent can reach when it is wrong, not what it means to do.
I wrote this because I asked myself what stops an agent from reading my ~/.ssh, and the answer was nothing. How do you handle coding agents with access to your home directory?