Seguridad y controles de los LLM

Los modelos de IA pueden comportarse de forma inesperada. Esta documentación explica cómo controlar lo que pueden hacer los agentes de programación, establecer medidas de protección y orientar el comportamiento de los LLM hacia los resultados deseados.

Comprender el comportamiento de los modelos

Los LLM generan texto a partir de distribuciones de probabilidad, no recuperan datos de una base de datos ni ejecutan lógica determinista. Pueden producir resultados diferentes para la misma entrada, inventar datos o código que parecen plausibles pero son incorrectos y verse influidos por instrucciones cuidadosamente elaboradas (inyección de prompts).

No puedes confiar en que los LLM siempre tomen decisiones seguras. En su lugar, se combinan dos enfoques: controles de seguridad que imponen límites estrictos a lo que pueden hacer los agentes de programación y mecanismos de orientación que guían el comportamiento de los LLM hacia mejores resultados.

Para comprender mejor cómo funcionan los LLM, consulta Cómo funcionan los modelos de IA.

Dos enfoques para la seguridad

Cherri Code ofrece dos enfoques complementarios para gestionar el comportamiento de los agentes de programación de IA:

Controles de seguridad (aplicación determinista): Límites estrictos que bloquean operaciones peligrosas independientemente de lo que sugiera el LLM. Incluyen restricciones de comandos de terminal, hooks de cumplimiento que rechazan operaciones, flujos de trabajo de aprobación y aislamiento. Los controles de seguridad son tu principal defensa contra las acciones perjudiciales de los agentes de programación.

Orientación del LLM (guía no determinista): Mecanismos que orientan al LLM hacia un mejor comportamiento mediante la configuración de su contexto y las acciones disponibles. Incluyen reglas que añaden instrucciones a los prompts, comandos que proporcionan flujos de trabajo reutilizables e integraciones que enriquecen los conocimientos del agente. La orientación mejora la calidad de los agentes de programación, pero no garantiza la prevención de acciones perjudiciales.

Usa ambos enfoques conjuntamente. Los controles de seguridad proporcionan una red de protección. La orientación reduce la frecuencia con la que los agentes de programación intentan acciones problemáticas.

Controles de seguridad

Estos controles deterministas establecen límites estrictos sobre lo que los agentes de programación pueden hacer. Funcionan independientemente de lo que sugiera el LLM.

Restricciones de comandos de terminal

De forma predeterminada, Cherri Code requiere tu aprobación antes de ejecutar cualquier comando de terminal. Esto protege frente a comandos destructivos (eliminación de archivos, borrado de bases de datos), comandos que exponen datos confidenciales y comandos con efectos secundarios no deseados.

Cuando un agente quiere ejecutar un comando, aparece una instrucción con el comando completo. Puedes aprobarlo y ejecutarlo, denegarlo o modificarlo antes de ejecutarlo.

Riesgos de la aprobación automática

Puedes activar la aprobación automática para comandos de terminal, pero ten en cuenta los riesgos. Los agentes de programación podrían ejecutar comandos destructivos sin que lo sepas, los comandos se ejecutan antes de que puedas revisarlos y los errores o la inyección de prompts podrían provocar operaciones no deseadas.

Configuración del modo de ejecución

Los equipos Enterprise pueden configurar políticas de modo de ejecución en el panel de control del equipo. En Cherri Code 3.6 y versiones posteriores, los usuarios finales pueden elegir entre los modos Auto-review (el predeterminado), Allowlist y Run Everything. Auto-review ejecuta llamadas incluidas en la lista de permitidos, ejecuta los comandos de shell en un entorno aislado cuando es posible y envía el resto a un clasificador de LLM que permite o bloquea según la seguridad y el grado de coincidencia de la llamada con la intención del usuario. Puede crear una lista de permitidos de comandos que no requieren aprobación, como npm install, pip install, cargo build o make test.

La lista de permitidos se aplica según el mejor esfuerzo y no constituye un límite de seguridad. Los agentes de programación decididos o la inyección de prompts podrían eludirla. Combine siempre las listas de permitidos con otros controles de seguridad, como los hooks.

Consulte Modos de ejecución y Seguridad de los agentes para obtener más información.

Hooks de cumplimiento

Los hooks permiten ejecutar lógica personalizada en puntos clave del ciclo del agente.

