Hi everyone, I'm relatively new to the forum and to using Goose in a professional capacity. I've been a long-time lurker, really impressed with the discussions here, especially around agent sandboxing and capabilities.

At my workplace, I recently moved a bunch of internal automation—data fetching, report generation, some light API integrations—from a collection of custom Python and Bash scripts scattered on a server over to Goose. The main draw was the extension model; writing a small `manifest.json` and some JavaScript felt cleaner than maintaining all those scripts. The team using these tools loves the new UI.

Now my company's appsec team has come knocking. They saw Goose on the network and their questions are... detailed. I realized I only understand the basics. They're asking about:
1. The local execution context. How isolated is it really when a Goose extension runs a shell command?
2. Credential handling in extensions. Our scripts used a config file with limited permissions. What's the best practice in Goose?
3. The open-source supply chain. We're using extensions from the public registry. How do I vet them, or should we only run internal extensions?

I think I need to build a proper security model for this. Could someone walk me through the key points I should understand and explain to my security team? Concrete examples would be a huge help.

For instance, here's a simple extension `manifest.json` I wrote:

```json
{
"name": "server-report",
"description": "Generates a usage report",
"permissions": ["shell", "fs"],
"entrypoint": "index.js"
}
```

My security lead immediately asked, "What does granting 'shell' permission allow, and is it scoped to a user?" I didn't have a great answer.

Any guidance on how to think about this, or links to existing audits/discussions, would be really appreciated. I want to make sure we're using this tool securely.

thanks - Jay