A segurança de agentes de IA começa com software pequeno

Matt Sephton publicou Fits on a Floppy em abril de 2026 com uma restrição deliberadamente absurda: software útil deveria tentar caber em 1,44 MB, a capacidade de um disquete padrão de 3,5 polegadas.¹

O limite de tamanho importa menos do que a postura por trás dele. Sephton defende downloads rápidos, inicialização instantânea, baixo uso de memória, baixo uso de CPU, código nativo, suporte a sistemas antigos e ferramentas que fazem uma coisa bem-feita.¹ A leitura óbvia é que software pequeno respeita o usuário. A leitura da era dos agentes vai além: software pequeno dá aos agentes de IA que programam menos lugares para esconder erros.

A segurança de agentes de IA começa com software pequeno porque sistemas pequenos e inspecionáveis reduzem o espaço em que um agente pode entender algo errado, modificar sem querer, autorizar indevidamente e deixar de testar. Sandboxes e prompts de permissão continuam importantes. O software pequeno desloca a fronteira de segurança para antes, para o formato do próprio artefato.

Resumo

Agentes de programação funcionam melhor quando conseguem ler os arquivos relevantes, executar as verificações relevantes e explicar o diff relevante antes que o contexto se deteriore. A orientação de Claude Code da Anthropic diz que o contexto se enche rapidamente e que o desempenho piora conforme ele se enche; o mesmo guia chama a verificação de prática mais valiosa e descreve ferramentas CLI como interfaces eficientes no uso de contexto.² A documentação de shell local da OpenAI alerta que agentes que executam comandos de shell precisam de sandboxing ou listas estritas de permissão e bloqueio antes da execução.³

Software pequeno não substitui esses controles. Ele torna esses controles mais fáceis de aplicar. Uma ferramenta pequena tem menos comandos para autorizar, menos arquivos para inspecionar, menos dependências em que confiar, menos testes para executar e menos ramificações onde uma suposição errada pode se esconder. A velha lição do Unix não ficou obsoleta: McIlroy associou “fazer uma coisa” às primeiras restrições de tamanho e depois explicou por que fluxos de texto se tornaram interfaces universais úteis tanto para programas quanto para pessoas.⁴ Sistemas de agentes redescobrem o mesmo padrão porque agentes precisam de superfícies inspecionáveis e componíveis.

Principais conclusões

Para quem constrói agentes: - Prefira ferramentas pequenas, com entradas explícitas, saídas explícitas e artefatos em arquivos simples, antes de adicionar APIs amplas ou grandes esquemas de ferramentas. - Trate caminhos de arquivos, diffs, logs e testes como superfícies de segurança. O agente pode inspecioná-los, o revisor pode inspecioná-los e a automação pode bloqueá-los ou aprová-los.

Para equipes de software: - Software pequeno reduz o custo de revisão. Um revisor consegue entender uma ferramenta de 400 linhas e seus testes de uma vez; um framework inchado força confiança onde deveria haver evidência. - Mantenha o escopo de permissão perto da ação. Um comando pequeno pode rodar em modo somente leitura, escrever em uma única pasta ou negar acesso à rede. Um comando genérico quase sempre pede mais autoridade do que a tarefa exige.

Para líderes de produto: - Software pequeno não é nostalgia. É um padrão de governança para um mundo em que máquinas conseguem produzir código demais, rápido demais. - A barra deveria sair de “o agente consegue construir isso?” para “a equipe consegue verificar, assumir e reverter isso?”

Por que software pequeno voltou a ser relevante

O inchaço de software costumava parecer um problema de experiência do usuário: downloads lentos, uso pesado de memória, inicialização demorada, baterias drenadas e dispositivos antigos deixados para trás. Fits on a Floppy torna essa crítica visível por meio de um padrão físico intencional. Um selo de 1,44 MB transforma contenção em um teste que o usuário consegue entender.¹

Agentes de IA que programam mudam o motivo pelo qual a contenção importa. A máquina consegue produzir arquivos mais rápido do que um humano consegue lê-los. Essa velocidade enfraquece a qualidade quando o sistema ao redor trata volume como progresso. Um recurso de 2.000 linhas com quatro novas dependências pode parecer impressionante na transcrição e ainda assim aumentar mais a superfície de defeitos do que o valor do produto.

Software pequeno dá ao agente um alvo mais difícil e ao revisor um alvo melhor. O prompt pode pedir um executável, um formato de dados, um arquivo de teste e um caminho de reversão. O resultado deixa menos graus de liberdade. Um modelo ainda pode errar, mas o erro tem menos espaço para se camuflar.

Niklaus Wirth publicou um artigo chamado A Plea for Lean Software em 1995, muito antes de agentes de programação entrarem no fluxo de trabalho.⁵ O título ainda funciona porque a falha de fundo permanece: equipes gastam hardware, dependências e camadas de abstração para evitar decisões difíceis de design. Agentes reduzem o custo de adicionar código, então a recusa em adicionar código fica mais valiosa.

Contexto é orçamento de segurança

