How are teams enforcing tool permissions across an org?

[Thepluscode]

The allowlist controls which extensions can be installed, and tool permissions (Always Allow / Ask Before / Never Allow) control how each tool is used. For teams running goose across many engineers: are tool permission levels enforced centrally, or set per user? And for extensions that hold credentials (GitHub, cloud, databases), what identity do they act as — the engineer's own token, a shared service account, or something scoped per session? Interested in what's worked in practice and where it's still awkward.

[CedricConday]

Per user, in the current code. Tool permission levels are written to permission.yaml in the user's config directory (crates/goose/src/config/permission.rs, PERMISSION_FILE, resolved through Paths::config_dir()) by goose configure or the Desktop settings screen; nothing fetches them from a central place. The only control that is pulled from a URL is the extension allowlist (GOOSE_ALLOWLIST). The other central levers are environment variables, which override config files: GOOSE_MODE pins the mode (auto, approve, smart_approve, chat) and GOOSE_PATH_ROOT relocates the whole config/data/state tree, so an admin-managed root with a read-only permission.yaml is the closest thing to enforcement. A user who can edit their own environment can undo both. For a hard rule on individual tool calls there is the PreToolUse hook (docs/guides/context-engineering/hooks.md): a plugin under ~/.agents/plugins/ or <project>/.agents/plugins/ can return {"decision":"block"} and, with on_failure: block, fails closed.

Identity: goose has no notion of its own. A stdio extension is a process started on the engineer's machine with envs plus env_keys, resolved from the process environment first and then the user's secret store (merge_environments in crates/goose/src/agents/extension.rs). A streamable_http extension sends the headers you configure or runs its own OAuth flow through a local callback (GOOSE_OAUTH_CALLBACK_PORT). So an extension acts as whatever credential the engineer put there: their own token by default, a shared service account only if everyone is handed the same secret. Session-scoped identity would have to come from the MCP server side.

[yaohuangguan]

The current code-level answer above is right; for an org rollout I would not treat the client-side permission file as the security boundary.

The pattern that has worked best for MCP-style deployments is:

1. Local UI permissions = UX guardrail. Ask Before / Never Allow is still useful, but assume a developer who controls their machine can change local config.
2. Enforce hard policy at the tool boundary. Put authorization in the remote MCP server (or a gateway in front of several servers): caller identity, tool name, resource scope, environment, and policy decision should all be checked server-side before execution.
3. Use per-user identity by default. Avoid a shared GitHub/cloud/database token for interactive engineering work. A shared service account destroys attribution and makes revocation/blast-radius management much harder.
4. Mint short-lived, least-privilege credentials where possible. Let the MCP server exchange the user's authenticated identity for a scoped credential for the exact backend/service it needs. Do not forward a broad bearer token through every tool.
5. Separate read and write capabilities. Read-only tools can be broadly enabled; mutating tools should have narrower scopes and, for high-impact actions, an additional approval/policy check.
6. Log decisions, not secrets. Record user, tool, target/resource, policy result, and request/session correlation ID. Never log the raw credential or sensitive tool arguments unless explicitly required.

For remote MCP specifically, the newer MCP auth model makes this cleaner because the authorization server can issue credentials to the user/client rather than relying on a credential embedded in the extension. The server should still enforce its own authorization; authentication in the client is not enough.

So for a large team I would think of Goose's local permission system as one layer:

Goose local permission / approval
        ↓
org policy gateway or MCP server authorization
        ↓
short-lived scoped backend credential
        ↓
GitHub / cloud / DB

The awkward part is exactly what you called out: once a stdio extension inherits local environment variables, org-wide policy becomes difficult to prove. If centralized enforcement matters, I would prefer remote MCP for sensitive integrations and keep stdio tools limited to low-risk local operations.

Useful MCP auth references:

• https://modelcontextprotocol.io/specification/2026-07-28
• https://ts.sdk.modelcontextprotocol.io/v2/migration/support-2026-07-28

[Thepluscode]

Thanks both, this is the clearest answer I've had. @yaohuangguan, have you run the gateway-at-the-tool-boundary pattern for a team, or is it the design you'd choose? If you've run it, what was hardest: identity exchange, policy authoring, or proving afterwards who authorised a call? @CedricConday, is anyone you know relying on the PreToolUse hook as an org-wide control? Happy to do 20 minutes if that's easier.