Hi everyone. I've been reading the discussions here about using microVMs like Firecracker for isolating agents, and the focus often seems to be on launching the VM itself. I'm trying to understand the next step: what do we actually do *inside* the guest to harden it?

The guest kernel in a Firecracker microVM is typically a stripped-down Linux kernel, but it still has a lot of functionality by default. My thinking is that if the agent is compromised, the attacker's first goal will be to break out of this VM layer. So, the guest's attack surface matters.

I have a few specific questions I'm hoping someone with experience can verify:

1. **Kernel modules:** Is the best practice to compile a completely monolithic kernel with only the absolute essentials (virtio drivers, maybe a console), and disable module loading entirely? Or is there a secure way to keep modules if you need flexibility?
2. **Syscall reduction:** gVisor's whole model is intercepting syscalls. For a pure microVM, are there concrete guides on disabling syscalls at the kernel config level (e.g., disabling `ioctl` for devices not present) that go beyond just using a minimal config?
3. **Namespacing inside the guest:** This feels like putting containers inside a VM, but does it add a meaningful security layer? If the agent runs as a non-root user inside a user namespace within the guest, does that significantly raise the bar for a guest kernel exploit?

I'm not looking for theoretical "yes, harden it" answers, but rather for walkthroughs or specific configuration snippets that people have used in production or serious testing. What are the actual kernel config options or boot parameters you set?

Also, what's the real performance impact of some of these measures, like a highly restricted syscall table? I assume it's negligible for an agent workload, but has anyone measured it?