OpenCode enterprise security: a CTO playbook for plugins, providers, and tool permissions
OpenCode7 min readBusinessGovern the components behind an OpenCode deployment: model providers, plugins, tool permissions, configuration changes, and the OpenLeash integration path.
A configurable coding agent gives a platform team useful freedom. It also makes the deployed system larger than the core application. A CTO needs to know which plugins execute, which model routes receive data, which tools hold credentials, and who can change that composition after the initial review.
In this guide
Make the deployed composition the unit of approval
An approval that says “OpenCode is permitted” leaves important operational questions unanswered. Two engineers can use the same agent with different providers, plugins, tool servers, configuration files, and credentials. Their effective capabilities may be quite different even when the desktop inventory shows the same application name.
Create a deployment manifest that captures the runtime version, approved plugin sources, model endpoints, available tools, credential ownership, and configuration locations. Include who can change each item. The manifest does not need to expose secrets; it needs to identify the authority and data destinations those secrets enable.
This gives the CTO a concrete platform product to support. It also gives the CISO a reviewable boundary. A plugin added after the security assessment is a change to that boundary, not merely a personal preference. The same is true when a developer redirects model traffic to a different provider or adds a tool with access to an internal service.
Understand the native permission and plugin surfaces
OpenCode documents configurable tool permissions and a plugin system. Plugins can participate in the agent’s behavior through the interfaces exposed by the runtime. Treat them as executable components whose source, update process, and privileges deserve review. A familiar package name is not evidence that its current version has been assessed.
Permission configuration is version-sensitive. Use the documentation for the runtime you deploy, validate the configuration it actually loads, and avoid copying a policy example across major versions without testing it. This guide deliberately describes acceptance criteria rather than presenting a configuration fragment that could silently become wrong after an upgrade.
Native permission settings should remain part of the baseline even when OpenLeash is installed. Determine how local, project, and centrally distributed settings interact in your version. Then test the resulting behavior from a fresh session. A file that looks correct in source control does not prove that the running agent consumed it or that another layer did not override it.
A hypothetical failure: the provider review misses a plugin
Consider a fictional team that completes a careful assessment of its model provider’s data terms. The team then installs a community plugin to automate issue updates. That plugin uses a separate credential and service endpoint. The provider assessment remains valid for its original scope, but it says nothing about the new plugin’s destination or write authority.
The governance failure is a mismatch between the reviewed system and the deployed system. No model-provider breach is required. The organization simply added an executable component with a new path to business data. If the plugin can also modify configuration or invoke tools, the change may affect more than information disclosure.
Test the principle with an internal sample plugin and a mock issue service. Give it a clearly marked test credential and observe the calls it makes. Confirm that your component inventory, network policy, and action-control tests account for the new path. Do not assume that a conversation proxy sees every independent network request a plugin can make.
Where OpenLeash adds a common action layer
OpenLeash’s published coverage lists an installable OpenCode plugin and supported provider proxy configuration. Automatic provider configuration applies to supported strict JSON configuration; JSONC requires a guided setup. The distinction matters because a successful plugin installation and a successful provider route are separate verification results.
Validate the plugin’s supported action events with the exact OpenCode version in your manifest. Where a supported provider route is configured, verify that the intended session uses it. Do not equate provider routing with a general firewall for plugin traffic or subprocesses. Keep independent network and credential boundaries for paths outside the integration.
The practical value for a platform team is a policy layer that can evaluate supported actions across its enrolled agents, while the team continues to govern the underlying components. For the CISO, the evidence should state the runtime, plugin path, policy outcome, and limitations. “Protected” is useful only when it can be traced to a tested deployment and an understood action surface.
Build a supported platform baseline
Publish one initial configuration for a narrow engineering use case. Choose a model route, a minimal tool set, and a reviewed plugin set. Use a nonproduction workspace without unrelated personal credentials. Explain how developers request an additional component and how the platform team evaluates it; otherwise, the approved baseline will quickly become a starting point for unmanaged variations.
For each requested plugin or tool server, ask what code executes, where it runs, what data it receives, and what authority it needs. Record the maintainer, update source, rollback method, and internal owner. A small integration that writes to a customer system may need more scrutiny than a large read-only development helper.
- Configuration loading: verify the effective runtime configuration from a fresh session, including project-level influence.
- Ordinary development: confirm the approved tools can finish a representative task without unnecessary policy interruptions.
- Action boundary: exercise a harmless out-of-scope write and confirm the configured supported-path outcome.
- Provider route: use a test session to verify the selected endpoint and avoid inferring routing from plugin installation alone.
- Component change: add a sample unapproved component in staging and verify how the organization detects or prevents drift.
- Upgrade and rollback: repeat the control tests after a runtime or plugin update, then prove that the previous approved baseline can be restored.
Review configuration changes like changes to infrastructure
A provider URL, permission rule, plugin list, or tool credential can change the system’s effective authority without changing application code. Put managed configuration through review and staged rollout. Make emergency changes possible, but record the reason, owner, scope, and expiry so an outage workaround does not become an indefinite platform exception.
Use a compatibility matrix rather than a vague statement that the latest version is supported. The rows should identify the runtime and relevant integration versions; the columns should capture the action tests, provider-route verification, and failure behavior. This is especially useful when a major release changes configuration semantics or plugin interfaces.
Do not force every developer experiment through a production-grade process. Offer a separate experimentation environment with synthetic data, limited credentials, and no path to shared production systems. The freedom to try new components becomes much easier to approve when the surrounding authority is deliberately small.
Separate data residency, tool safety, and software supply chain evidence
These three reviews often become mixed together. Provider assessment concerns where model input and output are processed and under what terms. Tool safety concerns what actions can occur and who authorizes them. Component review concerns the executable software you have chosen to trust. Passing one review does not settle the other two.
Assign evidence to the correct owner. Procurement and privacy teams can maintain provider agreements. Platform engineering can maintain the component manifest and update process. Service owners can define acceptable write actions. Security can verify that the combined deployment meets the organization’s risk standard and that gaps have explicit treatment.
OpenLeash action records can contribute evidence about supported agent decisions, but they should not be presented as a complete software bill of materials or a comprehensive record of every network operation. Combine them with the inventory and operational controls appropriate to your environment. The result should let an investigator reconstruct the deployed composition as well as the action that caused concern.
Decide when the platform is ready to expand
A useful rollout report shows task completion, integration reliability, configuration drift, approval friction, and unresolved component exceptions. Include the number of distinct approved configurations, because supporting twenty variations can cost more than supporting twenty additional users on one tested baseline.
Can developers choose any provider? That is a business and data-governance decision, separate from whether a provider route is technically supported. Make the approved choices explicit and provide a request path for exceptions.
Does an OpenLeash plugin make every extension safe? No. Validate the supported action surface and continue reviewing executable components. The next step for a CTO is to publish a small, versioned OpenCode baseline, run the acceptance tests, and assign an owner for every future change to its authority. That turns flexibility into an intentional platform capability.