Se você toca um red team, conhece a regra: o auditor não trabalha para o auditado. Você escolheu o Promptfoo justamente porque ele ficava de fora dos fornecedores de modelo. 350 mil desenvolvedores, 25% da Fortune 500, licença MIT, multi-provider. Ele rodava suas fixtures de jailbreak, suas sondas de prompt-injection, seus cenários de vazamento de PII — e reportava o que quebrava, independente de qual laboratório construiu o modelo. Essa independência era o produto.
Teste de segurança tem um problema de conflito de interesse que o resto do trabalho de eval de ML não tem. Quando você está pontuando acurácia, o dono do modelo é um incômodo. Quando você está pontuando exploitability, o dono do modelo é a pergunta inteira.
Em 9 de março de 2026, a OpenAI adquiriu o Promptfoo. Os fundadores Ian Webster e Michael D'Angelo entraram para o OpenAI Frontier. Termos não divulgados. Última avaliação privada: US$ 86M, segundo o TechCrunch. O anúncio no promptfoo.dev se comprometeu — por escrito — a manter o framework sob licença MIT, multi-provider e com governança independente. Linguagem bonita. O incentivo estrutural manda ler duas vezes.
Aqui está o que de fato muda para times de segurança. O módulo de red team do Promptfoo vem com pacotes de ataque pré-montados — OWASP LLM Top 10, sondas do NIST AI RMF, uma biblioteca de templates de jailbreak conhecidos. Quando você rodava isso contra o GPT-4o no ano passado, os casos que falhavam viravam telemetria sua. Pós-aquisição, a camada de scanning hospedada na nuvem passa pela infraestrutura da OpenAI. Ou seja: o conjunto de prompts que faz jailbreak com sucesso em um modelo da OpenAI agora fica visível para o fornecedor cujo modelo foi jailbreakado — antes mesmo de você escrever o e-mail de disclosure. Não é hipótese; é como o runner hospedado funciona.
A thread do Hacker News do dia 9 de março trouxe à tona duas preocupações técnicas que o press release não tocou. Primeira, a curadoria dos pacotes de ataque: quem decide quais templates de jailbreak entram no pacote padrão quando o dono também é quem entrega o modelo sendo jailbreakado? Um teardown no dev.to apontou que três testes de prompt-injection específicos da OpenAI foram silenciosamente movidos do suite padrão para uma camada "avançada" nas release notes da v2.14 em 22 de março. Pode ser faxina. Pode não ser. Segunda, o modelo avaliador: o LLM-as-judge do Promptfoo usa por padrão o GPT-4o para pontuação de rubrica. Um framework da OpenAI usando um modelo da OpenAI para avaliar saídas de modelos da OpenAI não é um conflito novo — é o mesmo conflito, agora virando peça estrutural. A orientação de red-team da Anthropic sempre recomendou avaliação cross-vendor exatamente por isso.
Nada disso significa que a ferramenta piorou. O build OSS self-hosted ainda roda normalmente na sua própria infra, contra qualquer provider, com qualquer grader que você apontar. A licença MIT é real. Os commits continuam chegando. O que mudou foi o caminho padrão: a camada cloud, os pacotes de ataque hospedados, o grader gerenciado. Times que adotaram o Promptfoo por conveniência herdaram a nova fronteira de confiança, tendo lido o FAQ da aquisição ou não.
Se o seu modelo de ameaças inclui a OpenAI como potencial adversário — setores regulados, contratos de avaliação de modelos de fronteira, qualquer trabalho sob NDA que nomeie um laboratório específico — mova a avaliação para um setup cross-vendor ainda neste trimestre. Rode Promptfoo self-hosted, avalie com Claude ou Gemini, mantenha suas fixtures de ataque em um repo privado. DeepEval e Arize Phoenix são genuinamente vendor-neutral, se preferir trocar de ferramenta de vez.
Leitura honesta: a camada de ferramentas de red team independentes acabou de encurtar em um nome. Os reguladores ainda não perceberam 😾
→ OpenAI adquire o Promptfoo → Promptfoo entrando para a OpenAI → Cobertura do TechCrunch
