OpenCode for Regulated and Enterprise Teams

Adopting an open-source coding agent inside a regulated organisation is a different exercise from adopting a commercial one. The open-source deployment lets you control where code goes, and OpenCode also offers an Enterprise vendor relationship for pricing and implementation.

Know who you would be contracting with before the data-handling questions start. OpenCode is an MIT-licensed open-source agent developed in public at anomalyco/opencode, and the company behind it, Anomaly, is the one selling the Enterprise product. The code you would deploy and the vendor you would sign with come from the same place.

The Decision This Page Settles

This page settles whether OpenCode can meet a hard data-residency or perimeter requirement, and which parts you build yourself versus buy from its Enterprise product. You will end with a mapped data path, a configuration model, and an honest list of what its public docs do not state.

Start from the Perimeter, Not the Brand

Most tool evaluations start with a feature grid and arrive at the security questions late. Reverse it. Write down the one requirement that would disqualify a tool outright, and test that first.

• Code must never leave our network: a local model is the only honest answer.
• Code may leave, but must not be retained: provider retention terms decide it.
• We need audit evidence for a regulator: you are buying paperwork, not features.
• We need it approved this quarter: published compliance documents win on speed.

OpenCode answers the first two well. On the third it is weaker: its public Enterprise page states no certification and links no audit report, so that evidence has to be requested under the Enterprise agreement rather than assumed from a provider's paperwork.

Map Every Outbound Path

OpenCode does not store code or context on its own service by default. Session data stays on your machine, and /share sends a shared conversation to OpenCode's hosting service.

A single session can reach the network through several independent paths, and each one has its own destination, credentials, and logs.

Path	Goes To	Control
Model requests	Provider or localhost	Provider config
Remote MCP servers	Third-party endpoints	Disable per server
Package installs	Public registries	Permission rules
Git operations	Your remotes	Deny rules on push

Run that list before a pilot, not after. A team that verified the model path and forgot the MCP path has verified a quarter of its perimeter and reported it as the whole thing.

The local-inference half of this has its own walkthrough in OpenCode local models with Ollama, including where the offline claim actually holds.

Run OpenCode Inside Your Own Infrastructure

The deployment story is the strongest part of the case. OpenCode runs on machines you already own, against a gateway you already control, with no vendor tenancy in the middle.

That gives a security team three things a hosted product usually cannot:

1. The agent's source is readable, so behaviour can be verified rather than trusted.
2. The model endpoint is yours, so retention is governed by your own contract.
3. Nothing is stored on OpenCode's service by default, so there is no vendor-side copy to reason about.

The cost is that operating it becomes your job. Upgrades, availability, and the gateway's own monitoring all land on an internal team, and a fast-moving open-source release cadence means those upgrades arrive often.

What OpenCode Enterprise Adds

The open-source tool is not the only option any more, and evaluations written a few months ago miss this. OpenCode sells a per-seat Enterprise product, with a sales and implementation contact rather than a community forum as the only route in. No seat price is published, so the figure has to come from a sales quote.

Enterprise adds	What It Covers
Central config	Organization-wide defaults
SSO	Gateway credentials via your identity provider
Internal gateway	Only yours; other providers disabled
Pricing	Per seat, unpublished; quote from sales
Vendor contact	Sales and implementation

That changes the shape of the decision. Organization-wide enforcement and identity are now a product you can buy rather than something you assemble, and bringing your own gateway means OpenCode adds no token charge on top of what your provider bills.

Internal Gateway Versus Bringing Your Own

The internal-gateway row is the one most likely to be misread, so read it slowly. Pointing OpenCode at a gateway you run is already free: a provider entry in opencode.json sets the base URL and the open-source tool sends its requests there. Buying Enterprise is not how you get a self-hosted endpoint.

That entry is the whole mechanism, in the shape OpenCode's provider documentation gives for an OpenAI-compatible /v1/chat/completions endpoint. A gateway serving /v1/responses instead takes the @ai-sdk/openai package rather than the one below. Substitute your own gateway URL and the model IDs it serves:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "gateway": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Internal gateway",
      "options": {
        "baseURL": "https://llm.internal.example.com/v1"
      },
      "models": {
        "your-gateway-model-id": {
          "name": "Internal gateway model"
        }
      }
    }
  }
}

No OpenCode Enterprise agreement is needed for that. Commit the file and every clone receives the same gateway configuration, which is exactly why the Enterprise value has to be something other than the endpoint itself.

What the Enterprise central config adds is stated in three parts on the same page. It is set up once for the whole organization rather than repository by repository. It can integrate with your SSO provider so OpenCode obtains the gateway credential through your existing identity system.

The third part is the one procurement cares about: the central config can be set to use only your internal gateway, with all other AI providers disabled. That is the centrally managed restriction OpenCode Enterprise offers.

One thing the public docs do not state is which configuration layer carries that central config, and the answer decides how strong the restriction is. OpenCode publishes an eight-source precedence order in which remote organizational config from .well-known/opencode loads first as a base layer that global and project files can override.

Managed config files and macOS MDM preferences sit at the top of that same order and are described as not user-overridable. The Enterprise page does not say which layer it uses, so ask before you write "other providers are disabled" into a control description.

What none of this changes is the evidence question set out in Start from the Perimeter, Not the Brand. Enterprise-specific liability and support terms are not published on the Enterprise page, so ask how the public Terms of Use relate to the Enterprise agreement.

