Skip to main content
Os perfis de segurança permitem definir conjuntos reutilizáveis de restrições de segurança — acesso à rede, acesso ao MCP, acesso ao git e credenciais da CLI do GitHub — e aplicá-los às sessões do Devin em toda a sua organização. Em vez de configurar restrições sessão por sessão, administradores criam perfis nomeados uma única vez e os associam no nível mais adequado: como padrão para toda a organização, em uma automação específica ou em uma sessão individual. Contas Enterprise também podem compartilhar perfis entre todas as organizações e impô-los como um limite mínimo rígido que ninguém nos níveis abaixo pode flexibilizar.

​
Restrições em um perfil

Um perfil é um conjunto nomeado de restrições. Cada restrição é opcional — um perfil limita apenas as configurações que define.

​
Política de rede

Uma política de rede é uma lista de permissões de destinos que a máquina da sessão pode acessar. Todas as outras conexões de saída são bloqueadas. As entradas da lista de permissões podem ser:
  • Hostnames, com curingas * (por exemplo, *.github.com, registry.npmjs.org). Um * corresponde a qualquer sequência de caracteres, incluindo pontos.
  • Faixas CIDR IPv4 / IPv6 (por exemplo, 10.0.0.0/8).
A restrição se aplica a todo o acesso à rede da sessão — comandos de shell, navegação, instalação de pacotes e scripts. Devin sabe quando está operando com uma política de rede restrita: ele consegue ver a lista de permissões atual e, quando é bloqueado por um destino que não está nela, solicita acesso. Aprovar a requisição adiciona o destino a essa sessão (sujeito a qualquer envelope obrigatório — consulte aplicação). Os destinos necessários para Devin funcionar (como o proxy git usado para acessar seus repositórios conectados) são permitidos automaticamente.

​
Acesso a MCP

Por padrão, as sessões podem usar qualquer servidor MCP instalado na sua organização. Um perfil pode restringir isso com uma lista de permissões de servidores MCP — as sessões abrangidas pelo perfil só podem usar os servidores listados.
O acesso a MCP é gerenciado independentemente da política de rede: você não precisa adicionar o endereço de um servidor MCP à lista de permissões da rede. Os servidores permitidos pelo perfil ficam acessíveis automaticamente, e os servidores excluídos pelo perfil permanecem indisponíveis, independentemente da política de rede.

​
Acesso ao Devin MCP

As sessões também têm acesso às ferramentas de gerenciamento do próprio Devin por meio do Devin MCP nativo — criar sessões filhas e enviar mensagens para elas, editar o Knowledge e playbooks, gerenciar agendamentos e assim por diante. Um perfil pode restringir esse escopo com Devin MCP somente leitura: as sessões controladas pelo perfil ainda podem ler recursos do Devin (listar sessões, consultar o Knowledge, inspecionar playbooks), mas não podem realizar operações de gravação, como criar sessões ou editar o Knowledge.

​
Nível de acesso Git

Controla o que a sessão pode fazer com seus repositórios conectados:

​
Token da CLI do GitHub

Além das operações básicas do Git abrangidas pelo nível de acesso Git, a máquina do Devin pode ter um token da CLI do GitHub (gh) que permite ao Devin usar recursos do GitHub diretamente pela API do GitHub. Um perfil pode remover o token da CLI do GitHub da máquina: as sessões regidas pelo perfil continuam funcionando com seus repositórios por meio da integração Git do Devin, mas não podem fazer chamadas diretas à API do GitHub. Um perfil só pode manter o token se também conceder acesso Git Completo e, caso defina uma política de rede, permitir api.github.com. Ambas as condições são verificadas quando você salva o perfil.

​
Onde os perfis ficam

Os perfis existem em dois escopos:
  • Perfis de organização são criados em Configurações → Personalização → Perfis de segurança e podem ser usados somente nessa organização.
  • Perfis do Enterprise (somente para contas Enterprise) são criados em Configurações do Enterprise → Devin → Perfis de segurança e podem ser usados por qualquer organização no Enterprise. As organizações podem selecionar um perfil do Enterprise para suas sessões, automações ou org default, mas somente admins do Enterprise podem editar o próprio perfil.