A segurança de agentes costuma ser tratada como um problema de permissão: quais comandos o agente pode executar, quais arquivos pode editar, quais segredos pode ver, quais chamadas de rede pode fazer. Essas perguntas importam. Mas elas não cobrem a primeira restrição que o agente encontra enquanto trabalha: contexto.

O guia de boas práticas de Claude Code da Anthropic diz que a janela de contexto guarda a conversa, mensagens, arquivos lidos e saída de comandos, e que uma única sessão de depuração pode consumir dezenas de milhares de tokens.² O guia também alerta que Claude pode começar a esquecer instruções anteriores ou cometer mais erros conforme a janela de contexto se enche.²

Esse alerta transforma tamanho em uma propriedade de segurança. Uma base de código pequena permite que o agente leia a superfície relevante sem afogar a sessão em arquivos irrelevantes. Uma ferramenta pequena permite que o agente mantenha a função, os testes, o modelo de permissão e os casos de borda à vista ao mesmo tempo. Um diff pequeno permite que o revisor encontre a mudança real em vez de vasculhar uma pilha de movimento gerado.

O orçamento de contexto tem três limites práticos:

Sistemas grandes ainda podem ser seguros. Eles precisam de decomposição mais forte. Se uma base de código não pode ser pequena, a superfície voltada ao agente deve ser pequena: um pacote, um subsistema delimitado, um comando público, um alvo de teste, uma pasta sob responsabilidade clara.

Arquivos simples vencem estado oculto

A história oral de McIlroy dá à velha lição um caráter prático e afiado. Ele descreveu “fazer uma coisa” como um princípio nascido da falta de espaço para fazer mais de uma coisa, e depois disse que as equipes mantiveram o padrão mesmo quando a restrição original passou.⁴ Ele também explicou por que fluxos de texto importavam: dados legíveis por humanos tornavam a depuração menos trabalhosa, e evoluir campos de texto exigia menos trabalho do que alterar layouts binários fixos.⁴

Agentes precisam do mesmo tipo de superfície. Um arquivo pode ser listado, pesquisado, comparado, lido em trechos, commitado, revertido, validado por lint e revisado. Estado oculto em IDE, bancos de dados locais opacos e ferramentas hospedadas amplas podem ser úteis, mas obrigam o agente e o revisor a confiar em uma superfície que eles não conseguem inspecionar facilmente.

Um artigo do arXiv de janeiro de 2026 conecta a abstração de arquivos do Unix a sistemas de IA com agentes. O artigo argumenta que abstrações semelhantes a arquivos e especificações baseadas em código condensam recursos diversos em interfaces consistentes e componíveis, e podem ajudar sistemas de agentes a se tornarem mais sustentáveis, auditáveis e operacionalmente sólidos.⁶ A análise da Oracle sobre memória de agentes faz uma distinção relacionada: interfaces de sistema de arquivos funcionam bem porque modelos já entendem superfícies nativas de desenvolvimento, como repos, pastas, Markdown, logs e interações CLI, enquanto o armazenamento durável ainda pode pertencer a um banco de dados.⁷

A distinção importa. “Use arquivos” não significa “guarde tudo em texto solto para sempre.” O padrão mais seguro separa a interface do agente do substrato de armazenamento:

O agente deve ver a menor interface útil. O produto pode manter a camada de armazenamento mais forte por baixo.

Menos ferramentas significa menos permissões

O artigo sobre autorização de MCP deixou a lição explícita: validar um bearer token não prova que um usuário pode chamar todas as ferramentas por trás do servidor.⁸ Software pequeno aplica a mesma ideia antes, no design. Uma ferramenta menor pede autoridade mais restrita.

A documentação de shell local da OpenAI declara o risco sem rodeios: executar comandos de shell arbitrários pode ser perigoso, e quem constrói esses sistemas deve usar sandboxing ou adicionar listas estritas de permissão e bloqueio antes de enviar comandos ao shell do sistema.³ O guia de Claude Code da Anthropic dá um exemplo prático em escala: ao distribuir trabalho por arquivos, use restrições de ferramentas permitidas para que execuções sem supervisão não façam mais do que o trabalho exige.²

Um comando pequeno é mais fácil de restringir:

Ferramentas amplas tendem a acumular permissões amplas. Um comando genérico de “publicar” pode tocar conteúdo, traduções, linhas de banco de dados, limpeza de cache, logs de deploy e analytics. Às vezes o comando de lançamento faz sentido. O padrão mais seguro constrói o lançamento a partir de comandos menores, com barreiras explícitas entre eles, e só automatiza a sequência depois que cada etapa tem evidência.

O objetivo não é tornar o trabalho mais lento. O objetivo é tornar a autoridade visível.

Testes devem caber na ferramenta

A primeira seção de boas práticas da Anthropic diz aos usuários para dar a Claude uma forma de verificar o próprio trabalho: testes, capturas de tela, saídas esperadas e verificações por comando.² Software pequeno torna esse conselho concreto. Uma ferramenta pequena pode carregar um contrato de verificação pequeno.

Para software construído por agentes, o contrato deve caber em uma tela:

Inputs:
- one source path
- one output path
- one optional flag

Allowed effects:
- read source path
- write output path
- no network unless --verify-sources is present

Evidence:
- unit tests for parsing
- fixture test for output
- dry-run output for the exact file
- git diff limited to owned paths

O contrato importa porque agentes conseguem satisfazer pedidos vagos com facilidade demais. “Melhore o pipeline” convida retrabalho arquitetural desnecessário. “Adicione uma flag de dry-run a este comando e prove que a saída não escreve arquivos” cria um caminho de evidência.

Testes também ficam mais rápidos quando as ferramentas permanecem pequenas. Testes rápidos mudam o comportamento do agente. O agente os executa com mais frequência, vê falhas enquanto o código relevante ainda está no contexto e corrige causas-raiz antes que a transcrição se desvie. Testes lentos empurram o modelo para adivinhar ou narrar o que teria executado.

Pequeno não significa incompleto

Software pequeno pode falhar de formas previsíveis:

O selo do disquete mede tamanho. A segurança de agentes precisa de outra medida: um revisor consegue entender o comportamento, o escopo de permissão e o caminho de evidência antes de aprovar a mudança?

Essa pergunta permite que uma ferramenta ultrapasse 1,44 MB. Ela recusa a parte que importa: escopo acidental. Um app nativo seguro e sem glamour de 20 MB pode ser melhor do que um script de 200 KB que chama um instalador sem revisão. Software pequeno só serve à segurança quando a contenção chega ao caminho real de execução.

Um placar de pequenez para trabalho com agentes

Antes de um agente construir ou modificar uma ferramenta, avalie o trabalho em cinco dimensões. A ideia não é punir sistemas grandes. A ideia é encontrar as superfícies que precisam de decomposição antes que o agente comece a escrever.

Uma célula vermelha não significa que o trabalho deve parar. Uma célula vermelha significa que o agente precisa de uma unidade de trabalho menor. A segurança melhora quando o formato da tarefa torna o comportamento correto fácil de provar.

O padrão prático

Os sistemas construídos por agentes em que eu confio compartilham um formato:

1. Um comando restrito faz um trabalho.
2. Arquivos simples carregam entradas, saídas, logs, planos e pacotes de revisão.
3. Permissões correspondem aos efeitos reais do comando.
4. Testes rodam rápido o bastante para o agente usá-los durante a sessão.
5. O diff fica pequeno o bastante para uma pessoa revisar.
6. O caminho de lançamento compõe comandos pequenos em vez de esconder autoridade ampla em um único botão.

O manifesto sem build descreveu a mesma preferência pelo lado da pilha web: menos camadas de build, menos artefatos gerados e menos distância entre fonte e ambiente de execução.⁹ A versão de segurança para agentes diz a mesma coisa pensando em outro leitor. Cada camada extra dá à máquina mais um lugar para produzir trabalho plausível que o humano não consegue verificar rapidamente.

Software pequeno transforma contenção em infraestrutura. Um módulo mais restrito melhora o encaixe no contexto. Um arquivo mais simples melhora a auditabilidade. Um teste mais rápido melhora o feedback. Um conjunto menor de permissões melhora o controle do raio de impacto. Um diff menor melhora o julgamento humano.

FAQ: software pequeno e segurança de agentes

Software pequeno torna agentes de IA que programam seguros?

Não. Software pequeno reduz a área que agentes podem entender errado ou danificar. Equipes ainda precisam de sandboxing, listas de permissão e bloqueio, testes, revisão de código, limites de credenciais e barreiras de lançamento. Software pequeno torna esses controles mais fáceis de aplicar e mais difíceis de contornar por acidente.

Quão pequena deve ser uma ferramenta voltada a agentes?

O limite útil é a facilidade de revisão, não a contagem de bytes. Uma boa ferramenta voltada a agentes tem um trabalho, um contrato pequeno de entrada e saída, um perfil claro de permissões, testes rápidos e um diff que um revisor consegue entender de uma vez.

A memória de agentes deve usar arquivos ou banco de dados?

Use arquivos para a interface quando o agente precisa inspecionar, pesquisar, comparar e escrever artefatos. Use um banco de dados quando o produto precisa de concorrência, indexação, controle de acesso, durabilidade ou estado entre usuários. A arquitetura mais segura separa a interface voltada ao agente do substrato de armazenamento.⁷

Onde MCP entra?

MCP entra quando o agente precisa de uma ponte tipada para ferramentas ou dados externos. MCP não elimina a necessidade de comandos pequenos, permissões com escopo definido e autorização no nível da ação. O servidor ainda precisa decidir se o sujeito específico pode executar a ação específica.⁸

Fechamento

IA torna código barato. Código barato aumenta o valor da recusa.

Software pequeno dá à recusa um formato que a máquina consegue obedecer: um comando, uma saída, uma fronteira de permissão, um caminho de teste, um diff. O formato não garante qualidade. Ele torna o trabalho fraco mais visível.

O disquete não é mais a restrição. A inspecionabilidade é.

Referências