• Antes de enviar instrucciones: Analiza las instrucciones para detectar datos confidenciales antes de enviarlas a los LLM. Bloquea los envíos que contengan claves de API o credenciales, información de identificación personal (PII) o información propietaria.
• Antes de leer archivos: Analiza los archivos antes de que los agentes de programación los lean. Censura o bloquea el acceso a archivos de configuración con secretos, PII en bases de datos o registros, o algoritmos propietarios.
• Después de generar código: Analiza el código generado antes de escribirlo en disco. Comprueba si hay vulnerabilidades de seguridad (inyección SQL, XSS), código con licencia que pueda causar problemas de propiedad intelectual o claves de API y credenciales en el código.
• Antes de ejecutar en la terminal: Bloquea comandos peligrosos o envíalos a flujos de trabajo de aprobación. Por ejemplo, bloquea todos los comandos git push, exige aprobación para cualquier comando sudo o bloquea instrucciones DROP en bases de datos.

Ejemplo: Bloqueo de comandos de git

Este hook intercepta comandos de shell y bloquea el uso directo de git, redirigiendo a los usuarios a la CLI de GitHub:

#!/bin/bashinput=$(cat)command=$(echo "$input" | jq -r '.command')if [[ "$command" =~ git[[:space:]] ]]; then    cat << EOF{  "permission": "deny",  "userMessage": "Git command blocked. Please use gh tool instead.",  "agentMessage": "Use 'gh' commands instead of raw git."}EOFfi

Ejemplo: Ocultación de secretos

Este hook analiza el contenido de los archivos en busca de claves de API de GitHub y bloquea el acceso si las encuentra:

#!/bin/bashinput=$(cat)content=$(echo "$input" | jq -r '.content')if echo "$content" | grep -qE 'gh[ps]_[A-Za-z0-9]{36}'; then    cat << EOF{  "permission": "deny"}EOF    exit 3fi

Consulta la documentación sobre Hooks para ver más ejemplos.

Protección de archivos confidenciales

No todos los archivos de tus repositorios deberían ser accesibles para la IA. Los archivos de configuración, los secretos y los datos confidenciales deben protegerse.

.cursorignore

El archivo .cursorignore funciona como .gitignore, pero controla a qué puede acceder Cherri Code. Los archivos que coinciden con los patrones de .cursorignore se excluyen de:

• Lectura de archivos por parte del agente de programación
• Selección de contexto

.cursorignore no es un límite de seguridad. Es una función práctica para excluir archivos del procesamiento de IA, pero:

• Los usuarios pueden leer manualmente los archivos ignorados
• Los agentes de programación podrían encontrar formas de acceder al contenido ignorado
• Los comandos de terminal y las herramientas MCP aún pueden leer archivos ignorados

Para una seguridad real, usa permisos del sistema de archivos o cifra los datos confidenciales.

Consulta Ignore Files para conocer la sintaxis detallada.

Protección del directorio .cursor

El directorio .cursor de los repositorios contiene ajustes, reglas y archivos de caché específicos del proyecto. Los equipos Enterprise pueden impedir que los agentes de programación modifiquen este directorio.

Cuando esta opción está activada, los agentes de programación no pueden:

• Modificar archivos en .cursor/
• Eliminar el directorio .cursor/
• Cambiar las reglas de Cherri Code o los archivos de ajustes

Los usuarios aún pueden editar estos archivos manualmente, pero los agentes de programación requieren aprobación.

Configúralo en el panel de control del equipo, en «Protección del directorio .cursor» (solo Enterprise).

Controles de origen del navegador

Los equipos Enterprise pueden restringir los sitios web a los que pueden acceder los agentes de programación mediante la herramienta de navegador. Defina una lista de permitidos de dominios aprobados; se bloqueará a los agentes de programación que intenten visitar otros orígenes.

Configure esta opción en el panel de control del equipo, en «Controles del navegador» (solo Enterprise).

Integración con herramientas de DLP

Muchas empresas ya cuentan con herramientas de prevención de pérdida de datos (DLP) que detectan datos confidenciales. Puedes integrar Cherri Code con tus herramientas de DLP de tres maneras.

Agentes de DLP en endpoints

La mayoría de las soluciones de DLP para endpoints pueden inspeccionar el tráfico de red de Cherri Code. Configure su DLP para supervisar el tráfico hacia los dominios *.cursor.sh, detectar patrones sensibles en las solicitudes salientes y bloquear o alertar sobre infracciones de las políticas.

