El plugin opencode-policy añade 309 reglas para proteger a los agentes de IA de inyecciones y fugas

opencode cuenta ahora con el plugin opencode-policy, una capa de protección situada delante del modelo y de las herramientas. Incluye 309 reglas: 27 contra prompt injection y 282 para llamadas peligrosas a herramientas, entre ellas intentos de leer .env, extraer variables de entorno, codificar datos con base64 y ejecutar comandos de shell sospechosos. La idea es sencilla: bloquear el riesgo de antemano, antes de que el agente ejecute nada.

Procesado por IA desde Habr AI; editado por Hamidun News
El plugin opencode-policy añade 309 reglas para proteger a los agentes de IA de inyecciones y fugas
Fuente: Habr AI. Collage: Hamidun News.
Escuchar artículo

Para opencode se ha propuesto una capa de protección independiente que intercepta las solicitudes peligrosas antes de que lleguen al modelo o se pasen al shell y a las herramientas de archivos. El plugin opencode-policy usa reglas deterministas, no solo el prompt del sistema, y cubre los escenarios típicos de ataque contra agentes de IA: prompt injection, lectura de archivos ajenos, intentos de extraer variables de entorno, preparación de datos para su exfiltración y ejecución de comandos sospechosos. La versión base incluye 309 reglas, que se pueden ampliar según la infraestructura de cada usuario.

La idea surgió de la práctica en competiciones de agentes de IA, en las que se les colaban instrucciones maliciosas a los participantes de forma deliberada. En esas pruebas se podía pedir al agente que olvidara las reglas anteriores, mostrara el prompt del sistema, leyera .env, ~/.ssh o /proc/self/environ, decodificara una carga útil y ejecutara algo en nombre del usuario. Por eso el autor del plugin sacó la protección del propio modelo: si un comando peligroso ya ha llegado a la ejecución de la herramienta, reaccionar es tarde. El filtro actúa antes y comprueba tanto los mensajes del usuario como los argumentos de las herramientas.

La integración con opencode se apoya en dos hooks. El primero transforma los mensajes antes de enviarlos al modelo y busca señales de prompt injection en campos de texto, entre ellos text, prompt, command y source.value. El segundo se activa antes de ejecutar una herramienta y analiza no solo la ruta del archivo, sino también el nombre de la herramienta, el comando de shell, el texto de la solicitud y otros argumentos. Si una regla coincide, la solicitud no avanza: al modelo se le entrega en su lugar una negativa segura, y la ejecución de la herramienta se detiene con un error de política. Este enfoque hace que el comportamiento sea predecible y fácil de auditar.

Actualmente el plugin tiene 282 reglas para llamadas a herramientas y 27 contra prompt injection. Se almacenan en JSON y funcionan como un conjunto de políticas regex. Se bloquean firmas típicas como ignore previous instructions, etiquetas falsas [developer] y [system], los comandos printenv y echo $TOKEN, accesos a /run/secrets y /proc/self/environ, así como intentos de codificar datos con base64, xxd u openssl enc. Cada activación se registra en un log JSONL con la hora, el tipo de evento y el identificador de la regla. Esto ayuda a analizar incidentes, detectar falsos positivos y añadir rápidamente nuevos patrones a partir de ataques reales.

El lado práctico también es muy terrenal. El plugin se instala con un solo comando, npm install opencode-policy, y se conecta mediante la configuración de opencode; a partir de ahí, los mensajes y las llamadas a herramientas pasan automáticamente por la capa de reglas antes de ejecutarse. El autor subraya que el conjunto de políticas es abierto y puede ampliarse para una infraestructura concreta, y que el enfoque también es compatible con modelos locales, siempre que funcionen a través de opencode. Eso lo hace útil no solo para asistentes en la nube, sino también para los entornos internos de agentes de las empresas.

También importa que el autor apuesta deliberadamente por mecanismos simples y transparentes, y no por otra capa de LLM sobre un LLM. Para algunas amenazas no hace falta una semántica compleja: los nombres de archivos secretos, los comandos que vuelcan el entorno y las plantillas de jailbreak son bastante concretos. El enfoque regex es más fácil de revisar, actualizar y vincular a casos concretos, y tras un incidente se puede añadir una regla nueva de forma muy puntual. Este diseño conservador resulta especialmente útil donde importan la reproducibilidad y las pruebas deterministas, más que una estimación probabilística del riesgo.

Por sí solo, este filtro no sustituye al sandbox, las restricciones de permisos, las listas blancas de herramientas ni el aislamiento de red. Pero para sistemas de agentes que trabajan con código, shell, CI/CD, repositorios internos y secretos, aporta una importante capa temprana de defensa. Su principal valor es la previsibilidad: las reglas las puede leer una persona, son fáciles de revisar y probar, y la protección no depende del modelo que haya debajo. Con el auge de los agentes de IA autónomos, esto parece menos una opción adicional y más una higiene básica para producción.

Historia
ZK
Zhemal Khamidun — CPO de Alpina Digital, product manager de AlpinaGPT. Crea productos de IA desde 2019. Hamidun News es un proyecto personal que creció hasta ser un agregador en producción con más de 6.000 lectores.
✦ Unified AI Workspace · Nomad

Test Frontier LLMs & Autonomous Agents in One Workspace

Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.

Try Nomad AI →Launch Nomad Agent
¿Qué te parece?
Cargando comentarios…