Os nomes dos perfis devem ser exclusivos dentro do respectivo escopo. Cada perfil também tem um nível de aplicação que determina se níveis inferiores podem substituí-lo.

​
Ao que um perfil pode ser vinculado

Um perfil passa a valer quando é vinculado a um recurso. Os vínculos seguem uma hierarquia, do mais amplo ao mais específico:
  1. Padrão do Enterprise — aplica-se a novas sessões em todas as organizações do Enterprise.
  2. Padrão da organização — aplica-se a novas sessões nessa organização.
  3. Padrão das automações — aplica-se a sessões iniciadas por automações nessa organização, substituindo o padrão da organização para essas sessões. Definido na mesma página de configurações de security-profiles.
  4. Automação — aplica-se a sessões iniciadas por essa automação específica, substituindo o padrão das automações. Definido no editor da automação.
  5. Sessão — escolhido para uma sessão individual quando ela é criada (pelo menu de opções na caixa de início da sessão) ou alterado depois nas configurações da sessão.
Em cada nível, você pode fazer uma de três escolhas:
  • Herdar (o padrão) — sem definir preferência; o nível acima decide.
  • Fixar um perfil — as sessões nesse nível usam o perfil selecionado.
  • Sem perfil — desativa explicitamente o uso de perfil, para que as sessões nesse nível sejam executadas sem restrições, mesmo que um nível acima defina um padrão recomendado.
Quando uma sessão é iniciada, Devin percorre a hierarquia de cima para baixo: o vínculo mais específico prevalece, a menos que um perfil obrigatório em um nível superior imponha restrições (veja abaixo). Sessões geradas por outras sessões (sessões filhas) seguem a mesma cadeia da sessão pai, portanto não é possível contornar as restrições delegando trabalho.

​
Quando as alterações entram em vigor

Uma sessão resolve o perfil que a rege nos momentos em que é iniciada: quando é criada pela primeira vez e sempre que sai do estado de inatividade ou reinicia. Edições no conteúdo de um perfil ou em qualquer binding (um padrão, um pin de automação ou uma seleção de sessão) não são propagadas automaticamente para sessões que já estão em execução — uma sessão em execução mantém as restrições que resolveu na última vez em que foi reativada. As alterações entram em vigor imediatamente para novas sessões e, para as sessões existentes, na próxima vez que forem retomadas. Todo perfil tem um nível de aplicação: Um perfil recomendado é o padrão, não uma exigência. Qualquer pessoa (com a permissão apropriada) em um nível inferior pode fixar um perfil diferente ou simplesmente não usar nenhum. Use perfis recomendados para dar às equipes um ponto de partida sensato, preservando a flexibilidade.

​
Obrigatório

Um perfil obrigatório é um patamar mínimo que os níveis inferiores não podem contornar:
  • Optar por não usar não tem efeito. Uma seleção de “nenhum perfil” abaixo de um perfil obrigatório é ignorada.
  • Seleções de níveis inferiores só podem restringir mais, nunca flexibilizar. Se um nível inferior fixa outro perfil, é feita a interseção entre os dois:
    • As listas de permissões de rede ficam restritas aos destinos permitidos por ambos os perfis.
    • As listas de permissões de MCP ficam restritas aos servidores permitidos por ambos.
    • O acesso ao Git assume o mínimo (somente leitura prevalece sobre acesso total).
    • O acesso ao Devin MCP será somente leitura se qualquer um dos perfis definir somente leitura.
    • O token da CLI do GitHub é removido se qualquer um dos perfis o remover.
  • Alterações durante a sessão são limitadas. O acesso à rede concedido durante uma sessão (por exemplo, ao aprovar a requisição do Devin para um novo domínio) sofre interseção com a política do perfil obrigatório, de modo que uma sessão nunca possa receber acesso além do que o perfil obrigatório permite.