Choose Between Shared Defaults and Enforcement

Access control for a local agent is mostly your existing controls: who can log into the machine, who holds the provider credential, and who can push to the repository. The agent inherits all three rather than replacing them.

Shared configuration is where a team gets consistency. A project-root opencode.json is documented as safe to commit and takes highest standard precedence, so every clone starts from the same providers and permission rules.

Be precise about what that buys you. A checked-in file gives reviewable shared defaults, and it can still be changed or overridden locally, so a repository config is not enforcement. Organization-wide enforcement comes from Enterprise central config or from admin-controlled managed settings.

Credential handling deserves one explicit rule. Provider keys belong in the environment or a secrets manager, never in a configuration file that gets committed, because the whole point of the shared file is that it is readable by everyone.

Permissions Are Your Policy Surface

OpenCode ships permissive: out of the box it will run most operations without asking, and you tighten it yourself. For an individual developer that is a preference. For a regulated team it is the single most important configuration step.

Write the rules before the pilot, not after the first incident. A deny rule on pushes, an ask rule on anything that installs software, and an allowlist for the commands your build actually needs covers most of what a review board asks about.

The rule syntax, ordering, and the bounded-loop guards are covered in the advanced OpenCode guide. Treat that file as the written policy, and keep it in review like any other control.

What Procurement Will Ask For

A vendor relationship now exists, so the old "there is nobody to ask" answer is wrong. What is still missing is the Enterprise-specific document set, unchanged from the perimeter check.

The Status column below is the at-a-glance version. Published means the answer is in the public docs, request means ask the vendor for it during contracting, and self-managed means it never was theirs to answer.

Question	Status	Where the Answer Comes From
Audit report	Request	Not linked; ask Enterprise sales
Data residency	Self-managed when /share is disabled	Your own infrastructure and model provider
Access control	Published	SSO via Enterprise central config
Enterprise-specific terms	Request	Request during Enterprise contracting
Support commitment	Request	Not stated; ask Enterprise sales

The residency row carries a condition worth reading twice. It holds for the local or internal-gateway path with sharing turned off, because /share sends the conversation to OpenCode's hosted service and caches it on that service's CDN edge, and self-hosting those pages is still on the roadmap.

A hosting or model provider's attestation covers that provider's service, not OpenCode's central config, SSO, supply chain, or contract. Do not let one stand in for the other in a submission.

Every row that stays yours is real work with a real owner, so name that owner in the proposal rather than leaving the cell to imply somebody has it.

Where a Commercial Vendor Wins

A commercial editor offers published compliance evidence, single sign-on, directory provisioning, and audit logs, most of them admin-configured rather than on out of the box. For a team whose blocker is a procurement calendar rather than a network boundary, that is still the faster path.

The trade runs the other way when the requirement is absolute. If code cannot leave the perimeter, a hosted agent that routes requests through a vendor backend cannot satisfy it, however good the paperwork is.

The full head-to-head on that trade, including pricing and the agent layer, is in Cursor vs OpenCode.

FAQ

Vendor facts on this page were checked against OpenCode's own documentation on August 9, 2026. The Enterprise product details, the internal-gateway distinction, and the config precedence order were re-verified on August 10, 2026.

Is OpenCode SOC 2 certified?

Its public Enterprise page states no certification and links no audit report, so treat OpenCode's own certification as unverified and request evidence under the Enterprise agreement. Your hosting and model providers have their own attestations, and those cover their services only. They say nothing about OpenCode's central config, SSO, supply chain, or contractual controls.

Does OpenCode store our code?

OpenCode does not store code or context on its service by default. Session data stays local, and the share command sends that conversation to OpenCode's hosting service. Your model provider, MCP servers, package registries, and Git remotes each keep their own retention terms.

Can OpenCode run fully air-gapped?

It can, with a local model and every remote tool disabled. Say local model inference when that is what you verified, and reserve air-gapped for a setup where the provider, tools, package installs, Git remotes, and telemetry have all been checked against the claim.

How do we enforce one configuration across a team?

Use checked-in project config for shared defaults, reviewed like code, knowing a developer can still override them locally. OpenCode Enterprise sells one organization-wide enforcement path through its central config, including the option to allow only your internal gateway. Ask which config layer it ships through, because OpenCode's published precedence order makes remote organizational defaults overridable while managed and MDM settings are not.

Who owns the model bill?

The open-source tool is free, while model costs depend on your provider, gateway, subscription, or local hardware. OpenCode Enterprise is priced per seat, with no published figure, and adds no token charge when you bring your own LLM gateway. Budget the model spend per team, because usage varies more than headcount does.

What should a pilot actually measure?

Measure where requests went, what commands ran, and how much review each change needed. Speed claims are the easiest to gather and the least useful for a compliance decision; the data path and the command log are what a security review will ask about.

Decide on the Requirement You Can Prove

Pick the smallest deployment that satisfies your hardest requirement. For most teams that is OpenCode against an internal gateway with checked-in permission rules, not a full air-gapped build that nobody has the hardware to run well.

Add Enterprise when the requirement is organization-wide enforcement, SSO, or a vendor contract, and price that per seat against what assembling the same controls would cost you.

Start from the OpenCode overview for the basics, and use the advanced guide to write the permission rules your pilot will be judged on.