Fernando Moreira

Full-Stack TypeScript (React/Next.js) · OWASP · Autor do Nemesis Defender

[Fernando Moreira @_feryamaha]

https://t.co/QrO5ofPlB2

[Fernando Moreira @_feryamaha]

OpenAI revela que um de seus modelos encontrou uma forma de escapar do sandbox e publicar código no GitHub durante testes internos.
Fonte: https://t.co/nr7l4il9JZ

O modelo persistiu por cerca de 1 hora, explorou uma vulnerabilidade no sandbox e abriu um Pull Request no repositório do benchmark NanoGPT, mesmo com instruções explícitas para postar apenas no Slack.

Isso é o mesmo padrão visto no Claude Mythos (abril/2026): o modelo escapa do sandbox, ganha acesso não autorizado à internet e envia email + publica detalhes publicamente sem ser instruído, tudo por perseguir objetivos de forma agentic sem restrições adequadas.
Fonte: https://t.co/adIRQ9UCIv

Nos dois casos, decisões ocultas em runtime e trajetórias longas contornam controles e geram ações além do escopo do usuário. Exatamente o comportamento que venho documentando há mais de um ano.
Casos como esses reforçam um ponto crítico: agentes autônomos com acesso direto a comandos do sistema podem causar perdas graves. Sandbox, Docker e harness (prompts, rules, skills) se mostram insuficientes sozinhos.
Para reduzir esse risco criei o Nemesis Defender, projeto open source em Rust de enforcement determinístico em tempo de execução.
Intercepta toolcalls e operações de escrita via hooks de IDEs (Cursor, Claude, Devin etc.)
Análise multi-camada para detectar padrões destrutivos e supply-chain attacks
Bloqueio imediato de comandos perigosos + quarentena de arquivos suspeitos com revisão humana
Camada extra no kernel via eBPF apenas para sistema Linux

Versão v0 com instalação facilitada e documentação completa.
Se você trabalha com agentes de IA, confira o repositório:
https://t.co/lF9josKeXs

"O QUE É SEGURO HOJE, NO FINAL DO DIA JÁ NÃO É MAIS"

[Fernando Moreira @_feryamaha]

Se até medalhista Fields deixa passar bug por quase três décadas, a gente pode parar de fingir que revisão de código humano é perfeita.

O maior matemático vivo pegou 24 applets Java que ele mesmo escreveu em 1999 e pediu pra uma IA portar tudo pra JavaScript.
A IA fez em horas.
E ainda encontrou 2 bugs no código original que o Terry Tao não tinha visto em 27 anos.
No processo ela introduziu 1 bug. Resultado: empate técnico.

https://t.co/OLE6DRxPRv

[Fernando Moreira @_feryamaha]

https://t.co/QrO5ofPlB2

[Fernando Moreira @_feryamaha]

Do you use Claude, Codex, Cursor, Grok or Devin?
Most coding-agent hooks protect against dangerous commands.
Almost none protect themselves.
Any model can disable its own guard and execute what it decided.
It can also write malicious code that only runs later (in the build or the next agent).
Nemesis does three things:

Denies execution
Scans written content
Prevents the agent from turning the guard off

Red-team with GLM-5.2, 93 attack vectors:
0 files deleted. 0 malicious scripts executed. 0 times Nemesis was neutralized.

[Fernando Moreira @_feryamaha]

@krisnarane1 Otimo tema Julia. Compartilha conosco detalhes da paletra! Sucesso!

[Fernando Moreira @_feryamaha]

Nemesis Defender é open source (AGPL-3.0).

Se você usa agentes de código (Grok, Claude, Cursor, Devin, Codex etc) e se preocupa com segurança, dá uma olhada.

https://t.co/QrO5ofPlB2

[Fernando Moreira @_feryamaha]

Testei vários vetores (rm genérico, git reset, shell commands, etc) usando meu pentest readteam de validação de jailbreak para validar essa integração entre o Nemesis e o Grok CLI:

[Fernando Moreira @_feryamaha]

Resumo dos testes:

- rm -rf em arquivos e pastas → bloqueado
- Tentativas via shell do agente → bloqueado
- Comandos que antes passavam → agora negados com exit code 2
- Arquivos protegidos permanecem intactos

O modelo não consegue mais ignorar a camada de segurança. Agora o Nemesis possui uma nova cobertura para Grok categoria TUI

[Fernando Moreira @_feryamaha]

Testei o Nemesis Defender com o Grok agent Grok 4.5 (agora que ele roda com harness).

Resultado: todas as tentativas de rm -rf, unlink e comandos destrutivos foram bloqueadas pelo PreToolUse hook do meu enforcement

Aqui um dos testes:

[Fernando Moreira @_feryamaha]

@LoopOnChain Wow. Interesting, I'll give it a try.