Por exemplo, uma Enterprise pode vincular um perfil obrigatório a uma política de rede que permite *.internal.example.com como padrão do Enterprise. As organizações podem então adicionar seus próprios perfis por cima para restringir ainda mais equipes ou fluxos de trabalho específicos — mas nenhuma organização, automação ou sessão pode ampliar o acesso além da política da Enterprise.

​
Permissões e governança

O gerenciamento de perfis é controlado por uma permissão dedicada de Gerenciar perfis de segurança, separada do gerenciamento geral das configurações. Ela existe em dois níveis, cada um concedido de forma independente: Ambos os níveis dessa permissão podem ser concedidos a funções personalizadas, para que você possa delegar o gerenciamento da política de segurança (por exemplo, para uma equipe de segurança) sem conceder privilégios completos de admin. Membros sem essa permissão não podem listar, selecionar nem alterar perfis — as sessões deles simplesmente seguem o padrão determinado — mas qualquer pessoa pode ver se sua sessão é governada por um perfil e qual acesso à rede ela tem.

​
Configurando perfis de segurança

  1. Crie um perfil. Vá para Configurações → Personalização → Perfis de segurança (ou Configurações do Enterprise → Devin → Perfis de segurança para um perfil aplicado em todo o Enterprise), crie um perfil e configure suas configurações de segurança e nível de aplicação.
  2. Defina um padrão. Vincule o perfil como padrão da sua organização (ou padrão do Enterprise) para que novas sessões o usem automaticamente.
  3. Fixe onde necessário. Aplique um override ao padrão em automações específicas — por exemplo, um perfil mais restritivo para uma automação que acessa sistemas sensíveis — ou em sessões individuais no momento da criação.
  4. Aumente as restrições ao longo do tempo. Comece com um perfil recomendado para observar o impacto e depois torne-o obrigatório quando suas listas de permissões cobrirem as necessidades legítimas das suas Teams.

​
Automações e perfis

As automações podem ter sua própria política de rede e seleção de MCP. Elas são camadas que apenas restringem o perfil principal — as sessões iniciadas pela automação só têm acesso a destinos de rede e servidores MCP permitidos pela automação e pelo perfil. Portanto, uma automação nunca pode ampliar o acesso do perfil. A camada de automação é determinada em tempo real a cada inicialização e reativação de sessão. Portanto, editar a política de rede de uma automação entra em vigor sem recriar as sessões.

​
Outposts e perfis

As sessões executadas no Devin Outposts determinam o perfil que rege pela mesma cadeia de associação usada pelas sessões em nuvem, e as restrições aplicadas pelo Devin na nuvem — a lista de permissões do MCP, o acesso somente leitura ao Devin MCP, o nível de acesso Git e a remoção do token da CLI do GitHub — aplicam-se às sessões de outpost exatamente como às sessões em nuvem. A política de rede é diferente. O Devin aplica a lista de permissões de rede de uma sessão no nível da máquina em VMs gerenciadas pelo Devin, mas um worker de outpost é executado em uma infraestrutura operada por você, portanto o Devin não instala regras de firewall nas suas máquinas. Em vez disso, a política de rede efetiva de cada sessão enfileirada é publicada para seu orquestrador na API do Outposts como spec.network_policy (se a política está ativada, além dos hostnames e CIDRs permitidos). A aplicação dessa política — por exemplo, com um proxy de saída por sessão, uma NetworkPolicy do Kubernetes ou regras de firewall da VM — é responsabilidade do operador do outpost. O Devin ainda vê a lista de permissões e solicita acesso a destinos não permitidos como de costume, mas aprovar uma requisição apenas atualiza a política da sessão no Devin; isso não altera sua rede por si só. spec.network_policy é capturada quando a sessão é enfileirada para um outpost e atualizada quando ela é reenfileirada (por exemplo, depois que a sessão entra em suspensão e é reativada). Portanto, leia-a novamente na API em vez de presumir que ela é estática.
Se você depender da política de rede de um perfil obrigatório como um limite rígido, verifique se sua infraestrutura de outpost aplica spec.network_policy a todas as sessões que executa. Sem isso, as sessões em outposts terão o mesmo acesso à rede que suas máquinas tiverem.