Everyone's celebrating that Goose from Block is open-source. That's great for transparency, but I think we're looking at it wrong. It's not a gift-wrapped security audit for us to consume—it's an invitation *to become* the auditors. The burden shifts.
Think about it: the extension model is powerful. You can write a `.goose` file that hooks into the runtime. But the "local execution context" they tout means those extensions, if malicious or just buggy, operate with the same permissions as Goose itself. If you're loading a community-built "Google Sheets exporter" extension, you're trusting its code with your data and credentials. The source being available means we *can* read it, but who actually reviews every extension before hitting `goose --install`?
Here's where the supply chain gets real:
* The core `gooseai/goose` repo is one thing. It's got eyes on it.
* But the ecosystem of extensions? That's a wild west. The model means security is now a community responsibility. No centralized vetting by default.
* Credential handling is done via `goose config set`. Those creds are used by extensions. A poorly written extension could log them; a malicious one could exfiltrate. The code being open doesn't prevent that—it just means we might spot it *after* the fact.
So my unpopular opinion: We're not just users. If we're serious about using this tool in any real workflow, we become its pentesters. Every extension is a potential injection point (prompt injection risks between chained tools are a whole other thread 😅). The "audit story" is literally us, forking repos, running `grep` for `os.environ` and `requests.post`, and checking network calls.
Does this make Goose less secure? Not inherently. But it changes the game completely. It's like running a Debian unstable branch—you get the latest, but you're on the hook. Are we, as a community, ready for that level of scrutiny? Or will we just `pip install` and hope for the best?
Curious how others are handling this. Are you auditing extensions you use? Setting up sandboxes? Or is the risk overblown?
You're right, and it highlights why network segmentation is critical for tools like this. That local execution context with high permissions is a major risk.
Running Goose on an isolated management VLAN, with strict egress filtering, would limit the damage a malicious extension can do. It can't exfiltrate creds if it can't phone home. The real challenge is controlling the east-west traffic if it starts probing your internal network.
We've treated our monitoring agents this way for years. Zero trust for your own tools isn't just hype, it's operational necessity.
Isolate everything.
Exactly. That last part about credential handling is what keeps me up at night. I've been tinkering with a wrapper script that intercepts the `goose config set` calls and dumps them into a separate, encrypted store the main process can't directly read. Then extensions have to request credentials via a local socket with a one-time token. It's messy, and breaks auto-update for extensions that expect direct env var access, but it's the only way I feel semi-okay running community stuff.
The real test is whether the core devs adopt a permission model for extensions, something like "this extension requests network access" or "this extension requests file read on the downloads folder." Until then, you're right, we're the pentesters by default. I just wish the auditing tools were better - grepping through a .goose file for `os.getenv` only gets you so far.
Still learning, still breaking things.