Olá a todos!
Hoje venho falar-vos de um projeto que descobri há uns dias e que me tem estado um prazer enorme de utilizar. Não porque seja mais um wrapper bonito a chamar a API do ChatGPT com um README longo cheio de bullet points bonitos, mas porque representa algo que, até há relativamente pouco tempo, estava categoricamente fora do alcance de qualquer organização que não tivesse uma equipa dedicada de segurança ofensiva e um orçamento considerável para a sustentar.
Estou a falar do PentAGI — Penetration testing Artificial General Intelligence — e está em https://github.com/vxcontrol/pentagi. Mais de 8.200 estrelas no GitHub, licença MIT, e um README que, se lerem com atenção, vai vos fazer perceber rapidamente porque é que isto está a gerar tanto barulho na comunidade de segurança.
Vamos a isto.
Facto: Pentesting é caro e muitas empresas portuguesas não o fazem
Deixem-me começar com uma pergunta honesta que ninguém gosta de responder em voz alta: quantas empresas portuguesas de pequena ou média dimensão têm algum processo regular de testes de segurança nos seus sistemas? Não um scan de vulnerabilidades automático que corre uma vez por ano e gera um PDF de 200 páginas que ninguém lê. Testes reais. Alguém a tentar genuinamente comprometer os sistemas para perceber o que falha.
A resposta, se formos honestos, é uma minoria pequena.
E não é por falta de consciência do problema. A maioria dos responsáveis de TI sabe que a sua superfície de ataque não para de crescer. Que cada novo microserviço que os developers colocam em produção é uma porta potencial. Que o servidor de staging que “era só temporário” está acessível desde 2019. Que as credenciais de acesso ao painel de administração de alguém ainda são admin/admin123 e que o dia em que alguém descobre isso vai ser um dia muito mau.
O problema é a equação económica. Um pentest externo decente, feito por gente competente, custa vários milhares de euros. E é, na melhor das hipóteses, uma fotografia de um momento no tempo. Passados três meses, a equipa de desenvolvimento fez doze deploys, adicionou quatro novos endpoints, migrou uma base de dados, e o relatório que custou cinco mil euros é essencialmente história. Para ter segurança contínua, precisas de segurança contínua. E isso, até agora, era um luxo de grandes empresas.
O PentAGI é uma proposta de resposta a este problema. Não perfeita, não mágica, mas genuinamente interessante.
O que é, sem o hype de marketing
O PentAGI não é um único agente de IA que recebe um URL e começa a tentar atacar alguém. A arquitetura é mais sofisticada do que isso — e é precisamente a sofisticação da arquitetura que o torna mais do que um brinquedo.
É um sistema multi-agente com papéis especializados. Há um Orquestrador que gere o fluxo de trabalho global. Um Investigador (Researcher) que faz reconhecimento e recolha de informação. Um Programador (Developer) que adapta e escreve código de exploração. Um Executor que corre os comandos nos containers isolados. E um Assistente para interação direta com o operador humano. Cada um destes agentes pode usar modelos de LLM diferentes — podes ter o Orquestrador no Claude Sonnet, o Executor a usar GPT-4o, e o Investigador a correr num modelo local via Ollama se quiseres poupar nos tokens para tarefas de pesquisa simples.
Isto não é um detalhe cosmético. Quem já trabalhou com agentes de IA sabe que a abordagem de agente monolítico que faz tudo é o caminho mais rápido para inconsistência, alucinações em tarefas longas, e perda de contexto nos momentos críticos. Separar responsabilidades é engenharia sólida, não marketing.
O sistema de memória é onde a coisa fica verdadeiramente diferente. Há três camadas distintas:
- Memória de longo prazo: PostgreSQL com extensão pgvector para pesquisa semântica. Os resultados de investigações passadas ficam guardados e podem ser recuperados por similaridade.
- Memória de trabalho: contexto atual, objetivos ativos, estado dos recursos disponíveis.
- Memória episódica: histórico de ações, resultados, padrões de sucesso.
E por cima disto, integração opcional com o Graphiti — um grafo de conhecimento temporal baseado em Neo4j. Se o sistema descobriu numa avaliação anterior que um determinado tipo de configuração de servidor web é vulnerável a uma técnica específica de injeção, essa aprendizagem fica guardada no grafo e pode ser reutilizada em avaliações futuras com alvos similares.
Isto é substancialmente diferente de chamar a API de um LLM e pedir “faz pentesting a este servidor”. Muito diferente.
As ferramentas — porque sim, são ferramentas reais. Não é magia. Não é the next best thing.
Outro ponto que vale a pena sublinhar: o PentAGI não simula ataques com prompts criativos. Tem um suite de mais de 20 ferramentas profissionais a correr dentro de containers Docker isolados. nmap, metasploit, sqlmap, nikto, hydra, gobuster — o arsenal que qualquer pentester com experiência reconhece imediatamente.
A stack de pesquisa externa também não é de desprezar: integração com Tavily, Perplexity, Sploitus (pesquisa de exploits específica para segurança), DuckDuckGo, Google Custom Search, e Searxng. Quando o sistema encontra uma versão de software específica num alvo, consegue ir procurar CVEs conhecidos e exploits disponíveis em tempo real.
Há também um scraper baseado em browser isolado para recolha de informação de fontes web que requerem JavaScript, que é basicamente toda a web em 2026.
A stack de observabilidade
Aqui está algo que me surpreendeu genuinamente quando li o README com atenção.
O PentAGI vem com uma stack de observabilidade completa: OpenTelemetry para recolha de telemetria, Grafana com VictoriaMetrics para dashboards em tempo real, Jaeger para tracing distribuído, Loki para agregação de logs, e Langfuse para observabilidade específica dos modelos de linguagem — incluindo análise de custos, latência, e qualidade das respostas.
Porquê é que isto importa? Porque um sistema de pentesting autónomo que funciona como caixa negra é um pesadelo — não só para debugar quando algo corre mal, mas do ponto de vista de auditoria e responsabilidade. Se o sistema executou um comando que causou uma disrupção num serviço de produção durante um teste autorizado, precisas de saber exatamente o quê, quando, porquê, e em que contexto. A observabilidade não é um extra — é um requisito para qualquer uso sério.
O facto de os criadores terem investido tanto nesta parte diz algo sobre a maturidade da abordagem.
Instalação: do zero a funcionar (to hero) em menos de meia hora
Chega de teoria. Vamos à parte que interessa a quem quer experimentar.
Requisitos mínimos
- Docker e Docker Compose instalados
- 2 vCPU e 4GB RAM (o mínimo, confortável a partir de 8GB)
- 20GB de espaço em disco
- API key de pelo menos um provider de LLM (OpenAI, Anthropic, Gemini, AWS Bedrock — ou Ollama local se quiseres zero custos externos mas precisas de hardware para isso)
Opção 1: Installer interativo (recomendado para começar)
O projeto disponibiliza um installer com TUI (Terminal User Interface) que guia o processo inteiro. É a forma mais rápida de ter tudo funcional sem ler documentação extensiva.
# Criar directório de trabalho
mkdir pentagi && cd pentagi
# Descarregar o installer (Linux amd64)
wget -O installer.zip https://pentagi.com/downloads/linux/amd64/installer-latest.zip
# Extrair
unzip installer.zip
# Correr o installer (precisa de acesso ao Docker socket)
sudo ./installer
O installer faz o seguinte por ordem: verificação de requisitos de sistema, configuração do ficheiro .env com valores por defeito sensatos, setup do provider de LLM (aqui escolhes OpenAI, Anthropic, Gemini, ou outro), configuração dos motores de pesquisa externos, geração de certificados SSL e credenciais seguras, e finalmente o deploy via Docker Compose.
Para macOS ou Windows, substituem o URL por darwin/amd64, darwin/arm64, ou windows/amd64 conforme o vosso sistema.
Opção 2: Docker Compose manual (para quem quer controlo total)
Se preferirem fazer as coisas à mão — o que é perfeitamente razoável e permite perceber melhor o que está a correr:
Passo 1 — Obter o ficheiro de configuração:
mkdir pentagi && cd pentagi
curl -o .env https://raw.githubusercontent.com/vxcontrol/pentagi/master/.env.example
curl -O https://raw.githubusercontent.com/vxcontrol/pentagi/master/docker-compose.yml
Passo 2 — Editar o .env com as vossas chaves:
Abram o ficheiro .env e preencham pelo menos um provider de LLM. O mínimo para funcionar:
# Escolham um destes (ou mais do que um)
OPEN_AI_KEY=sk-vossa-chave-aqui
ANTHROPIC_API_KEY=sk-ant-vossa-chave-aqui
GEMINI_API_KEY=vossa-chave-aqui
# Recomendo activar pelo menos o DuckDuckGo para pesquisa (gratuito, sem chave)
DUCKDUCKGO_ENABLED=true
# E o Sploitus para pesquisa de exploits (também gratuito)
SPLOITUS_ENABLED=true
Enquanto estão no .env, alterem também estas variáveis de segurança antes de colocar em qualquer ambiente que não seja estritamente local:
# Mudem isto para um valor aleatório — não deixem o default
COOKIE_SIGNING_SALT=gerem-algo-aleatorio-aqui
# Credenciais da base de dados
PENTAGI_POSTGRES_USER=pentagi
PENTAGI_POSTGRES_PASSWORD=uma-password-decente-aqui
Passo 3 — Deploy:
docker compose up -d
Na primeira vez isto vai demorar uns minutos a descarregar as imagens. Quando terminar, a interface web está em https://localhost:8443. O certificado é self-signed, por isso vão ter o aviso de segurança habitual no browser — é normal. Credenciais por defeito: [email protected] / admin. Mudem isto imediatamente.
Adicionar a stack de observabilidade (opcional mas recomendado)
Se quiserem o Grafana, Jaeger, e Loki para ter visibilidade sobre o que o sistema está a fazer:
curl -O https://raw.githubusercontent.com/vxcontrol/pentagi/master/docker-compose-observability.yml
# Activar no .env
echo "OTEL_HOST=otelcol:8148" >> .env
# Redeployar com ambos os ficheiros
docker compose -f docker-compose.yml -f docker-compose-observability.yml up -d
O Grafana fica disponível em http://localhost:3000.
Adicionar o Langfuse para observabilidade dos LLMs:
curl -O https://raw.githubusercontent.com/vxcontrol/pentagi/master/docker-compose-langfuse.yml
docker compose -f docker-compose.yml -f docker-compose-langfuse.yml up -d
Interface do Langfuse em http://localhost:4000.
Para correr tudo de uma vez (atalho útil):
docker compose \
-f docker-compose.yml \
-f docker-compose-langfuse.yml \
-f docker-compose-observability.yml \
up -d
Se usam muito o PentAGI, vale a pena meter este alias no vosso .bashrc ou .zshrc:
alias pentagi-up="docker compose -f docker-compose.yml -f docker-compose-langfuse.yml -f docker-compose-observability.yml up -d"
alias pentagi-down="docker compose -f docker-compose.yml -f docker-compose-langfuse.yml -f docker-compose-observability.yml down"
Uma nota importante sobre produção
Para ambientes que não sejam estritamente locais ou de laboratório, a documentação recomenda uma arquitectura de dois nós: um servidor principal com a interface e o backend, e um worker node separado onde correm os containers de pentesting. A razão é simples — o worker executa código potencialmente não confiável (exploits, payloads, ferramentas de ataque), e não é uma boa prática ter isso a correr na mesma máquina onde guardas os teus dados. É separação de responsabilidades básica. A documentação cobre isto em detalhe no guia worker_node.md no repositório.
O que isto demonstra sobre o estado da IA agentic em 2026
Agora o que me interessa genuinamente discutir: o que é que um projeto como o PentAGI nos diz sobre onde estamos?
Escrevi há pouco tempo sobre os custos absurdos da IA agentic — sobre como Jason Calacanis estava a gastar $300 por dia por agente, sobre como a Gartner prevê que mais de 40% dos projetos de agentic AI vão ser cancelados até 2027, sobre como a matemática frequentemente não fecha quando tentamos substituir humanos por agentes. Continuo a acreditar em tudo o que escrevi lá. Os custos são reais e muita gente está a ignorá-los.
Mas o PentAGI representa um caso de uso onde a equação económica pode genuinamente fazer sentido, e vale a pena perceber porquê.
O argumento não é “vamos substituir o pentester humano sénior”. Esse argumento é errado e os criadores do projeto provavelmente sabem-no. Um pentester experiente com quinze anos de carreira traz conhecimento contextual, criatividade, e julgamento que nenhum sistema de agentes replicará nos próximos anos. Os melhores pentesters do mundo não são ferramentas — são estrategistas.
O argumento correto é outro: para a imensa maioria das organizações que hoje não têm absolutamente nada, qualquer coisa é melhor do que nada. Uma PME sem capacidade de segurança ofensiva interna que usa o PentAGI para testes regulares vai encontrar as vulnerabilidades óbvias, os misconfigs triviais, os endpoints esquecidos, as versões de software desatualizadas. Vai encontrá-los antes que outros os encontrem. E isso tem valor real.
Há também um segundo caso de uso que me parece interessante: integração em pipelines de CI/CD. Imaginem um job que corre o PentAGI automaticamente após cada deploy para staging, antes de qualquer promoção para produção. Não como substituto de uma avaliação completa, mas como camada de validação contínua. Encontra o SQLi óbvio antes que chegue a produção. Não é sofisticado, mas para o que custa comparado com o custo de um incidente, a matemática fecha.
O lado que não posso ignorar
Há um elefante no parágrafo anterior que tenho de reconhecer diretamente.
Se uma equipa consegue construir isto em open source, com Docker Compose e uma API key, e disponibilizá-lo para download com um installer interativo — então a barreira de entrada para automação de reconnaissance e exploração desceu de forma muito significativa. E as mesmas técnicas que tornam o PentAGI valioso para quem defende sistemas são as mesmas que podem ser usadas por quem não tem boas intenções.
Não digo isto para dramatizar. Digo porque é verdade e porque fingir que não é seria desonesto. As ferramentas de ataque sempre estiveram disponíveis para quem as quis procurar — o Metasploit existe desde 2003, o Kali Linux desde 2013, e nenhum deles acabou com a civilização. O que o PentAGI acrescenta é automação e acessibilidade, que são coisas diferentes de criar capacidades novas.
A resposta racional a esta realidade não é suprimir estas ferramentas — é usá-las para encontrar os vossos próprios problemas antes que alguém o faça por vocês. Segurança por obscuridade nunca funcionou e continua a não funcionar.
Os números que vão querer saber antes de experimentar
Quanto custa correr isto? Depende do provider e da intensidade de uso, mas para dar uma ideia concreta:
Com OpenAI (GPT-4o para o orquestrador, modelos mais leves para tarefas de pesquisa), uma avaliação de complexidade moderada pode consumir entre $5 e $20 em tokens. Com Anthropic (Claude Sonnet para tarefas de raciocínio principal), números similares. Estes valores variam muito com a complexidade do alvo, o número de ferramentas que o sistema decide usar, e quantos loops de tentativa-e-erro são necessários.
Para quem quer zero custos externos: o suporte a Ollama é real e funcional, mas vão precisar de hardware suficiente. Os modelos que fazem sentido para este tipo de workflow — Qwen3 32B, QwQ 32B — requerem GPUs com memória suficiente para lidar com janelas de contexto de 110K tokens. Não é para toda a gente, mas para quem tem o hardware disponível é uma opção genuinamente interessante do ponto de vista de privacidade e previsibilidade de custos.
Hey, estou a correr o meu localmente, com duas 3060 e duas 3070.
O sistema expõe também REST e GraphQL APIs com autenticação por Bearer token, o que significa que é possível integrá-lo em workflows automáticos sem abrir a interface web. A documentação inclui exemplos em Python e TypeScript para quem quiser construir automações à volta disto.
Conclusão: um sinal de direção, não um produto acabado
O PentAGI não é o produto acabado que vai resolver o problema de segurança de todas as PMEs portuguesas. É um sinal muito claro de direção.
A direção é esta: ferramentas de segurança que antes requeriam equipas especializadas e orçamentos significativos estão a tornar-se acessíveis como software self-hosted, deployável com Docker Compose, configurável por qualquer pessoa com competências técnicas razoáveis. Não perfeitas — mas suficientemente capazes para encontrar os problemas que, na realidade, são os que mais frequentemente causam incidentes.
O repositório está ativo, a comunidade no Discord e Telegram está a crescer a olhos vistos, e o projeto tem 265 commits com updates regulares. Não é um proof-of-concept abandonado — é um projeto em desenvolvimento activo.
Se trabalham em segurança ou em IT numa organização que não tem capacidade de testes regular, vale genuinamente a pena dedicar meio dia a instalar isto num ambiente de laboratório e perceber o que consegue fazer. Não como substituição de uma avaliação profissional quando a situação o exigir, mas como ferramenta de higiene contínua.
E se ficarem impressionados com o que encontra nos vossos próprios sistemas — não digam que não ficaram avisados.
Mantenham-se curiosos, testem os vossos sistemas, e sobretudo: usem isto apenas em sistemas que tenham autorização explícita para testar. Penetration testing sem autorização é crime em Portugal e na maior parte das jurisdições. Isso não muda por a ferramenta ser open source e fácil de usar. Na verdade, a facilidade de uso torna a consciência legal ainda mais importante.
Um abraço, Nuno
P.S.: Para quem quiser explorar sem gastar nada em tokens logo de início, comecem com DUCKDUCKGO_ENABLED=true e SPLOITUS_ENABLED=true no .env, e usem o modo de assistente com ASSISTANT_USE_AGENTS=false para ter uma conversa com o sistema antes de lançar um workflow autónomo. Percebem muito melhor o que está a acontecer por baixo, e evitam surpresas desagradáveis na fatura do OpenAI.