Goose ships with compounding security defaults that together equal dangerouslySkipPermissions

Published: 2026-03-17 Last verified: 2026-04-19 validated
5 claims 0 tested finding

Goose ships with compounding security defaults that together equal dangerouslySkipPermissions

From Theory Delta | Methodology | Published 2026-03-17 | Updated 2026-04-19

What you expect

Goose is an open-source AI agent (33K+ stars) you install locally. You add MCP extensions for the tools you need. The documentation describes security configuration as available for users who want it — implying sensible defaults for users who don’t configure it.

What actually happens

Every tool in Goose is an MCP server — there are no built-in tools. The MCP security boundary is the only security boundary. And the default configuration removes it across five compounding settings:

1. Autonomous mode with no approval prompts (GOOSE_MODE=auto). Goose runs fully autonomously by default. Tool calls — file modification, deletion, extension execution, arbitrary shell commands — proceed without user confirmation. This is the outer containment layer. It is off.

2. No extension allowlist (GOOSE_ALLOWLIST absent). Any MCP server can be added and used without source restriction. Combined with the v1.27.0 in-app MCP marketplace (shipped March 5, 2026), installing a new extension is frictionless. There is no mechanism to restrict which servers are permitted. A malicious MCP server gets immediate, unapproved execution.

3. Injection detection disabled (SECURITY_PROMPT_ENABLED=false). Goose ships with prompt injection detection, but it is off by default. An MCP server that returns injection payloads in tool responses will not be flagged. Related fields (SECURITY_PROMPT_THRESHOLD, SECURITY_PROMPT_CLASSIFIER_ENABLED for ML-based detection) are also not enabled by default.

4. 1000-turn ceiling (GOOSE_MAX_TURNS=1000). The maximum conversation length defaults to 1000 turns. This is not a safety limit. A prompt injection delivered through a malicious extension faces zero barriers between injection and 1000 unreviewed tool calls, including file deletion.

5. Permissions file fail-open on corruption (< v1.26.2, patched March 4, 2026). In versions prior to v1.26.2, a corrupted permission.yaml caused Goose to silently allow all tool use with no warning — the agent proceeded as if no permission file was configured. The fix (v1.26.2) changed this to a hard panic. If you are on v1.26.2 or later, this specific behavior is fixed. If you are on an earlier version, any crash or file corruption event can silently escalate to full permissions.

Each default removes a guardrail that would contain the others. Autonomous mode without an allowlist means any server runs. No injection detection means malicious servers are not caught. A 1000-turn ceiling means they have time. The fail-open corruption behavior meant even explicit restrictions could be silently removed. This is the Goose equivalent of Claude Code’s dangerouslySkipPermissions — the difference is Claude Code requires an explicit opt-in flag. Goose ships this way.

What this means for you

If you installed Goose and started using it without configuration: you are running in the equivalent of no-guardrails mode. Your agent can modify and delete files, execute arbitrary extensions, and take 1000 consecutive tool actions — all without approval, without injection detection, and without any mechanism to restrict which MCP servers it uses.

If you trust the permission file to contain blast radius: on versions prior to v1.26.2, a corrupted file silently granted full access with no warning. On v1.26.2+, corruption now panics instead. Update and verify your version.

If you’re evaluating Goose’s security posture against Claude Code: the difference is architectural. Claude Code ships built-in tools and treats MCP as an optional extension layer — core functionality continues when an MCP server fails. Goose’s everything-is-MCP design means every tool depends on MCP connections, and the security controls that would contain a malicious extension are opt-in.

If you’re adding extensions from the in-app marketplace (v1.27.0+): the marketplace has no behavioral vetting. Without GOOSE_ALLOWLIST, you can add any extension without source restriction. Treat every extension install as a new dependency with full system access.

What to do

  1. Set GOOSE_MODE=smart_approve. This mode selectively prompts for high-risk actions (file deletion, extension installation) while allowing low-risk actions to proceed. The auto default exists and is documented, but its security implications are not flagged.

  2. Configure GOOSE_ALLOWLIST. The field takes a URL pointing to an approved extension registry. Without it, any MCP extension installs without source restriction.

  3. Enable injection detection. Set SECURITY_PROMPT_ENABLED=true. Consider also enabling SECURITY_PROMPT_CLASSIFIER_ENABLED for ML-based detection. The built-in detection is not perfect, but it catches obvious payloads.

  4. Reduce GOOSE_MAX_TURNS. 10–50 turns is sufficient for most tasks. 1000 turns of autonomous execution is not a safety boundary — it is a blast radius multiplier.

  5. Update to at least v1.26.2 to get the permission file panic-on-corruption fix. Pin to a version you have reviewed; Goose has a pattern of silent deprecations and removals between minor versions (v1.25.0, v1.26.0, v1.27.0 all had breaking behavior changes with no deprecation warnings).

Evidence

DefaultValueRiskSource
GOOSE_MODEautoFully autonomous: no approval for file modification, deletion, or extension executionGoose config docs
GOOSE_ALLOWLISTabsentAny MCP extension installs without source restrictionGoose config docs
SECURITY_PROMPT_ENABLEDfalsePrompt injection detection disabled by defaultGoose config docs
GOOSE_MAX_TURNS10001000 consecutive tool actions before any automatic stopGoose config docs
permission.yaml corruption (< v1.26.2)fail-openCorrupted file silently allowed all tool use; fixed to panic in v1.26.2v1.26.2 changelog, PR #7458

Confidence: validated — security defaults confirmed through source code review and default configuration analysis. No runtime exploitation was performed; the compounding interaction is assessed architecturally. Permission fail-open confirmed via v1.26.2 changelog and PR #7458.

Falsification criterion: This claim would be disproved by demonstrating that Goose’s default configuration (on the current release) includes at least one of: mandatory user approval for tool calls, an extension allowlist, or enabled injection detection.

Seen different? Contribute your evidence — theory delta is what makes this knowledge base work.