Skip to main content
Los perfiles de seguridad te permiten definir conjuntos reutilizables de restricciones de seguridad — acceso a la red, acceso a MCP, acceso a git y credenciales de GitHub CLI — y aplicarlos a las sesiones de Devin en toda tu organización. En lugar de configurar las restricciones sesión por sesión, los Admin crean perfiles con nombre una sola vez y los asignan en el nivel que tenga sentido: como valor predeterminado para toda la organización, en una automatización específica o en una sesión individual. Las cuentas Enterprise también pueden compartir perfiles entre todas las organizaciones y aplicarlos como un mínimo obligatorio que nadie por debajo puede relajar.

​
Restricciones en un perfil

Un perfil es un conjunto de restricciones con nombre. Cada restricción es opcional: un perfil solo limita la configuración que define.

​
Política de red

Una política de red es una lista de destinos permitidos a los que la máquina de la sesión puede acceder. Todas las demás conexiones salientes se bloquean. Las entradas de la lista pueden ser:
  • Nombres de host, con comodines * (p. ej., *.github.com, registry.npmjs.org). Un * coincide con cualquier secuencia de caracteres, incluidos los puntos.
  • Rangos CIDR IPv4 / IPv6 (p. ej., 10.0.0.0/8).
La restricción se aplica a todo el acceso a la red desde la sesión: comandos de shell, navegación, instalación de paquetes y scripts por igual. Devin sabe cuándo se está ejecutando con una política de red restringida: puede ver la lista actual de destinos permitidos y, cuando se bloquea por la falta de un destino, solicitará acceso. Aprobar la solicitud agrega ese destino para esa sesión (sujeto a cualquier restricción obligatoria; consulta enforcement). Los destinos necesarios para que Devin funcione (como el proxy de git que se usa para acceder a tus repositorios conectados) se permiten automáticamente.

​
Acceso a MCP

De forma predeterminada, las sesiones pueden usar cualquier servidor MCP instalado en tu organización. Un perfil puede restringir esto con una lista de servidores MCP permitidos: las sesiones regidas por el perfil solo pueden usar los servidores incluidos en la lista.
El acceso a MCP se gestiona de forma independiente de la política de red: no necesitas agregar la dirección de un servidor MCP a la lista de direcciones permitidas de la red. Se puede acceder automáticamente a los servidores permitidos por el perfil, y los servidores excluidos por el perfil seguirán sin poder usarse independientemente de la política de red.

​
Acceso a Devin MCP

Las sesiones también tienen acceso a las propias herramientas de gestión de Devin a través del Devin MCP integrado: crear sesiones secundarias y enviarles mensajes, editar Knowledge y Playbooks, gestionar programaciones, etc. Un perfil puede restringir este alcance con Devin MCP de solo lectura: las sesiones sujetas al perfil pueden seguir leyendo recursos de Devin (listar sesiones, consultar Knowledge, inspeccionar Playbooks), pero no pueden realizar operaciones de escritura, como crear sesiones o editar Knowledge.

​
Nivel de acceso de Git

Controla lo que la sesión puede hacer con tus repositorios conectados:

​
Token de GitHub CLI

Además de las operaciones básicas de git permitidas por el nivel de acceso de git, la máquina de Devin puede tener un token de GitHub CLI (gh) que permite a Devin usar funciones de GitHub directamente a través de la API de GitHub. Un perfil puede eliminar el token de GitHub CLI de la máquina: las sesiones regidas por el perfil seguirán funcionando con tus repositorios mediante la integración de git de Devin, pero no podrán realizar llamadas directas a la API de GitHub. Un perfil solo puede conservar el token si también concede acceso de git completo y, si establece una política de red, permite api.github.com. Ambas condiciones se validan al guardar el perfil.

​
Dónde se encuentran los perfiles

Los perfiles existen en dos ámbitos:
  • Los perfiles de organización se crean en Settings → Customization → perfiles de seguridad y solo se pueden usar dentro de esa organización.
  • Los perfiles de Enterprise (solo para cuentas Enterprise) se crean en Settings de Enterprise → Devin → perfiles de seguridad y pueden ser utilizados por todas las organizaciones de Enterprise. Las organizaciones pueden seleccionar un perfil de Enterprise para sus sesiones, automatización o valor predeterminado de la org, pero solo los Admin de Enterprise pueden editar el perfil en sí.
