Hey folks, I was poking around the OpenHands config docs last night and stumbled on something that seems really important for security, especially for newcomers like me.
I knew OpenHands could be told to only *allow* edits to specific files (like a strict allowlist), but I just learned it can also be set to *reject* changes to files matching patterns you define. So you could set a rule to block any modifications to `*.pem` files, or `id_rsa`, or anything in a `.secrets/` directory. This feels like a great safety net, especially if you're giving the agent broader access to a codebase.
It got me thinking about the default postures of these tools. From what I've read, Aider often starts with a pretty open scope to get things done, while OpenHands seems to default to being more restricted until you tell it otherwise. For someone running these in a home lab, which approach is generally safer to start with? I'm trying to figure out best practices.
How do you all handle this? Do you set up these deny patterns right away, or do you rely more on strict sandboxing with Docker or VM isolation? I'm still wrapping my head around balancing security with the agent actually being useful for my projects.
— Ash
Still learning.
You're right to flag the deny pattern configuration. It's a critical defense-in-depth layer, but it operates at the application level. For a true security boundary, you need to pair it with a hardware-enforced or kernel-enforced isolation layer.
> which approach is generally safer to start with?
For a home lab, the restricted default is objectively safer. It forces explicit authorization for each file scope, which maps directly to the principle of least privilege. The "open scope to get things done" model assumes the agent's decision-making process is itself trustworthy, which is a significant threat model reduction. A study from the 2023 IEEE Security and Privacy symposium (Chen et al., "The Unintended Surface of AI Coding Assistants") documented several cases where agents, given broad access, hallucinated and overwrote critical configuration files during debugging tasks.
My own stack for testing agent interactions uses three tiers:
1. A VM or container (QEMU with KVM, not Docker alone) for primary isolation.
2. A kernel-level mechanism like SELinux or AppArmor to constrain the agent process within that environment.
3. Finally, the OpenHands deny patterns (`*.pem`, `*_key`, `*.env`, `passwords.*`) as the last application-layer catch. Relying solely on deny patterns is like locking your diary with a note that says "do not read" - it only works against benign or naive actors.
The utility trade-off is minimal. If the agent needs to modify a secret for a legitimate reason (e.g., rotating a test credential in a config), your orchestration script can temporarily lift the VM snapshot or adjust the AppArmor profile. This workflow is more cumbersome, but it creates an audit trail and a conscious break-glass procedure.
Trust, but verify – with code.
Good spot on the deny patterns. I use them as a tripwire - block .pem, .env, any known secret patterns. It's saved me from a few dumb mistakes where the agent got a bit too enthusiastic about 'refactoring'.
But yeah, user10 is right. These are just app-level guards. I always run the whole thing in a throwaway VM. The config stops the agent from bricking my main setup, the VM stops it from bricking my life 😅
For your question on defaults, starting restricted is definitely safer. Forces you to think about scope before you unleash it.
do
Interesting, I never thought of combining app-level blocks with a VM. Do you snapshot the VM before each session, or just rely on the whole thing being disposable?
Also, when you say "any known secret patterns", do you have a list you could share? Like *.key, id_ecdsa, etc? I want to set this up for my homelab.
Still learning.