OpenCues' security posture rests on one structural rule: LLM output never becomes an action. Model text is only ever draft text in your input box; it is never routed into tool execution, network fetches, clipboard or file writes. Worst-case prompt injection lands as words you can see and delete before you press Enter.
You are the commit boundary
Nothing OpenCues writes is submitted anywhere until you submit it. The inline agent edits only your unsent draft; the send action is always yours.
Third-party configs are contained
- JavaScript blanks run in a capability-restricted sandbox: no filesystem, no
process, norequire; network access is a hostname-exact allow-list; storage is namespaced per blank. - Script-backed blanks are local-or-shipped only; nothing auto-installs from the network without showing you the code or prompt first.
- Secrets are bound to declared hosts, so a blank cannot leak your API key to a domain it did not declare. An opt-in OS-level sandbox (
sandbox: strict) adds another layer for scripts. - Word-cue routing is isolated per source, so a hijacking prompt in one cue file cannot poison words it does not claim.
Your data
Text goes only to the provider you configured, on your own key or subscription. The optional identity feature defaults to safe mode, and the protection is bidirectional: the model sees token names like [FIRST NAME], stored values you type into the buffer yourself are dehydrated to those tokens before dispatch, and real values are substituted back on your machine after the response, so PII stays out of provider logs whether it came from the catalog or your own typing. Agent rewrites are validated against a length floor before touching your draft, and the merge preserves paragraph structure, so a draft is never wiped wholesale.
The full threat model lives in the repo's security documentation. Related: LLM providers · GitHub repo.