# Segurança

> Credenciais, HTTPS, login e exposição de rede de uma instalação do PentAGI.

## [Alterar os padrões](https://pentagi.com/pt-br/docs/configuration/security/#change-the-defaults)

Uma instalação nova cria o administrador local `admin@pentagi.com` com a senha `admin`, que deve ser alterada no primeiro login. Se a senha for perdida, o menu de manutenção do instalador a redefine, desde que a conta ainda use o endereço `admin@pentagi.com`.

Defina esses valores em `.env` antes da primeira inicialização; o instalador gera o salt e as senhas para você. O PostgreSQL e o Neo4j usam suas credenciais apenas quando criam seus volumes de dados, portanto, alterá-los posteriormente rompe a conexão:

| Variável                                             | Finalidade                                                                                                     |
| ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| `COOKIE_SIGNING_SALT`                                | Assina cookies de sessão e tokens de API — defina um valor aleatório                                           |
| `PENTAGI_POSTGRES_USER`, `PENTAGI_POSTGRES_PASSWORD` | Credenciais do PostgreSQL                                                                                      |
| `NEO4J_PASSWORD`                                     | Senha do Neo4j para o [knowledge graph](https://pentagi.com/pt-br/docs/glossary/#knowledge-graph); `NEO4J_USER` deve permanecer `neo4j` |
| `PUBLIC_URL`                                         | A URL que os usuários abrem, por exemplo `https://pentagi.example.com`                                         |

Em uma instalação em execução, altere a senha do banco de dados primeiro no PostgreSQL ou no Neo4j e depois em `.env`.

## [HTTPS](https://pentagi.com/pt-br/docs/configuration/security/#https)

O PentAGI serve HTTPS na porta 8443 com um certificado autoassinado. Para usar o seu próprio, defina `SERVER_SSL_CRT` e `SERVER_SSL_KEY` e monte os arquivos em `docker-compose.yml`.

## [Usuários e login](https://pentagi.com/pt-br/docs/configuration/security/#users-and-sign-in)

Não há formulário de cadastro. Os administradores gerenciam usuários locais pela Users API (`/api/v1/users/`) a partir de uma sessão de navegador autenticada — um token de API recebe 403 ali — e as funções restringem o que cada usuário pode ver e alterar. Usuários locais alteram seu próprio e-mail e senha em **Settings → Account**.

Com o login via GitHub ou Google configurado, um login cujo e-mail verificado pelo provedor corresponda a uma conta existente, incluindo contas locais, faz login nessa conta com sua função; qualquer outro login recebe uma nova conta com a função de usuário padrão. Toda instalação começa com o administrador `admin@pentagi.com`, portanto mova-o para um endereço sob seu controle em **Settings → Account** antes de habilitar o login, e habilite-o apenas onde novas contas sejam aceitáveis, por exemplo com um app do Google Workspace limitado ao seu domínio.

O login via GitHub e Google está disponível por OAuth. Registre um app com o callback `${PUBLIC_URL}/api/v1/auth/login-callback` e adicione suas credenciais:

```bash
PUBLIC_URL=https://pentagi.example.com
OAUTH_GITHUB_CLIENT_ID=your_github_client_id
OAUTH_GITHUB_CLIENT_SECRET=your_github_client_secret
```

## [Exposição de rede](https://pentagi.com/pt-br/docs/configuration/security/#network-exposure)

Por padrão, a interface web do PentAGI escuta apenas em `127.0.0.1`. Para acessá-la de outras máquinas:

```bash
PENTAGI_LISTEN_IP=0.0.0.0
PENTAGI_LISTEN_PORT=8443
PUBLIC_URL=https://192.168.1.100:8443
CORS_ORIGINS=https://localhost:8443,https://192.168.1.100:8443
```

Use o endereço real em `PUBLIC_URL` e `CORS_ORIGINS`, nunca `0.0.0.0`. Recrie os containers com `docker compose up -d --force-recreate` e abra a porta 8443 no firewall.

Por trás de um proxy reverso, defina `TRUSTED_PROXIES` como o endereço ou CIDR do proxy, separados por vírgula. Caso contrário, todas as requisições parecerão vir do proxy, e o limite de tentativas de login por endereço — 30 falhas em cinco minutos, seguido de um bloqueio de 15 minutos — será compartilhado por todos os usuários.

O contêiner [sandbox](https://pentagi.com/pt-br/docs/glossary/#sandbox) de cada [flow](https://pentagi.com/pt-br/docs/glossary/#flow) também publica duas portas para callbacks fora de banda, como reverse shells. Elas vêm das 2000 portas que começam em `DOCKER_PORTS_BASE` (padrão `28000`) e são vinculadas a `DOCKER_PUBLIC_IP`, o endereço que os [agents](https://pentagi.com/pt-br/docs/glossary/#agent) também fornecem aos alvos para realizar o callback.

Por padrão, `DOCKER_PUBLIC_IP` é `0.0.0.0`: as portas escutam em todas as interfaces do host Docker, e os agents descobrem seu endereço público por conta própria. Defina-o para um endereço específico apenas se o host possuir esse endereço e os alvos puderem alcançá-lo; atrás de NAT, mantenha o padrão. As portas que o Docker publica ignoram as regras do ufw e do firewalld no host, portanto, restrinja o intervalo com um firewall à frente do host, como um grupo de segurança na nuvem, ou com regras na cadeia `DOCKER-USER` do Docker.

`PROXY_URL` encaminha as chamadas do backend para provedores de modelo, o provedor de embeddings, APIs de busca e a verificação de atualizações por meio de um proxy, o que ajuda a isolar a instalação de redes externas. Endpoints auto-hospedados, como Ollama, vLLM ou SearXNG, também passam por ele, pois não há exceção `NO_PROXY`; portanto, o proxy deve poder alcançá-los. Os contêineres sandbox dos flows, onde os agents executam seus comandos, o scraper, que abre páginas web para a ferramenta browser, e o serviço Graphiti não o utilizam; portanto, restrinja o tráfego de saída deles no nível de rede. O login com GitHub ou Google e as chamadas para um endpoint Langfuse ou OpenTelemetry fora das stacks incluídas também não o utilizam, e o daemon Docker baixa imagens com suas próprias configurações de proxy.

## [Verificação de atualizações](https://pentagi.com/pt-br/docs/configuration/security/#update-check)

Dentro de dois minutos após o início e depois a cada três horas, o servidor pergunta a `update.pentagi.com` se há uma build mais recente disponível. A solicitação leva o ID da instalação, a chave de licença se houver uma definida, a versão e a plataforma, e um resumo da instalação: o provider configurado e os tipos de login, alguns interruptores de recursos, contagens de usuários, flows, [tasks](https://pentagi.com/pt-br/docs/glossary/#task), contêineres, prompts, tokens de API e [tool calls](https://pentagi.com/pt-br/docs/glossary/#tool-call), e totais de tokens e custos por tipo de provider — sem nomes, endereços, prompts ou conteúdo de flow. `UPDATE_CHECK_INTERVAL=0` desativa isso. Cada vez que o instalador é iniciado e após cada ação que ele executa, como Apply Changes, Update, Start ou Stop, ele envia as imagens instaladas e o estado de cada stack, além do mesmo resumo enquanto o PentAGI estiver em execução; `UPDATE_CHECK_INTERVAL` não o afeta.

> [!WARNING]
> O container `pentagi` roda como root porque gerencia containers pelo socket do Docker. Para maior isolamento, execute as [tools](https://pentagi.com/pt-br/docs/glossary/#tool) em um [worker node](https://pentagi.com/pt-br/docs/deployment/worker-node/) separado.