> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Perfis de segurança

> Defina perfis de segurança reutilizáveis do Devin que restrinjam o acesso à rede, ao MCP, ao git e às credenciais da CLI do GitHub, e associe-os a orgs, automações e sessões.

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.

<div id="restrictions-in-a-profile">
  ## Restrições em um perfil
</div>

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

<div id="network-policy">
  ### Política de rede
</div>

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](#mandatory-vs-recommended-enforcement)).

Os destinos necessários para Devin funcionar (como o proxy git usado para acessar seus repositórios conectados) são permitidos automaticamente.

<div id="mcp-access">
  ### Acesso a MCP
</div>

Por padrão, as sessões podem usar qualquer [servidor MCP](/pt-BR/work-with-devin/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.

<Note>
  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.
</Note>

<div id="devin-mcp-access">
  ### Acesso ao Devin MCP
</div>

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.

<div id="git-access-level">
  ### Nível de acesso Git
</div>

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

| Nível               | O que Devin pode fazer                                                                     |
| ------------------- | ------------------------------------------------------------------------------------------ |
| **Somente leitura** | Clonar e buscar atualizações de repositórios, mas não fazer push de branches nem abrir PRs |
| **Completo**        | Clonar, buscar atualizações, fazer push e abrir PRs normalmente                            |

<div id="github-cli-token">
  ### Token da CLI do GitHub
</div>

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.

<div id="where-profiles-live">
  ## Onde os perfis ficam
</div>

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](#mandatory-vs-recommended-enforcement) que determina se níveis inferiores podem substituí-lo.

<div id="what-you-can-bind-a-profile-to">
  ## Ao que um perfil pode ser vinculado
</div>

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](/pt-BR/product-guides/automations) 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.

<div id="when-changes-take-effect">
  ### Quando as alterações entram em vigor
</div>

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.

<div id="mandatory-vs-recommended-enforcement">
  ## Aplicação obrigatória vs. recomendada
</div>

Todo perfil tem um nível de aplicação:

<div id="recommended">
  ### Recomendado
</div>

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.

<div id="mandatory">
  ### Obrigatório
</div>

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.

<div id="permissions-and-governance">
  ## Permissões e governança
</div>

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:

| Nível de permissão | O que permite                                                                                                                   | Concedido por padrão a |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------- | ---------------------- |
| Organização        | Criar, editar e excluir perfis da organização; definir os padrões da org e das automações; fixar perfis em automações e sessões | Admins da organização  |
| Enterprise         | Criar, editar e excluir perfis do Enterprise; definir o padrão do Enterprise                                                    | admins do Enterprise   |

Ambos os níveis dessa permissão podem ser concedidos a [funções personalizadas](/pt-BR/enterprise/security-access/custom-roles), 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.

<div id="setting-up-security-profiles">
  ## Configurando perfis de segurança
</div>

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.

<div id="automations-and-profiles">
  ## Automações e perfis
</div>

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.

<div id="outposts-and-profiles">
  ## Outposts e perfis
</div>

As sessões executadas no [Devin Outposts](/pt-BR/cloud/outposts/overview) 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](/pt-BR/cloud/outposts/reference) 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.

<Warning>
  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.
</Warning>