opencode-policy plugin adds 309 rules to shield AI agents from injections and data leaks

A separate protective layer has been proposed for opencode. It intercepts dangerous requests before they reach the model or get passed to the shell and file tools. The opencode-policy plugin relies on deterministic rules rather than on the system prompt alone, and covers typical attack scenarios against AI agents: prompt injection, reading other people's files, attempts to extract environment variables, preparing data for exfiltration, and running suspicious commands. The default package contains 309 rules, which you can extend for your own infrastructure.

The idea grew out of AI-agent competitions, where participants were deliberately fed malicious instructions. In such tasks, an agent could be asked to forget its earlier rules, reveal its system prompt, read .env, ~/.ssh or /proc/self/environ, decode a payload and execute something on the user's behalf. That is why the plugin's author moved protection outside the model itself: once a dangerous command has reached tool execution, it is too late to react. The filter sits earlier and checks both user messages and tool arguments.

The integration with opencode is built on two hooks. The first transforms messages before they are sent to the model and looks for signs of prompt injection in text fields, including text, prompt, command and source.value. The second fires before a tool runs and analyzes not just the file path but also the tool name, the shell command, the request text and other arguments. If a rule matches, the request goes no further: the model receives a safe refusal in its place, and tool execution simply stops with a policy error. This approach makes behavior predictable and easy to audit.

The plugin currently has 282 rules for tool calls and 27 rules against prompt injection. They are stored in JSON and work as a set of regex policies. Blocked patterns include typical signatures such as ignore previous instructions, fake [developer] and [system] tags, the printenv and echo $TOKEN commands, access to /run/secrets and /proc/self/environ, and attempts to encode data with base64, xxd or openssl enc. Every match is written to a JSONL log with a timestamp, event type and rule identifier. This helps with incident analysis, spotting false positives and quickly adding new patterns based on real attacks.

The practical side is similarly down to earth. The plugin installs with a single command, npm install opencode-policy, and is connected through the opencode config. After that, messages and tool calls are automatically run through the rule layer before execution. The author stresses that the policy set is open and can be extended for a specific infrastructure, and that the approach also works with local models, as long as they run through opencode. That makes the tool useful not only for cloud assistants but also for companies' internal agent setups.

It also matters that the author deliberately bets on simple, transparent mechanisms rather than yet another LLM layer on top of an LLM. For some threats, complex semantics are genuinely unnecessary: the names of secret files, commands that dump the environment and jailbreak templates are quite concrete. A regex approach is easier to review, update and tie to specific cases, and after an incident a new rule can be added very precisely. Such a conservative design is especially useful where reproducibility and deterministic tests matter more than a probabilistic risk estimate.

On its own, this kind of filter does not replace a sandbox, permission limits, tool allowlists or network isolation. But for agent systems that work with code, shell, CI/CD, internal repositories and secrets, it provides an important early line of defense. The main value is predictability: humans can read the rules, they are easy to review and test, and the protection does not depend on which model sits under the hood. With autonomous AI agents on the rise, this looks less like an optional extra and more like basic production hygiene.