El DLP de red puede afectar al rendimiento. Consulte Configuración de red para conocer las consideraciones sobre proxies.

DLP basado en hooks

Usa la función de hooks de Cherri Code para implementar lógica de DLP personalizada:

Antes de enviar instrucciones: Analiza las instrucciones en busca de patrones sensibles antes de enviarlas a los LLM:

#!/bin/bashinput=$(cat)prompt=$(echo "$input" | jq -r '.prompt')# Comprobar si hay claves de APIif echo "$prompt" | grep -qE 'api[_-]?key.*[A-Za-z0-9]{32}'; then    cat << EOF{  "continue": false,  "userMessage": "Prompt contains what looks like an API key. Remove it and try again."}EOF    exit 1fi# Permitir si no se detectan datos confidencialescat << EOF{  "continue": true}EOF

Después de generar código: Revise el código generado antes de escribirlo en el disco:

#!/bin/bashinput=$(cat)file_path=$(echo "$input" | jq -r '.file_path')edits=$(echo "$input" | jq -r '.edits[].new_string')# Comprueba si hay credenciales codificadasif echo "$edits" | grep -qE 'password.*=.*["\047][^"\047]+["\047]'; then    # Envía los datos a la API de DLP para analizarlos    curl -X POST "https://dlp.yourcompany.com/scan" \      -H "Content-Type: application/json" \      -d "{\"content\":\"$edits\",\"file\":\"$file_path\"}"        # Comprueba la respuesta de la API y actúa según correspondafi

Integración de DLP de terceros

Llame a la API de su proveedor de DLP actual desde los hooks:

#!/bin/bashinput=$(cat)content=$(echo "$input" | jq -r '.content')# Enviar a la API de DLPresponse=$(curl -s -X POST "https://dlp-api.company.com/analyze" \  -H "Authorization: Bearer $DLP_API_TOKEN" \  -H "Content-Type: application/json" \  -d "{\"text\":\"$content\"}")# Analizar la respuestais_allowed=$(echo "$response" | jq -r '.allowed')if [ "$is_allowed" = "true" ]; then    cat << EOF{  "permission": "allow"}EOFelse    violation=$(echo "$response" | jq -r '.violation_type')    cat << EOF{  "permission": "deny",  "userMessage": "Content blocked by DLP policy: $violation"}EOFfi

Este enfoque le permite gestionar de forma centralizada las políticas de DLP en todas las herramientas de desarrollo.

Flujos de trabajo de aprobación

Puedes configurar Cherri Code para que solicite aprobación para cada acción del agente de programación. Los usuarios pueden configurar su agente de programación para que siempre pida aprobación antes de leer o editar archivos, ejecutar comandos de terminal o realizar solicitudes de red.

Sin embargo, este enfoque ralentiza considerablemente el desarrollo. Los agentes de programación necesitan realizar varias acciones para completar tareas, y exigir aprobación para cada una hace que el flujo de trabajo sea tedioso. En su lugar, la mayoría de los equipos optan por usar hooks para bloquear automáticamente operaciones peligrosas.

Seguridad de los proveedores de modelos

Todos los proveedores de modelos (OpenAI, Anthropic, Google, SpaceXAI) implementan sistemas de seguridad que filtran contenido dañino. Estos sistemas rechazan instrucciones que solicitan información dañina, se niegan a generar código peligroso y filtran las salidas por motivos de seguridad.

Cherri Code trabaja con los proveedores para garantizar que los modelos cumplan los estándares de seguridad antes de ponerlos a disposición de los usuarios. Los proveedores evalúan continuamente los modelos para detectar problemas de seguridad. Sin embargo, no constituyen límites de seguridad. Los sistemas de seguridad pueden eludirse o engañarse. Implemente siempre sus propios controles mediante hooks y políticas de acceso.

Consideraciones sobre el aislamiento

De forma predeterminada, los agentes de programación de Cherri Code se ejecutan en tu máquina local. Pueden leer los archivos que puedes leer, escribir los archivos que puedes escribir, ejecutar los comandos que puedes ejecutar y acceder a los recursos de red a los que puedes acceder.

No hay ningún límite de seguridad entre los agentes de programación y tu cuenta de usuario. Si tu cuenta puede eliminar archivos, los agentes de programación también pueden eliminarlos (con aprobación de forma predeterminada).

