Hey folks, been tinkering with Goose on my old NUC homelab cluster and it's been a fun agent runtime. Its open-source nature is a huge plus for our crowd. But I was reading the docs on the extension model and a thought crossed my mind.
An extension runs locally, in its own context, but it's granted certain permissions by the user. The scary part? If you install a malicious extension, or a trusted one gets compromised, it could potentially go after files way outside its supposed scope.
So, how could a bad extension actually steal SSH keys? It's simpler than you might think.
* The extension asks for (or already has) a broad file system permission, like `read_home_dir`. You might grant this to a utility that organizes your projects.
* Keys are often in predictable places: `~/.ssh/id_rsa`, `~/.ssh/id_ed25519`.
* The malicious code, once run, can just read those files directly.
* It could then exfiltrate them by making a hidden network call to a server the attacker controls, or even stash them in a seemingly innocent log file that gets synced elsewhere.
The local execution context isn't a sandbox in the traditional sense—it's more about permissions you grant. Goose's security relies heavily on you vetting extensions and on the maintainers keeping the supply chain clean. Since it's open-source, we *can* audit extensions, but how many of us actually read every line of code before installing?
Just something to keep in mind, especially if you're running Goose on a machine that also manages your servers via SSH. I stick to a heavily segmented network and run my Goose instance on a separate VLAN for this exact reason.
You've hit on the critical part: permissions. That `read_home_dir` scope is the core of it. It's exactly why we recommend treating extension permissions like sudo - you wouldn't grant a script global read access unless you absolutely trusted its author and its code.
One nuance people miss is the exfiltration path. It doesn't have to be a noisy network call. A malicious extension could encode the key data and embed it in a regular-looking POST request to its own backend API, masked as routine telemetry or a version check. The logs would show an outbound connection to the extension's domain, which you'd likely have already permitted.
Your point about "trusted one gets compromised" is the real sleeper threat. Everyone audits at install, but how many re-audit after updates? An extension with a broad permission set only needs one malicious commit to become a trojan. That's why I only ever install extensions where I can reasonably follow the commit history.
stay frosty
Good, you've outlined the basic attack vector. But you're stopping short at the filesystem permission. The real failure is that the local execution context has no meaningful isolation layer.
You mention it's not a traditional sandbox. That's the problem. Without a proper namespace jail or a tight seccomp filter, an extension with `read_home_dir` can also `stat` your entire home directory, scan for config files with other secrets, and even attempt to read your bash history to find other paths. The permission is just an API gate, not a boundary.
Goose needs a mandatory system like AppArmor profiles per extension, denying access to `/proc/*/mem` and blocking arbitrary network calls even if the permission model says they're allowed. The current model is just discretionary access control, and we know how that ends.
capability check