How to Secure Goose MCP Extensions in 2026: Permissions, Prompt Injection & Local AI Safety

Goose is becoming a serious local-agent platform: it can run with Ollama, connect to MCP extensions, execute shell commands, edit files and orchestrate multi-step work. That combination is useful precisely because an agent can do more than a chatbot. It is also the reason a “local” agent should not automatically be treated as a safe agent.

The security boundary is not only the model. It is the combination of the model, the working directory, shell access, file permissions, MCP servers, downloaded recipes and the approval policy around tool calls. Goose's current documentation explicitly notes that its Developer extension can execute shell commands and modify files with the user's privileges, while its security controls let you choose autonomous, approval, smart-approval or chat-only operation.

This guide shows how to harden a Goose installation without making it useless: start with a low-risk permission mode, restrict tools, isolate untrusted repositories and MCP extensions, enable the relevant prompt-injection protections, and verify the resulting behavior before giving the agent access to important code or credentials.

Why a local Goose agent can still be dangerous

Running an LLM locally can keep prompts and model inference on your machine, but that does not mean the agent has a sandbox. If Goose is allowed to run a shell command as your normal user, that command gets the same operating-system permissions available to that user. Likewise, a file-writing tool can modify any accessible file within its effective scope.

That distinction matters when an agent reads untrusted content. A README, issue, web response, repository file or MCP result can contain instructions designed to manipulate the model. Goose's own security discussions have described prompt-injection scenarios where untrusted text could reach an agent that also has shell, write and network capabilities.

Start Goose in approval mode

Goose supports several permission modes. Autonomous mode is convenient, but it removes the approval step. Manual Approval requires review of actions, Smart Approval lets Goose decide which actions require review, and Chat Only disables tools.

For an unfamiliar repository or a project containing sensitive material, start with manual approval:

goose session --permission-mode approve

If your installed CLI uses the in-session mode selector, you can also change the mode during a session:

/mode approve

The exact CLI surface can vary by Goose release, so if a command is rejected, use goose configure and the current Goose documentation for your installed version. The important security principle is unchanged: test an agent with approval before granting autonomous execution.

Use Chat Only when you do not need tools

There are tasks where tool access provides no value. If you only want an explanation, code review from pasted text, brainstorming or a transformation of text already in the conversation, disable tools rather than leaving a shell and filesystem interface available.

Chat Only is particularly useful for testing a new local model. It lets you separate “does this model produce useful answers?” from “does this model safely operate my computer?”

Understand Goose's Developer extension before enabling it

The Developer extension is powerful because it supplies the tools an agent needs to work on software. Goose documents shell, write and edit as high-risk capabilities because they can execute commands or modify accessible files. The tree and image-reading tools are lower-risk read-oriented capabilities.

Do not solve every problem by disabling the entire Developer extension. Instead, decide what the task actually needs. A codebase exploration task may need tree and read capabilities but not shell execution. A documentation task may need file writing but not package installation. A test-fixing task may require shell access.

Do not put secrets in the agent's working directory

A common mistake is launching an agent from a directory containing everything: source code, .env files, SSH configuration, cloud credentials, database dumps and personal documents. A local model does not need internet access for this to become a problem; the agent may read those files and place their contents into another tool call or an external MCP request.

Use a dedicated working directory and keep secrets outside it. For development, use environment variables or narrowly scoped credentials where appropriate. Never give a local coding agent a long-lived production token merely because a command is easier that way.

Be careful with MCP extensions

Goose extensions are based on MCP, which makes the ecosystem powerful but also means an extension can add meaningful capabilities. Goose's documentation says external extensions are checked for known malware before activation, but a malware scan should not be treated as a complete trust decision.

Ask four questions before installing an extension:

1. What program actually runs?
2. What files, network resources or credentials can it access?
3. What tools does it expose to the agent?
4. Do I need this extension for the current task?

For organization-wide deployments, Goose also supports an extension allowlist. The allowlist can restrict which MCP installation commands users are permitted to install. This is a much stronger control than asking every developer to remember which extensions are approved.

Inspect command-line MCP extensions

Command-line extensions deserve special attention because they start a local process. Before approving a configuration, inspect the executable and arguments rather than copying a snippet from a random blog post.

A useful review pattern is:

which your-mcp-command
your-mcp-command --help

On Windows, use the corresponding PowerShell command such as Get-Command. Verify the executable path, package source and arguments. Prefer pinned versions and reproducible installation instructions when an extension is part of a long-lived workflow.

