This repository wraps OpenCode as an A2A runtime. It exposes A2A HTTP+JSON and JSON-RPC interfaces, and adds authentication, task/session contracts, streaming, interrupt handling, and runtime guidance. It does not fully isolate upstream model credentials from OpenCode runtime behavior.

• A2A_STATIC_AUTH_CREDENTIALS protects access to the A2A surface, but it is not a tenant-isolation boundary inside one deployed instance.
• One OpenCode + opencode-a2a instance pair is treated as a single-tenant trust boundary by design.
• Tenant isolation across consumers is expected to come from parameterized self-deployment.
• For mutually untrusted tenants, use separate instance pairs with distinct Linux users, workspace roots, credentials, and runtime ports.
• Within one instance, consumers share the same underlying OpenCode workspace/environment by default.
• LLM provider keys are consumed by the opencode process. Prompt injection or indirect exfiltration attempts may still expose sensitive values.
• Payload logging is opt-in. When A2A_LOG_PAYLOADS=true, operators should treat logs as potentially sensitive operational data.
• This project does not ship host bootstrap or process-manager wrappers as an official product capability. Operators remain responsible for file permissions, secret storage, service users, and supervisor-specific hardening.
• Experimental V2 exclusive execution additionally requires a dedicated private network namespace, unshared upstream credentials, one gateway process, and no autonomous session writers. Loopback URL validation is not topology verification. See the restricted profile before enabling it; shared everyday OpenCode services are unsupported.
• Release artifacts are built in a read-only job, audited, and checksummed before separate least-privilege PyPI and GitHub Release jobs can upload them. Releases include a CycloneDX runtime SBOM.

This project is currently best suited for trusted or internal environments. Important limits:

• no per-tenant workspace isolation inside one instance
• no hard guarantee that upstream provider keys are inaccessible to agent logic
• static credential auth only by default; stronger identity propagation is still a follow-up hardening area
• operators remain responsible for host hardening, secret rotation, process access controls, and reverse-proxy exposure strategy

For the security surface mapping and residual-risk register, see docs/security-architecture.md.

Please avoid posting active secrets, bearer tokens, or reproduction payloads that contain private data in public issues.

Preferred disclosure order:

1. Use GitHub private vulnerability reporting if it is available for this repository.
2. If private reporting is unavailable, contact the repository maintainer directly through GitHub before opening a public issue.
3. For low-risk hardening ideas that do not expose private data, a normal GitHub issue is acceptable.

Security fixes are expected to land on the active main branch first.