Hey, welcome and thanks for posting. You've hit on the exact set of concerns that any security team worth their salt should have, and honestly, it's a good sign they're asking. Moving from scattered scripts to a centralized platform like Goose is a net win, but it does change the security model. Let me tackle your points in order.

> The local execution context.
This is key. When an extension calls `goose.shell.exec()`, it runs in a subprocess *as the user running the Goose agent*. There's no magic isolation beyond what the OS provides. If your agent runs as a service account with broad privileges, that's your new risk boundary. The sandbox is more about preventing the JavaScript from crashing the main Goose process than about OS-level containment. You need to lock down that service account's permissions like you would for any other automation runner.

> Credential handling in extensions.
Don't bake them into the extension code or manifest. Goose has a secrets store, but it's often overlooked. You can define required secrets in your manifest under `capabilities.requiredSecrets`, and then the values get injected at runtime from the agent's secured store. For internal extensions, this is the way. It keeps creds out of the code and lets you rotate them centrally. For your old config file, you'd migrate those secrets into the agent's store and reference them by key.

> The open-source supply chain.
Big one. The public registry is great, but you can't treat it like npm. Vetting is manual work, but you can set some ground rules. First, run the agent with a policy that *only allows extensions from your internal registry*. Then, you can selectively mirror and vet public extensions. When you vet one, pull the source, audit the manifest for requested permissions (especially `shell` or `network`), look at the actual code. It's like approving any other third-party library. Some teams only allow extensions where they control 100% of the code for this reason.

Your appsec team is right to be concerned, but you can turn this into a collaborative win. Frame it as, "We moved from an unmanaged scripting free-for-all to a platform where we can actually enforce policies and audit usage." They'll probably like that angle.

Got any details on how your agent is currently deployed? That changes a lot of the advice.

Excellent initial move centralizing those scripts. That alone reduces your attack surface from a dozen inconsistent entry points to one auditable platform. Let's address your three points directly, as they're the right concerns.

For credential handling, the config file model was actually more secure by default if it used filesystem ACLs. In Goose, credentials often end up in the extension's JavaScript context as plaintext variables or within `localStorage`. You must assume any installed extension can read them. The correct pattern is to use Goose's built-in secret storage, if your version has it, or to keep credentials entirely outside the extension, delivered via a secure API call at runtime. Many public extensions don't do this, so you'll have to modify them.

Regarding the public registry, you cannot vet a JavaScript extension by simply reading the source in the registry. The delivered package is often minified, and the build process can pull in dependencies not visible in the repository. You need a pipeline that downloads, deobfuscates, and audits the actual code bundle you're installing. Otherwise, you're trusting a third-party CDN. For internal use, I'd mandate a policy of only running extensions where you control the full build from source, even if that source was originally forked from the public registry.

Welcome! Honestly, it's great you're thinking about this before the security review gets difficult. Your move probably already improved your overall posture, but you've swapped one set of risks for another.

For vetting public extensions, start by checking the manifest for permission requests. A data-fetching extension shouldn't ask for 'shell.exec'. Then look at the source, if available, for obvious red flags like hardcoded credentials or calls to external domains you don't recognize. I'd suggest creating a simple internal policy: any extension from the public registry must go through a quick code review by someone on your team before it's deployed, even if it's just a visual scan. It's a good middle ground before you lock things down to internal-only.

Your appsec team will likely appreciate that you've started this process. Maybe ask them what their extension review checklist looks like?

Hey, I was in a similar spot a few months ago! The move to Goose felt so much cleaner, but you're right, the security model is totally different.

> How isolated is it really when a Goose extension runs a shell command?
Not much at all, from what I've read. The other replies nailed it - it's just a subprocess. I got tripped up thinking the "sandbox" was a container. It's not. It's for the JS runtime, not the OS. So yeah, that service account is everything now.

A follow-up question for the more experienced folks here: if the agent's service account is locked down, is the biggest risk then a malicious extension using its allowed perms to, say, exfiltrate data from the internal APIs it already has access to?

You're absolutely right about the registry source being a red herring. The minified bundle is the real artifact, and that's where SBOM generation becomes critical. Tools like Syft or Trivy can at least list the npm dependencies in that bundle, giving you a software bill of materials to check against known vulnerabilities. It's not perfect, but it moves you from "blind trust" to "informed risk."

We enforce a policy where the actual `.goose` package file pulled from the registry gets scanned and its SBOM diffed against the public git repo's `package.json`. Any mismatch fails the install.