Treat shared Goose recipes as untrusted input

Recipes are useful because they package repeatable workflows, extensions and parameters. They are also configuration, not just prompts. In July 2026, a public Goose issue reported that a shared recipe could specify process-spawning command arguments and shell checks in ways that deserved stronger review. The issue was accepted for design discussion, so the safest operational rule is simple: inspect recipes before running them, especially when they came from a URL, repository or another person.

Do not treat a recipe security warning, source repository or “local” label as proof that a recipe is harmless. Read the extension commands, arguments, retry checks and referenced files yourself before execution.

Use prompt-injection protection as a layer, not a guarantee

Current Goose configuration exposes prompt-injection detection settings, including pattern-based and ML-based classifier options. The security documentation also describes Adversary Mode, which uses a separate reviewer to evaluate tool calls before execution.

These mechanisms can reduce risk, but they are not a substitute for least privilege. If a tool can delete files or run arbitrary commands, the safest design is still to reduce what that tool can access and require approval for consequential actions.

One important implementation detail is that Goose's current Adversary Mode documentation says the reviewer is fail-open if it fails: a reviewer failure allows the tool call through. That means you should not design your security model around the reviewer being the final enforcement boundary.

Protect untrusted repositories

If you want Goose to inspect a repository you do not fully trust, clone it into an isolated directory first. Avoid putting the repository next to your personal files. For higher-risk work, use a container, disposable virtual machine or separate OS user with limited permissions.

The isolation boundary should cover more than the model. A container that has the host Docker socket, broad mounted directories or production credentials is not meaningful isolation for an autonomous coding agent.

A practical safe setup for a local developer

For everyday development, a sensible baseline is:

1. Run the current Goose release rather than an old binary.
2. Use a dedicated project directory.
3. Keep secrets outside that directory.
4. Start new or unfamiliar sessions in approval mode.
5. Enable only the MCP extensions you actually need.
6. Review shell commands that install packages, modify system settings or access networks.
7. Use stronger isolation for untrusted repositories.
8. Return to autonomous mode only for tasks you already understand and have tested.

Verification checklist

Do not assume the configuration is secure because the settings look right. Test it.

When stronger isolation is appropriate

Use a container, VM, separate user account or disposable development environment when the agent will process untrusted repositories, execute generated code, install dependencies from unknown sources, access production systems or interact with valuable credentials.

For highly sensitive environments, consider a dedicated machine with no access to production networks. The goal is to make a successful prompt injection boring: the agent should have little valuable data and few dangerous capabilities to reach.

Goose security configuration locations

Current Goose documentation places the primary configuration at ~/.config/goose/config.yaml on macOS/Linux and under the Goose application configuration directory on Windows. Permission settings and runtime decisions are stored separately. Review these files when debugging a configuration that appears different between sessions.

# macOS / Linux
~/.config/goose/config.yaml

# Windows
%APPDATA%\Block\goose\config\config.yaml

Goose also exposes settings for prompt-injection detection and telemetry. Review those settings deliberately rather than assuming that “local model” means “nothing is ever transmitted.” An MCP extension may contact a remote service even when the model itself is running locally.

FAQ

Is Goose safe to run with Ollama?

Local inference reduces the need to send model prompts to a cloud model provider, but Goose still has access to tools you enable. Ollama does not sandbox Goose's shell, filesystem or MCP extensions.

Should I use Autonomous mode?

Use it only when the project and available tools are trusted and the consequences of an unexpected action are acceptable. Approval mode is a better starting point for unfamiliar environments.

Can an MCP server access my files?

Potentially. It depends on the MCP server and the permissions of the process it runs. Review the extension's executable, arguments and documented capabilities before installation.

Does prompt-injection detection make an agent safe?

No. Detection is a defense layer. Least privilege, approval controls and operating-system isolation remain important because detection can miss attacks.

What is the safest way to test a new Goose extension?

Use a disposable project, no production credentials, manual approval and the smallest set of extensions necessary. Observe exactly which processes and network connections appear before adopting the extension for important work.

Official sources

• Goose Developer extension and access controls
• Goose extensions documentation
• Goose Adversary Mode
• Goose Extension Allowlist
• Goose v1.52.0 release
• Goose recipe security issue

Related GyanAangan guides

• Goose + Ollama Local AI Agent Setup in 2026
• OpenCode + Ollama Troubleshooting 2026
• Ollama Out of Memory in 2026
• How to Build a Private Local RAG System in 2026