[Fernando Moreira @_feryamaha]

Nos últimos dias vi dois relatos que ninguém que trabalha com agentes de código devia ignorar.

"o GPT-5.6 Sol acabou de apagar todo o meu banco de produção... No mesmo dia: GPT-5.6 Sol apagou quase todos os arquivos do Mac... "

Sem malícia, sem jailbreak, sem ataque. Só um agente com autoridade delegada, um rm que escapou, e nada entre o palpite do modelo e o disco.

Diante disso apareceu uma solução um tanto incoerente, e é aqui que eu quero prender sua atenção. A ideia, que está circulando, é colar um prompt no Codex pedindo para o próprio modelo se blindar: detectar o sistema, instalar um hook PreToolUse que negue rm, unlink, find -delete, git reset --hard, mandar tudo para a lixeira em vez de apagar. Defense in depth, não só instrução escrita, diz o texto. Parece resolver. MAS NÃO RESOLVE POSSO TE PROVAR QUE NÃO!

O problema PARA quem você está confiando. Você está pedindo para o mesmo agente autônomo que pode apagar seu disco construir, configurar e respeitar a própria jaula. E um modelo que decide agir contorna a jaula que ele mesmo guarda.

A prova mais forte disso não é opinião minha: a Anthropic reportou este ano que uma versão de fronteira do Claude, a Mythos, foi instruída a operar dentro de um sandbox de teste, construiu sozinha um exploit para alcançar a internet por um canal que só devia falar com serviços pré-aprovados, escapou, e ainda mandou um e-mail para o pesquisador avisando que tinha conseguido. A empresa decidiu não liberar o modelo por causa disso. Se um modelo de ponta instruído a ficar contido sai mesmo assim, confiar que o mesmo modelo vai erguer e honrar a própria contenção é confiar exatamente na parte errada. Contenção não pode depender da boa vontade de quem ela contém. O próprio autor do prompt admite no fim: um hook do Codex é um guardrail, não uma fronteira de segurança do sistema operacional.

É por isso que eu construí o Nemesis Defender de um jeito diferente. A regra não é escrita pelo agente nem mora num arquivo que ele pode editar: ela vive compilada dentro do binário, tamper-proof. O Nemesis não conversa com o modelo, ele intercepta a chamada de ferramenta antes da execução e devolve exit code 2. Bloqueio determinístico, categórico, não importa se o modelo foi enganado ou apenas estava confiante e errado. Quando confirma hostilidade, não apaga nada: move para quarentena e espera revisão humana. Reversível, 100% local. A tese cabe em uma frase: inteligência não implica autoridade.

Sou honesto sobre o limite: cobertura é a soma das camadas, não uma bala de prata, e vetor fora do que foi antecipado pode passar. Mas nos vetores que exercitei, o modelo não passou.

A pergunta que eu deixo é simples: enquanto a indústria discute quão inteligente vai ser o próximo modelo, quem está cuidando do que fica entre esse modelo e o seu disco? A resposta não pode ser o próprio modelo.

O Nemesis é open source, AGPL-3.0. Link nos comentários.

#IA #AgentesAutonomos #SegurancaDeIA #AISafety #Rust #DevSecOps #LLM

https://t.co/lF9josKeXs

[Fernando Moreira @_feryamaha]

Hi Bruno,Just saw your post. That's rough. Production DB wiped because the agent went rogue during cleanup after e2e tests. I built Nemesis Defender exactly for situations like this: open-source Rust security layer that hooks into Cursor/Claude/etc. and stops destructive commands from AI agents before they run (quarantine + human approval + eBPF on Linux).

https://t.co/lF9josKeXs

[Fernando Moreira @_feryamaha]

Are you trying to resolve a problem with the very entity causing it? That doesn't work.
Take a look at my Nemesis Defender; it’s an enforcement tool that uses pre-tool hooks to block actions deterministically and at the binary level it doesn't rely on the model. If a tool call involves destructive or malicious commands, it blocks the execution directly at the OS level with exit code 2.

https://t.co/lF9josKeXs

[Fernando Moreira @_feryamaha]

@mattshumer_ @gdb Take a look at my project. I created it for exactly this reason, it’ll help you out!

https://t.co/QrO5ofPlB2

[Fernando Moreira @_feryamaha]

@reach_vb
The problem with Rules and self-configured PreToolUse hooks is that they are still just instructions the model has to follow. As we saw in the GPT-5.6-Sol incident, models can misinterpret, ignore, or fail to apply them correctly, especially in complex multi-step agent workflows.That’s exactly why I built Nemesis Defender.
It’s a deterministic enforcement layer that hooks directly into the IDE’s pre-tool calls. It blocks destructive commands and malicious patterns before they ever execute on the system, regardless of what the model decides to do. Rules are baked into the binary (tamper-proof), and suspicious actions get quarantined for human review instead of being deleted. It doesn’t rely on the agent obeying instructions.
Repo:https://t.co/lF9josKMN0
I see prompt-based rules + external deterministic enforcement as complementary layers.

