Okay, I have to ask because I’m genuinely curious after spending the last two weeks instrumenting and stress-testing a dozen different Goose extensions. Am I the only one who treats every single extension—even the ones from the official repo—as inherently untrusted and runs them in a sandbox by default?

I get that Goose’s whole value proposition is its powerful extension model and local execution context. That local context is fantastic for performance and for keeping sensitive data off the wire, but it also means that a malicious or buggy extension has direct access to my filesystem, network, and credentials if I’m not careful. The open-source nature helps with audits, but let’s be real—how many of us have the bandwidth to do a full code review on every extension we pull from the community registry or even a fork of a core one? The supply chain risk is non-zero.

Here’s my standard deployment playbook now. Every extension gets its own isolated environment. I’m using a combination of `gVisor` for the stricter sandboxing and plain old Linux namespaces for the lighter-weight ones. The key is profiling the resource caps and expected syscalls first.

I’ve been logging everything into Prometheus to baseline “normal” behavior. For example, here’s a snippet of the security-focused metrics I tag each sandboxed extension with:

```yaml
# extension_sandbox_monitor.yml
metrics:
- name: extension_syscall_count
labels: ['extension_name', 'syscall_type']
description: "Count of syscalls by type, spikes can indicate anomalous behavior"
- name: sandbox_network_egress_bytes
labels: ['extension_name', 'destination_ip']
description: "Track any unexpected network calls from the local context"
- name: filesystem_access_outside_workspace
labels: ['extension_name', 'path_attempted']
description: "Alert on attempts to read/write outside the allocated temp directory"
```

The performance hit is measurable but, in my view, absolutely worth the trade-off. For a data-fetching extension, the sandbox (gVisor) adds about 15-20ms of overhead per execution compared to native. For a compute-heavy transformation extension, the overhead is more like 5-8% CPU penalty due to the syscall interception. I have the detailed benchmarks if anyone is interested.

My question to the room: is this level of paranoia the new normal for those of us deploying Goose in production with multiple extensions? Or are you relying more on the reputation of the source and the fact it’s open source? Have you found a lighter-weight sandboxing method that doesn’t kill performance for high-throughput agents?

I’m particularly interested in how you handle credential passing to sandboxed extensions. I’ve been using short-lived, scoped tokens passed via environment variables that the sandbox can’t persist, but I’m sure there are other patterns.

- Aisha