Los nombres de los perfiles deben ser únicos dentro de su ámbito. Cada perfil también tiene un nivel de aplicación que determina si los niveles inferiores pueden anularlo.

​
A qué se puede vincular un perfil

Un perfil surte efecto al quedar vinculado a un recurso. Las vinculaciones forman una jerarquía, de la más general a la más específica:
  1. Predeterminado de Enterprise — se aplica a las sesiones nuevas de todas las organizaciones de Enterprise.
  2. Predeterminado de la organización — se aplica a las sesiones nuevas de esa organización.
  3. Predeterminado de automatizaciones — se aplica a las sesiones iniciadas por automatizaciones de esa organización, anulando el valor predeterminado de la organización para esas sesiones. Se configura desde la misma página de Settings de perfiles de seguridad.
  4. Automatización — se aplica a las sesiones iniciadas por esa automatización específica, anulando el valor predeterminado de automatizaciones. Se configura desde el editor de la automatización.
  5. Sesión — se elige para una sesión concreta al crearla (desde el menú de opciones en el cuadro de inicio de la sesión) o se cambia más adelante en Settings de la sesión.
En cada nivel puedes elegir una de estas tres opciones:
  • Heredar (lo predeterminado) — sin preferencia; decide el nivel superior.
  • Fijar un perfil — las sesiones de este nivel usan el perfil seleccionado.
  • Sin perfil — exclusión explícita, para que las sesiones de este nivel se ejecuten sin restricciones aunque un nivel superior establezca un valor predeterminado recomendado.
Cuando se inicia una sesión, Devin recorre la jerarquía de arriba abajo: prevalece la vinculación más específica, a menos que un perfil obligatorio en un nivel superior bloquee la configuración (consulta más abajo). Las sesiones creadas por otras sesiones (sesiones secundarias) se rigen por la misma cadena que su sesión principal, por lo que no es posible eludir las restricciones delegando trabajo.

​
Cuándo surten efecto los cambios

Una sesión resuelve qué perfil la rige en cada inicio: cuando se crea por primera vez y cada vez que sale de dormir o se reinicia. Los cambios en el contenido de un perfil o en cualquier vinculación (un valor predeterminado, una fijación de automatización o una selección de sesión) no se aplican automáticamente a las sesiones que ya están en ejecución: una sesión en ejecución conserva las restricciones que resolvió la última vez que salió de dormir. Los cambios surten efecto de inmediato en las sesiones nuevas y, en las existentes, la próxima vez que se reanuden. Cada perfil tiene un nivel de aplicación: Un perfil recomendado es la opción predeterminada, no una obligación. Cualquier persona (con el permiso adecuado) en un nivel inferior puede fijar un perfil diferente o no usar ninguno. Usa perfiles recomendados para dar a los equipos un punto de partida razonable sin perder flexibilidad.

​
Obligatorio

Un perfil obligatorio establece un mínimo del que los niveles inferiores no pueden salirse:
  • No optar por excluirse no tiene ningún efecto. Una selección de “sin perfil” por debajo de un perfil obligatorio se ignora.
  • Las selecciones de niveles inferiores solo pueden restringir más, nunca flexibilizar. Si un nivel inferior fija otro perfil, ambos se intersecan:
    • Las listas de permitidos de red se restringen a los destinos permitidos por ambos perfiles.
    • Las listas de permitidos de MCP se restringen a los servidores permitidos por ambos.
    • El acceso a Git toma el mínimo (solo lectura prevalece sobre acceso completo).
    • El acceso a Devin MCP es de solo lectura si alguno de los perfiles lo establece así.
    • El token de GitHub CLI se elimina si alguno de los perfiles lo elimina.
  • Los cambios a mitad de la sesión quedan limitados. El acceso de red concedido durante una sesión (p. ej., al aprobar la solicitud de Devin para un nuevo dominio) se interseca con la política del perfil obligatorio, por lo que nunca se puede conceder a una sesión acceso más allá de lo que permite el perfil obligatorio.
