Secretos y red
Los agentes en la nube están disponibles en modo de privacidad. Nunca entrenamos con tu código y solo conservamos el código mientras el agente se ejecuta. Más información sobre el modo de privacidad.
Para conocer cómo se diseñan y protegen los agentes en la nube, incluido el ciclo de vida de la ejecución, el modelo de acceso, el aislamiento, el cifrado y el manejo de datos, consulta el Resumen de seguridad. Esta página es la referencia de configuración de los controles que describe.
Modo de privacidad (heredado) no es compatible. El modo de privacidad heredado bloquea el almacenamiento de datos en la nube, y los agentes en la nube necesitan almacenar datos de código y del entorno en la nube mientras se ejecutan. Cambia al modo de privacidad desde Panel de control → agentes en la nube antes de usar agentes en la nube.
Protección de secretos
Los secretos proporcionados a los agentes en la nube se cifran tanto en reposo como en tránsito. No son visibles para nadie más que el usuario del agente en la nube.
Los secretos se pueden configurar como variables de entorno, secretos de tiempo de ejecución o secretos de compilación.
Variables de entorno
Los secretos configurados con el tipo Environment Variable son visibles para el agente en la nube. Se recomienda usarlos para configuraciones no confidenciales que el agente pueda consultar, como flags o URL públicas. Siguen cifrados en reposo y en tránsito, al igual que otros tipos de secretos.
Secretos de tiempo de ejecución
Anteriormente, los secretos de tiempo de ejecución se llamaban secretos censurados.
Los secretos configurados con el tipo Runtime Secret siguen cargándose como variables de entorno, pero su contenido se censura en los resultados de las llamadas a herramientas del agente, la transcripción del chat, los commits y los mensajes de commit, y se sustituye por la cadena de marcador de posición [REDACTED]. Son ideales para credenciales sensibles que no deben exponerse al agente ni confirmarse nunca en el repositorio.
Aunque los secretos de tiempo de ejecución siguen funcionando internamente como variables de entorno y no se muestran al agente, los usuarios que interactúan con el entorno del agente mediante la Terminal pueden seguir viéndolos.
Secretos de compilación
Los secretos configurados con el tipo Build Secret solo están disponibles para el proceso de compilación de Docker (si has configurado uno) y no se exponen al entorno del agente en ejecución. Son ideales para registros de paquetes privados o credenciales de compilación que no deben exponerse al agente.
Para usar de forma segura un Build Secret en tu Dockerfile, haz referencia a él desde un paso RUN mediante un montaje de secretos de Docker, por ejemplo:
RUN --mount=type=secret,id=MY_TOKEN,env=MY_TOKEN,required=true \ ./scripts/install-private-deps.shTokens de identidad OIDC
Para roles en la nube y API internas, usa preferentemente tokens OIDC de corta duración en lugar de claves de larga duración en Secretos. Un agente en la nube puede emitir un JWT firmado por Cherri Code a través de un socket local y presentarlo a AWS, GCP, Azure, Vault o cualquier verificador OIDC.
Commits firmados
Los agentes en la nube firman cada commit con una clave Ed25519 respaldada por un HSM. En GitHub y GitLab, estos commits muestran una insignia de «Verificado» para que tu equipo pueda confirmar que provienen de Cherri Code.
Esta función se aplica automáticamente a todos los agentes en la nube. No requiere configuración.
Si tu repositorio aplica reglas de protección de ramas que exigen commits firmados, las PR de los agentes en la nube cumplen esos requisitos sin configuración adicional.
Ámbitos de Git protegidos
Los administradores de equipo pueden restringir una organización de Git a su organización de Cherri Code para que solo sus equipos puedan iniciar agentes en la nube en sus repositorios. Consulte Ámbitos de Git protegidos.
Lo que debes saber
- Otorga permisos de lectura y escritura a nuestra aplicación de GitHub para los repositorios que quieras editar. Los usamos para clonar el repositorio y realizar cambios.
- Tu código se ejecuta en nuestra infraestructura de AWS, en VM aisladas, y se almacena en los discos de las VM mientras el agente está disponible.
- El agente tiene acceso a Internet de forma predeterminada. Puedes configurar controles de egreso de red para usuarios, equipos y entornos guardados a fin de restringir los dominios a los que puede acceder el agente.
- El agente ejecuta automáticamente todos los comandos de terminal, lo que le permite iterar con las pruebas. Esto difiere del agente en primer plano, que requiere la aprobación del usuario para cada comando. La ejecución automática conlleva un riesgo de exfiltración de datos: los atacantes podrían ejecutar ataques de inyección de prompts y engañar al agente para que suba código a sitios web maliciosos. Consulta la explicación de OpenAI sobre los riesgos de la inyección de prompts para agentes en la nube.
- Si el modo de privacidad está desactivado, recopilamos instrucciones y entornos de desarrollo para mejorar el producto.
- Si desactivas el modo de privacidad al iniciar un agente en la nube y luego lo activas durante su ejecución, el agente seguirá con el modo de privacidad desactivado hasta que termine.
Retención de datos
Los agentes en la nube almacenan dos tipos de datos en cada ejecución:
- Historial de conversación. Las instrucciones, respuestas del modelo, llamadas a herramientas y artefactos de demostración que conforman la transcripción del agente. Son los datos que ve al abrir un agente en la web o desde un cliente de escritorio.
- Instantáneas del entorno. Copias cifradas del disco de la máquina virtual en un momento determinado. Las instantáneas permiten personalizar los entornos de las VM y que los agentes se inicien o reanuden sin tener que volver a clonar el repositorio ni ejecutar de nuevo la configuración.
El historial de conversación se conserva indefinidamente de forma predeterminada para que pueda revisar y reanudar ejecuciones anteriores. Las instantáneas del entorno se almacenan durante un máximo de 90 días de inactividad. Cada vez que un agente se inicia o se reanuda desde una instantánea, su vencimiento se prorroga otros 90 días. Cuando una instantánea lleva 90 días sin usarse, se elimina automáticamente, independientemente del plan o la política.
Puede usar la Delete Agent API para eliminar explícitamente el historial de conversación de un agente en la nube. Este endpoint elimina la transcripción de la conversación y sus artefactos. No elimina las instantáneas del entorno, que no se pueden eliminar bajo demanda, sino que siguen el período de retención indicado anteriormente.
Políticas de retención de agente en la nube
Las ventanas de retención personalizadas están disponibles con acceso anticipado para determinados equipos Enterprise. Contacta con ventas para solicitar acceso.
Los administradores de equipos Enterprise pueden limitar durante cuánto tiempo se conservan los datos del agente en la nube del equipo desde Configuración del equipo en el Panel de control de agentes en la nube. Las opciones disponibles son Indefinida y 90 días.
Al establecer la política en 90 días:
- Un proceso en segundo plano elimina las conversaciones que superan el periodo de retención.
- Las instantáneas del entorno siguen rigiéndose por la ventana móvil de inactividad de 90 días descrita anteriormente.
- La política se aplica a todas las ejecuciones de agentes del equipo, incluidas las ejecuciones desde entornos guardados y la API.
Al volver a Indefinida, se detienen las eliminaciones posteriores de conversaciones, pero no se restauran los datos que ya se han eliminado.
Acceso de red
Controla a qué recursos de red pueden acceder tus agentes en la nube. Estos ajustes están disponibles en el Panel de control de Cloud Agents para usuarios individuales, entornos guardados y administradores de equipo.
Acceso a redes privadas
Los agentes en la nube no necesitan ejecutarse en tu hardware para acceder a recursos privados. Para servicios en una VPC o intranet, usa las redes en espacio de usuario de Tailscale, Cloudflare Tunnel o un cliente de red privada similar en el entorno del agente en la nube. Consulta Ejecutar Tailscale y Ejecutar Cloudflare Tunnel para ver notas de configuración.
Con Tailscale o Cloudflare Tunnel, tus servicios privados no necesitan aceptar tráfico entrante desde la internet pública. El agente se conecta mediante una ruta de red autenticada, mientras el servicio permanece en tu red privada.
Cloudflare Tunnel es una buena opción cuando el agente puede acceder al servicio privado mediante un nombre de host HTTPS autenticado. Un conector de tu red establece una conexión saliente con Cloudflare, y el agente en la nube accede a ese nombre de host como a cualquier otra URL externa. Puedes proteger el nombre de host con tokens de servicio de Cloudflare Access, almacenar los valores de los tokens como secretos de Cherri Code y añadir el nombre de host a la lista de permitidos de tu agente en la nube.
Para destinos TCP, como bases de datos privadas, usa un cliente de túnel que exponga un puerto de escucha TCP local en el entorno del agente. Luego, el agente se conecta a localhost, mientras el túnel reenvía el tráfico al origen privado.
Para GitHub Enterprise Server privado, GitLab Enterprise, API de control de código fuente, registros de paquetes como Artifactory o Nexus y el tráfico de webhook relacionado, los equipos Enterprise pueden usar la conectividad privada con AWS PrivateLink o Cloudflare Tunnel.
Modos de acceso
Tres modos controlan el acceso de red saliente de los agentes en la nube:
| Modo | Comportamiento |
|---|---|
| Permitir todo el acceso de red | Los agentes en la nube pueden conectarse a cualquier host externo. No se aplican restricciones de dominio. |
| Predeterminado + lista de permitidos | Los agentes en la nube pueden acceder a los dominios predeterminados y a cualquier dominio que añadas a tu lista de permitidos. |
| Solo lista de permitidos | Los agentes en la nube solo pueden acceder a los dominios que añadas explícitamente a tu lista de permitidos. |
Incluso en el modo Solo lista de permitidos, un pequeño conjunto de dominios sigue siendo accesible para que los agentes en la nube puedan funcionar. Entre ellos se incluyen los servicios propios de Cherri Code y los proveedores de gestión de control de código fuente (SCM).
Carga de artefactos
Los agentes en la nube cargan artefactos (capturas de pantalla, vídeos y referencias a registros mostradas en las PR) en cloud-agent-artifacts.s3.us-east-1.amazonaws.com.
Si usas Predeterminado + lista de permitidos o Solo lista de permitidos, añade el host exacto a tu lista de permitidos para que la carga de artefactos se realice correctamente. No amplíes la entrada a *.s3.us-east-1.amazonaws.com: el comodín permite el tráfico saliente a todos los buckets de la región y crea una vía de exfiltración para un agente afectado por una inyección de instrucciones. Bloquear el host desactiva las cargas; las sesiones del agente y las demás llamadas a herramientas seguirán funcionando.
Ajustes de usuario
Cada usuario puede configurar su modo de acceso de red en el Panel de control de agentes en la nube, en la sección Seguridad. Este ajuste se aplica a todos los agentes en la nube que crees.
Al seleccionar un modo que incluye una lista de permitidos (Predeterminado + lista de permitidos o Solo lista de permitidos), aparecerá debajo del ajuste una sección para configurar la lista de permitidos, donde podrás añadir dominios personalizados.
Ajustes a nivel de entorno
Los entornos guardados pueden tener su propio modo de acceso de red y lista de permitidos. Usa ajustes a nivel de entorno cuando un repo o grupo de repos requiera un acceso saliente más restrictivo que el resto de tu equipo.
Por ejemplo, puedes mantener un entorno próximo a producción en Solo lista de permitidos y dejar un entorno menos sensible en Predeterminado + lista de permitidos. Los agentes de programación que usan el entorno más restrictivo heredan esas restricciones.
Los ajustes a nivel de entorno incluyen dos opciones de herencia:
| Modo | Comportamiento |
|---|---|
| Heredar ajustes | Usa el ajuste de acceso de red aplicable del usuario o equipo. |
| Heredar ajustes + lista de permitidos del entorno | Usa el ajuste aplicable del usuario o equipo y añade los dominios de la lista de permitidos del entorno. |
También puedes establecer directamente un entorno en Permitir todo el acceso de red, Predeterminado + lista de permitidos o Solo lista de permitidos.
Ajustes de equipo
Los administradores de equipo pueden establecer un modo de acceso de red predeterminado para todo el equipo desde el mismo panel de control. La lista de permitidos a nivel de equipo es la misma que los administradores configuran para la lista de permitidos de red predeterminada del sandbox. No hay una lista de permitidos independiente que gestionar; una sola lista controla tanto el acceso de red del agente en la nube como los valores predeterminados del sandbox.
Cuando existe un ajuste de equipo:
- Si un entorno define su propio modo, el ajuste del entorno se aplica a los agentes de programación que usan ese entorno.
- Si un entorno hereda ajustes y un usuario ha configurado su propio ajuste, el ajuste del usuario tiene prioridad.
- Si ni el entorno ni el usuario han configurado un ajuste, se aplica el valor predeterminado del equipo.
Bloquear la configuración (Enterprise)
El bloqueo solo está disponible para equipos Enterprise.
Los administradores de equipos Enterprise pueden bloquear la configuración de acceso de red mediante la opción Bloquear política de acceso de red. Al bloquearla:
- La configuración a nivel de equipo se aplica a todos los miembros, independientemente de sus preferencias individuales.
- Los usuarios no pueden anular la configuración bloqueada desde su propio panel de control.
Esto otorga a los administradores control total sobre el acceso de red de los agentes en la nube en toda la organización.
Relación con la política de red del sandbox
Los dominios "Predeterminados" del modo Predeterminado + lista de permitidos corresponden a la misma lista de permitidos de red predeterminada que usa el sandbox del Agent de escritorio. La lista de permitidos a nivel de equipo también es compartida: cuando un administrador configura una lista de permitidos en el panel de control, se aplica tanto al acceso de red del agente en la nube como a la política de red del sandbox.
Rangos de IP de salida
Los agentes en la nube se conectan desde rangos de direcciones IP específicos al acceder a servicios externos, API o repositorios.
Endpoint de la API
Los rangos de IP están disponibles a través de un endpoint de API JSON:
curl /docs/ips.jsonFormato de respuesta
{ "version": 1, "modified": "2025-09-24T16:00:00.000Z", "cloudAgents": { "us3p": ["100.26.13.169/32", "34.195.201.10/32", "..."], "us4p": ["54.184.235.255/32", "35.167.37.158/32", "..."], "us5p": ["3.12.82.200/32", "52.14.104.140/32", "..."] }, "gitEgressProxy": ["184.73.225.134/32", "3.209.66.12/32", "52.44.113.131/32"]}- version: Número de versión del esquema de la respuesta de la API
- modified: Marca de tiempo ISO 8601 de la última actualización de los rangos de IP
- cloudAgents: Objeto que contiene rangos de IP, indexados por clúster
- gitEgressProxy: Direcciones IP utilizadas por el proxy de salida de git
Rangos de IP publicados en notación CIDR. Si es necesario, puedes usar una herramienta de conversión en línea para convertir la notación CIDR en rangos de direcciones IP.
Uso de los rangos de IP
Los agentes en la nube pueden usar estos rangos de IP publicados para:
- Clonar repositorios remotos y hacer push a ellos (a menos que se use el proxy de salida de Git)
- Descargar paquetes y dependencias
- Realizar llamadas a la API de servicios externos
- Acceder a recursos web durante la ejecución del agente de programación
Si su organización utiliza reglas de firewall o listas de permitidos de IP para controlar el acceso de red, es posible que deba incluir estos rangos de IP en la lista de permitidos para garantizar que los agentes en la nube puedan acceder correctamente a sus servicios.
Consideraciones importantes:
- Realizamos cambios en nuestras direcciones IP periódicamente por necesidades operativas y de escalado.
- No recomendamos usar listas de permitidos de direcciones IP como mecanismo de seguridad principal.
- Si debe usar estos rangos de IP, le recomendamos encarecidamente supervisar periódicamente el endpoint de la API JSON.
Proxy de salida de Git y lista de IP permitidas
Cherri Code admite una función similar, pero distinta, a usar un proxy de salida de Git para listas de IP permitidas. Este proxy enruta todo el tráfico de Git a través de un conjunto más reducido de direcciones IP y funciona con todos los hosts de Git, incluidos GitHub, GitLab, Azure DevOps y Bitbucket.
Para los hosts de Git, recomendamos la configuración de lista de IP permitidas descrita en el enlace anterior, ya que se integra directamente con la aplicación de GitHub de Cherri Code.
Si necesitas añadir las direcciones IP del proxy directamente a una lista de permitidos, usa estas direcciones:
184.73.225.1343.209.66.1252.44.113.131IPs de Origin
Si tu equipo usa agentes en la nube junto con Origin, añade estas IP adicionales a la lista de permitidos, además de las IP del proxy de salida de Git indicadas anteriormente:
34.192.39.18250.16.106.25544.217.29.1243.223.245.20154.164.185.1034.194.133.2335.170.116.221Estas direcciones IP son estables. Si la lista cambia, los equipos que usan listas de IP permitidas recibirán un aviso con antelación antes de que se añada o elimine alguna dirección.
Los clientes Enterprise con implementaciones privadas de GitHub Enterprise Server o GitLab Enterprise pueden usar opciones de conectividad privada para que los agentes en la nube y Bugbot puedan acceder a sistemas privados de control de código fuente.