All posts
· 11 min read ·

Goose runs entirely on your machine. That changes what 'agent trust' means.

Goose is the only AAIF anchor project whose default operating mode runs entirely on the user's machine. The trust boundary distributed across vendor, registry, and remote tool collapses into the OS the user already trusts. The inversion is a different trust model, not a UX preference.

Goose shipped v1.34.1 on May 15, 2026 (two days before this post) and crossed 45,400 stars on GitHub. It is the only AAIF-anchor project whose default operating mode is to run entirely on the user's machine. Claude Code, Cursor, Devin, and the rest of the coding-agent field default to executing the agent inside a vendor's cloud and reaching into the user's environment over a protocol. Goose inverts that default. The agent process runs on your laptop. Its tool calls hit your local file system, your local terminal, your local MCP servers. The LLM provider is still remote, but the rest of the agent's blast radius is bounded by the operating system you're already sitting in front of.

That inversion is not a UX preference. It is a different trust model. The question a consumer asks of a cloud-mediated agent (which vendor's infrastructure is my code running through?) does not apply to goose. The question that takes its place is which local processes, files, and tools is this agent able to touch?, and that one the OS has been answering for decades.

What goose actually is

A short fact sheet, useful for framing the rest:

  • Written in Rust, originally open-sourced by Block in early 2025 and donated to AAIF in December 2025 alongside MCP and AGENTS.md.
  • Ships three interfaces (desktop app, CLI, embeddable API) and integrates with 15+ LLM providers including Anthropic, OpenAI, Google, Ollama, OpenRouter, Azure, and Bedrock.
  • Supports 70+ MCP extensions, run locally by default. Servers can also be remote.
  • Apache-2.0 licensed, 45,400 stars at time of writing, latest stable release v1.34.1 on May 15.

The notable absence from that list: a hosted execution environment. Goose has no vendor-side runtime. The binary on the user's machine is the agent. That places goose in the same architectural lineage as the local-first software movement: applications whose primary state lives on the user's device and whose collaboration happens through explicit sync, not through a server.

What the trust boundary actually moves

Cloud-mediated vs local-first agent trust boundaries Two stacked diagrams comparing a cloud-mediated agent and a local-first agent. The cloud-mediated agent has three trust boundaries: between user and vendor, between vendor and registry, and between registry and target service. The local-first agent collapses the middle boundaries: agent and tools both live on the user's machine, with only the LLM provider remaining off-machine. The OS boundary becomes the load-bearing trust line. CLOUD-MEDIATED AGENT · 4 NESTED TRUST DOMAINS user files, creds vendor cloud agent runtime registry MCP discovery MCP server remote tool service DB, API

FOUR TRUST BOUNDARIES, ALL LEGIBLE TO ATTACKERS

LOCAL-FIRST AGENT (GOOSE) · 1 BOUNDARY THAT MATTERS

user's machine · OS trust boundary goose agent local process local MCP servers your stdio your files filesystem terminal · git · build tools · dev environment all reachable, all OS-permission-bound LLM provider (off-machine) Anthropic, OpenAI, Ollama, ...

the only network-side trust call

The diagram makes the structural difference legible. A cloud-mediated agent has four trust boundaries that an attacker can target, and each boundary is the responsibility of a different party. The local-first agent collapses three of those four boundaries into the OS trust domain the user already has. The remaining boundary, the agent's call to its LLM provider, is the only one that crosses the network.

This does not make goose more secure than a cloud-mediated agent in the unqualified sense. It changes which threat model is load-bearing. A goose user's exposure to a malicious MCP server is the local stdio command injection class that has been disclosed at population scale this spring. A Cursor user's exposure to the same class lives on Cursor's infrastructure and is mediated by Cursor's vetting. Both are real risks. They are different risks.

What still leaves the machine

The local-first label is precise but partial. Three things in goose's default configuration still cross the network:

  • The LLM provider call. Inference happens at Anthropic, OpenAI, Google, Bedrock, Azure, or an Ollama-style local LLM if the user chooses it. Local inference removes even this boundary; cloud inference does not.
  • Remote MCP servers. Goose supports both. A remote MCP server call carries the same trust properties as a cloud-mediated agent's tool call would — vendor identity, transport security, and (per the spec's optional authorization) Origin validation are the user's problem.
  • The extension marketplace. Goose can install MCP extensions from public sources. Local-first execution does not mean local-source provenance.

A goose deployment that uses only local LLM inference, only locally installed and vetted MCP servers, and stays inside its own machine has collapsed all the network-side trust calls into the LLM model itself. That is the strongest form of the trust-boundary collapse, and it is achievable today. Most deployments do not run it. Most use cloud inference and a mix of local and remote MCP servers, and they get the partial version of the inversion.

What this means for registries

If you operate a registry that publishes MCP server claims for use by cloud-mediated agents, your downstream consumer is the vendor's runtime. The vendor decides what to do with the claim. If you operate a registry that publishes MCP server claims for use by goose or a similar local-first agent, the downstream consumer is the user's machine. The user decides what to do with the claim.

Those two decisions have different shapes. A vendor can apply centralized policy: blocklists, scan results, conformance score gates. A user, by default, applies whatever the agent's CLI surface exposes to them. The Agenstry-relevant observation is that probe data matters more, not less for local-first agents, because the user has fewer policy intermediaries between them and the registry. A signed agent card that hasn't been probed for behavior is a card. The probe is the user-side defense that a vendor would otherwise apply on the user's behalf.

The work Agenstry publishes is, at root, the public-side analogue of the trust check a careful goose user makes before installing an extension. The user check happens at install time on the machine. The public probe happens continuously across the population. They compose; they don't substitute. The interesting question for local-first adoption is whether the public probe data gets pulled into goose's extension installer flow as a default signal rather than as a thing the user has to look up.

What we're watching

Three things, observable within the next two quarters:

  1. Whether goose ships a probe-aware extension installer. A flag in the installer that surfaces "this MCP server has been probed continuously for the last 90 days; here's its conformance funnel" would be the cleanest expression of the local-first / probe-data composition.
  2. Whether AAIF's project lifecycle policy graduates goose first. The first graduation under AAIF's Growth/Impact/Emeritus stages will signal the foundation's actual bar. Goose is the most user-visible AAIF anchor; it is also the one most likely to surface conformance gaps as it scales.
  3. Whether enterprise teams begin to ship goose internally as a local-first replacement for cloud coding agents. Uber's pattern of building an MCP gateway implies cloud-side mediation; a parallel pattern with local-first agents would shift much of that mediation onto the developer's workstation. The first public case study will be informative.

The cloud-mediated agent stack is the loud part of this year's agent infrastructure story. The local-first stack is quieter, smaller, and asking a slightly different question about what the trust boundary actually is. Goose's v1.34.1 release is one data point. The next twelve months will tell whether it is also the architecture pattern that more of the agent web adopts.

Sources

← Back to blog Agenstry