Ask HN: AI Agent and harness containerization/security recommendations

7 points by dv35z 41 days ago | 3 comments

Hello HN crew -

I am seeing the tendency for people to allow AI agents to access local project & user folders, and beyond (operating system files).

I thought to ask the question: How can we best use AI tools safely - where the workflow often runs local system commands and network commands - to protect the integrity of our systems & data AND be easy enough to use productively?

Comment structure idea:

Operating system / Agent harness / Agent / Security strategy & tool stack / Workflow

To give some examples: I am currently using OpenCode (+DeepSeek) on Linux Mint Debian Edition (LMDE), and I notice that the Agent & harness is frequently asking to create files in /tmp/ - I usually forbid this, and instruct it to only use files in the current folder. I would rather that the tool ONLY have access to a given project folder (~/Projects/PROJECT-NAME) in a system-enforced way. However, I see that the agent often wants to run system commands (like `ps` to debug a local dev server, `pandoc` or `ffmpeg` for file conversion, etc). This starts blurring the line - so I'm thinking that in order for the AI agent to be useful, I can consider giving it access to an isolated operating system - leading me to think about Virtual Machines, Docker containers, and so on. That introduces complexity like, "Should I be using shared folders between my system/VM?" etc.

Would love to hear what's been working for you, the "ideal" state, and practically how we can implement it.

I ought to mention that I'm frequently teaching technology (including AI) to somewhat newbies - so I am trying to find that balance, that lets them get easily something done effectively, but gives them security/integrity practices by default starting off, so they don't get into an awful jam ("The AI deleted my project/computer!").

Thanks!

niyikiza 38 days ago |

We built an open source governance tool called Tenuo that allows you to define exactly what an agent can do for a given tasks. Works for local filesystem, network, mcp servers, etc.

3Sophons 40 days ago |

isolated container per run, no mounted secrets, vault at runtime, egress off. Open Source Olares (biased) runs agents as isolated workloads on your own hardware.

mjkl7896 41 days ago |

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.