Por ejemplo, una cuenta Enterprise puede vincular un perfil obligatorio con una política de red que permita *.internal.example.com como valor predeterminado de Enterprise. Después, las organizaciones pueden superponer sus propios perfiles para restringir aún más equipos o workflows específicos, pero ninguna organización, automatización ni sesión puede ampliar el acceso más allá de la política de Enterprise.

​
Permisos y gobernanza

La gestión de perfiles se rige por un permiso específico de Gestionar perfiles de seguridad, independiente de la gestión general de Settings. Existe en dos niveles, y cada uno se concede por separado: Ambos niveles del permiso se pueden conceder a roles personalizados, para que puedas delegar la gestión de políticas de seguridad (por ejemplo, a un equipo de seguridad) sin conceder privilegios completos de Admin. Los miembros sin este permiso no pueden listar, seleccionar ni cambiar perfiles: sus sesiones simplemente siguen el valor predeterminado resuelto. Pero cualquiera puede ver si su sesión está regida por un perfil y qué acceso a la red tiene.

​
Configurar perfiles de seguridad

  1. Crea un perfil. Ve a Settings → Customization → perfiles de seguridad (o Settings de Enterprise → Devin → perfiles de seguridad para un perfil a nivel Enterprise), crea un perfil y configura sus ajustes de seguridad y nivel de aplicación.
  2. Establece un valor predeterminado. Vincula el perfil como predeterminado de tu organización (o predeterminado de Enterprise) para que las nuevas sesiones lo adopten automáticamente.
  3. Fíjalo donde sea necesario. Aplica una anulación del predeterminado en automatizaciones específicas — por ejemplo, un perfil más estricto para una automatización que accede a sistemas sensibles — o en sesiones individuales al crearlas.
  4. Refuérzalo con el tiempo. Comienza con un perfil recomendado para observar el impacto y luego cámbialo a obligatorio una vez que tus listas de permitidos cubran las necesidades legítimas de tus equipos.

​
Automatizaciones y perfiles

Las automatizaciones pueden tener su propia política de red y selección de MCP. Estas son capas que solo imponen restricciones sobre el perfil que las rige: las sesiones iniciadas por la automatización solo tienen acceso a los destinos de red y servidores MCP permitidos por ambos, la automatización y el perfil, por lo que una automatización nunca puede ampliar el acceso del perfil. La capa de automatización se resuelve en tiempo real cada vez que se inicia o reactiva una sesión, por lo que los cambios en la política de red de una automatización surten efecto sin necesidad de recrear sus sesiones.

​
Outposts y perfiles

Las sesiones que se ejecutan en Devin Outposts determinan el perfil que las rige mediante la misma cadena de vinculaciones que las sesiones en la nube, y las restricciones que Devin aplica desde su nube —la lista de permitidos de MCP, el modo de solo lectura de Devin MCP, el nivel de acceso de Git y la eliminación del token de GitHub CLI— se aplican a las sesiones de outpost exactamente igual que a las sesiones en la nube. La política de red es diferente. Devin aplica la lista de permitidos de red de una sesión a nivel de máquina en las VM gestionadas por Devin, pero un worker de outpost se ejecuta en infraestructura que tú gestionas, por lo que Devin no instala reglas de firewall en tus máquinas. En su lugar, la política de red efectiva de cada sesión en cola se publica en tu orquestador mediante la API de Outposts como spec.network_policy (si la política está habilitada, además de los nombres de host y CIDR permitidos). Aplicarla —por ejemplo, con un proxy de salida por sesión, una NetworkPolicy de Kubernetes o reglas de firewall de VM— es responsabilidad del operador del outpost. Devin sigue viendo la lista de permitidos y solicitando acceso a destinos no incluidos como de costumbre, pero aprobar una solicitud solo actualiza la política de la sesión en Devin; no modifica tu red por sí sola. spec.network_policy se captura cuando la sesión se pone en cola para un outpost y se actualiza cuando vuelve a ponerse en cola (por ejemplo, después de que la sesión se duerma y se reactive), así que vuelve a leerla desde la API en lugar de asumir que es estática.
Si dependes de la política de red de un perfil obligatorio como límite estricto, asegúrate de que tu infraestructura de outpost aplique spec.network_policy a todas las sesiones que atienda. De lo contrario, las sesiones en outposts tendrán el acceso de red que tengan tus máquinas.