Opciones de aislamiento

Si necesita mayor aislamiento, ejecute Cherri Code en una VM independiente mediante agentes en la nube, use permisos del sistema de archivos para limitar a qué puede acceder el proceso de Cherri Code o ejecute Cherri Code en una máquina de desarrollo dedicada con acceso limitado a sistemas de producción.

Para la mayoría de las empresas, los requisitos de aprobación y los hooks integrados proporcionan suficiente control.

Permisos del sistema de archivos

Como medida de protección adicional, usa los permisos del sistema de archivos para proteger archivos confidenciales:

Restringe el acceso a archivos secretos:

# Permitir que solo usuarios específicos puedan leer los secretoschmod 600 .envchown app-user:app-user .env# O usar directorios independientes con acceso restringidochmod 700 /etc/app/secrets

Repositorios sensibles independientes: Mantén el código altamente sensible en repositorios independientes con acceso restringido. No clones estos repositorios en máquinas donde se ejecute Cherri Code.

Sistemas de archivos cifrados: Para datos muy sensibles, usa sistemas de archivos cifrados que requieran montarse explícitamente. No montes estos sistemas de archivos en directorios a los que Cherri Code tenga acceso.

Orientación del LLM

Los controles de seguridad bloquean acciones perjudiciales después de que el LLM las sugiera. Los mecanismos de orientación guían al LLM para que haga mejores sugerencias desde el principio. No son deterministas: mejoran los resultados, pero no garantizan su prevención.

Reglas

Las reglas añaden instrucciones a la ventana de contexto del LLM antes de cada solicitud. Usa reglas para establecer estándares de código, aplicar patrones arquitectónicos, definir requisitos de seguridad o establecer convenciones específicas del proyecto.

Las reglas funcionan en tres ámbitos:

Reglas de usuario: Se aplican a todos los proyectos de un usuario específico. Úsalas para preferencias personales, como el estilo de código o las bibliotecas preferidas.

Reglas del proyecto: Se aplican a todas las personas que trabajan en un proyecto. Úsalas para estándares específicos del proyecto, como convenciones de nomenclatura o el uso de frameworks.

Reglas del equipo: Se aplican a todos los proyectos de tu organización. Úsalas para estándares de toda la empresa, como requisitos de seguridad o reglas de cumplimiento.

El LLM ve todas las reglas aplicables al generar respuestas. Intentará seguirlas, pero las reglas son sugerencias, no garantías. Combina las reglas con hooks de cumplimiento para requisitos que deban cumplirse.

Consulta Reglas para ver la configuración y ejemplos.

Comandos y flujos de trabajo

Los comandos agrupan instrucciones reutilizables que los agentes de programación pueden invocar mediante comandos con barra como /test o /deploy. Ayudan a estandarizar flujos de trabajo comunes en tu equipo.

Flujos de trabajo: Crea procesos de varios pasos que guíen a los agentes de programación en tareas complejas. Por ejemplo, un comando /security-review podría indicar al agente que busque inyecciones SQL, compruebe si hay secretos expuestos, valide la sanitización de las entradas y genere un informe de seguridad.

Bibliotecas de instrucciones: Crea una colección de instrucciones probadas para tareas comunes. Esto reduce la variación en el comportamiento de los agentes de programación y recoge el conocimiento institucional.

Los comandos pueden aplicarse a equipos, proyectos o usuarios. Los administradores de equipo pueden crear comandos para toda la organización que estén disponibles para todos los desarrolladores.

Consulta Comandos para ver la configuración y ejemplos.

Enriquecimiento del contexto con MCP

Los servidores de Model Context Protocol (MCP) permiten a los agentes de programación acceder a fuentes de datos externas. Use MCP para incorporar documentación de la empresa, consultar API internas, acceder a bases de conocimiento o integrarse con herramientas de desarrollo.

Los MCP enriquecen el contexto del agente de programación con información a la que de otro modo no tendría acceso. Por ejemplo, un MCP podría proporcionar acceso a las especificaciones de su API, para que los agentes de programación generen código que llame correctamente a sus servicios internos.

Los MCP se asignan a equipos o usuarios. A diferencia de los hooks, los MCP no aplican políticas; proporcionan información que ayuda a los agentes de programación a tomar mejores decisiones.

Consulte Integración de MCP para ver la configuración y ejemplos.