Segurança

Alterar os padrões

Uma instalação nova cria o administrador local [email protected] 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 [email protected].

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:

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

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

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 [email protected], 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:

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

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

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 de cada 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 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

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, contêineres, prompts, tokens de API e tool calls, 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.