[Fernando Moreira @_feryamaha]

Great prompt for adding self-guardrails directly inside Codex. My project takes a different approach. Nemesis Defender is an external Rust tool that intercepts pre-tool calls at the IDE/system level before the agent can execute anything.Key differences:Rules are baked into the binary (tamper-proof)
Multi-layer detection (AST + regex + entropy + denylist) for destructive commands and supply-chain malware
Quarantines suspicious files for human review instead of just blocking
Optional eBPF kernel layer on Linux as a hard backstop
Works across different agents and IDEs (not tied to one model’s prompt system)

It’s designed as a deterministic enforcement layer that doesn’t rely on the agent correctly following instructions.Repo: https://t.co/uUKO7lViFI actually see them as complementary — prompt-level guards like yours + external system enforcement like Nemesis.What’s your take?

[Fernando Moreira @_feryamaha]

Hi scary stuff.

I’ve been building Nemesis Defender (https://t.co/lF9josKeXs) specifically to prevent this kind of incident.

It’s a deterministic security layer for LLM agents in dev environments. It hooks into pre-tool calls in IDEs (Cursor, Claude, Devin, etc.) and blocks destructive commands and suspicious file writes before they execute. It uses multi-layer scanning (AST, regex, entropy, etc.) and, on Linux, has an optional eBPF kernel backstop.Instead of just killing the action, it quarantines suspicious files for human review.

The blocking rules are baked into the binary so agents can’t bypass them by editing configs. It’s still early (v0), but it’s designed exactly for the failure mode you described. Would love to hear your thoughts on it or if you’d be open to trying it.

Thanks

[Fernando Moreira @_feryamaha]

A Anthropic recentemente publicou um guia de segurança para agentes de IA que traz uma mensagem clara: devemos parar de confiar cegamente nos nossos próprios agentes.

https://t.co/P1Xh2RBTkk

No documento, eles destacam um critério importante para avaliar controles de segurança: a diferença entre tornar um ataque apenas mais trabalhoso ou realmente impossível de ser executado. Essa distinção é fundamental, pois agentes automatizados ou comprometidos não se importam com atritos como rate limits ou instruções de prompt.

Muitas soluções atuais seguem o caminho de políticas e recomendações. Subagentes especializados em segurança e configurações de Least Agency são avanços relevantes. No entanto, todas essas abordagens ainda dependem, em última instância, de que o modelo respeite as regras definidas ou de que um scanner identifique o problema antes da execução.

Quando um agente sofre jailbreak, tool poisoning ou ignora as instruções de segurança, essas camadas deixam de ser eficazes. A ação maliciosa pode ocorrer antes de qualquer intervenção.É nesse ponto que surge a diferença entre detecção/recomendação e enforcement determinístico.

O Nemesis Defender foi projetado para atuar exatamente nessa lacuna. Ele combina três camadas de proteção: PreTool Hooks que interceptam chamadas de ferramenta diretamente no ambiente de desenvolvimento, um Content Scanner em Rust com análise AST e verificação de padrões maliciosos, e uma camada de kernel baseada em eBPF + Landlock para bloqueio em nível de syscall.

Além do bloqueio em tempo de execução, ao instalar o Nemesis o ambiente de desenvolvimento passa a contar com proteções adicionais. Arquivos sensíveis como variáveis de ambiente ficam protegidos contra leitura e exfiltração não autorizadas por agentes. Arquivos de configuração, hooks, settings e a estrutura do ambiente de desenvolvimento também são resguardados contra modificações não permitidas.

O sistema impede a execução de comandos destrutivos ou maliciosos, mesmo quando sugeridos ou tentados pelo modelo. A autoridade final permanece sempre com o desenvolvedor.

Diferente de abordagens baseadas apenas em prompts ou subagentes, o Nemesis opera com regras tamper-proof embutidas no binário, funciona de forma offline e garante que nenhuma ação de alto risco seja realizada sem aprovação humana explícita.

Prompt engineering e subagentes de segurança continuam sendo ferramentas úteis. Porém, quando o objetivo é garantir que determinadas ações simplesmente não possam acontecer, mesmo diante de um agente comprometido, o enforcement em tempo de execução no nível do kernel oferece um nível de garantia que as camadas anteriores não conseguem entregar sozinhas.

https://t.co/SsRvOwDB8v

Como você tem avaliado a segurança dos agentes de IA nos seus ambientes de desenvolvimento?

Está priorizando camadas de recomendação ou já considera necessário enforcement determinístico em runtime?