MemoryHub’s OpenCode plugin moves the secret boundary without removing the data boundary

MemoryHub’s new OpenCode integration draws a useful line between credentials and data: the plugin authenticates to MemoryHub from the host process, so the API key does not have to appear in an agent prompt, transcript or tool call. That is a real reduction in secret exposure, but it is not a blanket confidentiality guarantee for the memories retrieved after authentication.

What the plugin changes

The OpenCode plugin wraps MemoryHub’s MCP client and calls register_session itself. It resolves the server URL and API key from plugin options, environment variables or local credential files, then exposes six narrower memory tools for search, read, list, write, update and delete. On every eligible user message, it searches MemoryHub and injects a marker-guarded <relevant-memories> block into the latest user message. It also appends MemoryHub’s operating rules to the system prompt.

That architecture keeps the API key on the host side rather than asking the model to submit it through the MCP tool interface. Session registration is single-flight, and an expired session triggers one guarded reconnect and retry so concurrent callers do not repeatedly tear down the transport.

Where the trust boundary sits

The deployment therefore trusts the OpenCode host, its plugin runtime and the local secret source. A key stored in opencode.json can be committed accidentally; the project documentation recommends an environment variable or the shared MemoryHub credentials file instead. A compromised host process can still read those values. Host-side authentication protects against disclosure through model context; it does not protect a secret from the machine that must use it.

The retrieved memory is different. Auto-recall deliberately places selected memory content in the model request. The plugin prefixes that block with an untrusted-data warning so text stored as memory is framed as historical context rather than instructions, but the model provider can still receive the recalled content under the deployment’s normal inference and logging policy. MemoryHub scopes, project defaults and server-side authorization consequently remain part of the security boundary: retrieval must not return material that the active agent or model endpoint should not see.

Residual risks to check

The implementation records several early-stage assumptions. Its pending recall block is process-scoped rather than session-scoped, creating a concurrency boundary the project has already flagged for follow-up. The two OpenCode transforms used for memory and system-prompt injection are experimental APIs; if they stop firing, the plugin is designed to degrade to tools-only operation rather than break the host. TypeScript integration suites are not yet run by repository CI, and the documented end-to-end check used a local MCP stub; verification against a deployed MemoryHub cluster remains a deployment task.

Operators evaluating the plugin should therefore separate three questions: where the API key is stored, which identities and scopes MemoryHub permits, and which model endpoint receives recalled content. The plugin improves the first problem and supplies guardrails for the second and third, but it does not make those latter policy choices on the operator’s behalf.