Goose ships with five security defaults that compound into full system access

From Theory Delta | Methodology | Published 2026-03-17

What the docs say

Goose is an open-source AI agent (32K+ stars) that runs locally and uses MCP servers as its extension system. The documentation describes it as a flexible, extensible agent that can be customized for any workflow. Security configuration is available for users who want it.

What actually happens

Every tool in Goose is an MCP server -- there are no built-in tools. This means the MCP security boundary is the only security boundary. And the defaults remove it.

Five default settings interact multiplicatively:

1. Autonomous mode (no approval prompts). Goose runs in autonomous mode by default. Tool calls execute without user confirmation. This is the outer containment layer -- and it is off.

2. No extension allowlist. Any MCP server can be added and used. There is no mechanism to restrict which servers are permitted. Combined with autonomous mode, a malicious MCP server gets immediate, unapproved execution.

3. Injection detection disabled. Goose has prompt injection detection, but it is off by default. An MCP server that returns injection payloads in tool responses will not be flagged.

4. 1000-turn ceiling. The maximum conversation length defaults to 1000 turns. This is not a safety limit -- it is an operational limit. An agent running autonomously with no injection detection has 1000 turns to act before hitting any boundary.

5. Historical fail-open on corrupted permissions. When the permissions file is corrupted or missing, Goose has historically defaulted to granting full access rather than failing closed. This means a crash or file corruption event can silently escalate permissions.

Each default removes a guardrail that would contain the damage from 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. Fail-open on corruption means even explicit restrictions can be silently removed.

What to do instead

1. Disable autonomous mode. Require user approval for tool calls, especially for any MCP server that has filesystem or network access.
2. Create an extension allowlist. Only permit MCP servers you have reviewed. Treat adding a new server like adding a new dependency.
3. Enable injection detection. Turn on the built-in prompt injection detection. It is not perfect, but it catches obvious payloads.
4. Reduce the turn ceiling. Set maxTurns to a reasonable limit for your use case (10-50 for most tasks). 1000 turns of autonomous execution is not a safety boundary.
5. Audit the permissions file. Check that it exists, is not corrupted, and contains the restrictions you expect. Monitor it for unexpected changes.

Environments tested

Confidence and gaps

Confidence: validated -- security defaults confirmed through source code review and default configuration analysis. No runtime exploitation was performed; the compounding interaction is assessed architecturally.

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

Open questions: Has Goose changed any of these defaults in recent releases? Does the Desktop version have different defaults than the CLI? Are there enterprise deployment guides that address these defaults?

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