Duas Falhas de Contenção, Mesma Semana. Ambas Implícitas Até Falharem.

Em uma semana, duas histórias chegaram à mesa que, na superfície, não têm nada em comum. A primeira: Patrick Hughes publicou o postmortem da PocketOS, em que um agente Cursor instruído a limpar arquivos não utilizados destruiu o banco de dados de produção e os backups. A segunda: a Apple removeu o aplicativo iOS do Replit da App Store, citando a diretriz 2.5.2, depois de quatro submissões em que o time do Replit fez exatamente o que os revisores da Apple sugeriram.

Um postmortem de banco de dados e agente, mais uma briga de revisão da App Store, não parecem a mesma história. São. Em ambos os casos, a fronteira que deveria ter impedido a falha existia apenas como suposição. Ninguém a desenhou. Ninguém a nomeou. Ninguém perguntou se era a fronteira que importava. O agente em um caso, e o revisor de plataforma no outro, trataram a fronteira implícita como se ela não estivesse ali. Em ambos os casos eles estavam corretos, porque ela de fato não estava.

A parte difícil da operação de agentes em 2026 não é deter um modelo malicioso ou alucinando. É reconhecer as fronteiras que você não se deu ao trabalho de desenhar, antes que algo apareça com permissão para atravessá-las.

Pocket: Duas Coisas no Mesmo Lugar

O relato de Hughes sobre o incidente da PocketOS é brutalmente específico. O time pediu a um agente Cursor para limpar arquivos não utilizados. O agente tinha acesso de escrita ao servidor de produção. O banco de dados de produção vivia nesse servidor. Os backups viviam no mesmo servidor, montados em um caminho que o agente conseguia ver. O agente fez o trabalho dele. Arquivos que ele considerou não utilizados, incluindo os arquivos do banco vivo e os tarballs de backup, foram removidos. A restauração era impossível porque a única fonte de restore tinha sido removida na mesma operação.

Leia a descrição da falha e dá quase para escrever o postmortem sozinho. Backups co-localizados são um anti-padrão conhecido desde os anos 1990. A novidade não é o erro de arquitetura. A novidade é quem o expôs.

Hughes propõe uma stack de contenção em seis camadas como resposta: agentes com credenciais mínimas, backups isolados, mudanças de schema com PR, varredura de dependências, limites de gasto em tempo de execução e confirmação humana em comandos destrutivos. A PocketOS tinha, pela contagem dele, duas das seis. As outras quatro eram as fronteiras implícitas de que o time não sabia depender: a suposição de que os backups estavam “em algum lugar seguro”, de que comandos destrutivos exigiam aprovação de alguém, de que a escrita em sistema de arquivos do agente nunca alcançaria dados de produção, e de que “limpeza” era uma operação delimitada.

Já escrevemos sobre a stack de contenção em quatro andares e sobre por que três falhas de autonomia compartilham o mesmo formato de raio de impacto. O caso PocketOS é a demonstração mais cara, até agora, da mesma lição: um único host implicitamente compartilhado é a mesma falha que uma única identidade implicitamente compartilhada. O agente não precisava ser malicioso. Não precisava alucinar. Bastou estar errado sobre escopo uma vez.

Apple e Replit: Um Wrapper Que a Regra Não Enxerga

A história Apple/Replit rima a partir do outro lado. O texto da Adaptive Software percorre a linha do tempo. Replit submete o Anything, um app iOS que permite ao usuário descrever um aplicativo e tê-lo gerado em tempo real. A Apple cita a diretriz 2.5.2: aplicativos não podem mudar funcionalidade depois da revisão. O time do Replit recorre, pede orientação, e ouve que deveria usar uma superfície de Safari preview para o conteúdo gerado. Eles reconstroem em torno dessa sugestão. Submetem de novo. São rejeitados de novo. Seguem a mesma sugestão por quatro submissões. São removidos.

Amjad Masad chama o raciocínio da Apple de mentira. A leitura mais dura é que o raciocínio da Apple é fiel à regra, e a regra foi escrita para um mundo que não contém o Anything. A diretriz 2.5.2 foi redigida para impedir que aplicativos enviassem um binário estático e o mutassem depois da revisão por meio de código baixado. Ela assume que a superfície revisável é o binário. Um wrapper que gera novos aplicativos em tempo de execução falha contra essa suposição. Não há binário estático para revisar no sentido relevante. O que a Apple olhar no dia da submissão não é o que o usuário vai rodar na terça.

Essa é a mesma falha da PocketOS, em outro domínio. A fronteira em que o processo de revisão da Apple confiava nunca foi desenhada. Os revisores assumiram que o binário equivalia ao produto. O Anything prova que a suposição está errada. Quando existe um wrapper guiado por LLM, “o aplicativo” deixa de ser uma unidade que se pode revisar inspecionando o artefato. O processo de revisão não foi construído para reconhecer que artefato e produto haviam se separado.

O texto da Adaptive registra que os 800 milhões de usuários semanais do ChatGPT da OpenAI agora têm um caminho alternativo para experiências em formato de aplicativo, o Model Context Protocol, que contorna a revisão nativa do iOS por completo. A fronteira que a Apple defendia também está sendo realocada. Se a App Store não consegue governar wrappers, os construtores migram para uma superfície em que produtos com formato de wrapper são cidadãos de primeira classe. A fronteira implícita vira fronteira inócua.

A Mesma Falha em Dois Domínios

Ponha os dois casos lado a lado e o padrão de falha compartilhado fica nítido.

A PocketOS tratou “o host” como unidade de segurança. Dados de produção e backups estavam ambos nele. A suposição implícita era que uma operação cujo escopo fosse “arquivos neste host” não cruzaria entre os dois papéis que esses arquivos exerciam. O agente não viu papéis. Viu arquivos. A fronteira entre dado vivo e dado de recuperação existia apenas na cabeça dos operadores.

A Apple trata “o binário” como unidade de revisão. Funcionalidade e código estão ambos dentro. A suposição implícita era que uma operação cujo escopo fosse “o binário no momento da submissão” diria aos revisores o que o usuário viveria. O wrapper não vê “momento da submissão” e “tempo de execução” como categorias diferentes. Vê um pipeline de geração. A fronteira entre código revisável e comportamento baixado existia apenas na cabeça dos revisores.

Em ambos os casos, o ator não era malicioso. O agente Cursor estava fazendo limpeza. O time do Replit estava construindo um produto. Os dois seguiram a especificação que receberam. Os dois cruzaram uma fronteira que existia apenas como suposição compartilhada entre os humanos do outro lado do sistema.

Esta é a parte da operação de agentes mais desconfortável de internalizar. Falhas de contenção em 2026 não são, em sua maioria, sobre o agente fazer algo errado. São sobre uma fronteira que nunca foi desenhada virar a fronteira que importava. As seis camadas de Hughes são uma lista de fronteiras que ele está forçando a virem para o aberto. O processo de revisão da Apple é uma fronteira que o formato da plataforma tornou parcialmente decorativa.

O Que Isso Significa Para a Revisão Arquitetural

Argumentamos no stack de contenção que os times de plataforma deveriam caminhar pelos quatro andares do edifício. As duas falhas desta semana afiam uma pergunta específica que esse caminho precisa fazer: quais fronteiras no seu sistema existem apenas como convenção não escrita entre os humanos que o construíram?

Uma lista curta de onde olhar:

A fronteira entre dado de produção e dado de backup. Se compartilham host, identidade, credencial ou ponto de montagem, são uma mesma coisa vestindo dois rótulos. A PocketOS é o aviso.

A fronteira entre o escopo de leitura e o escopo de escrita do agente. A maioria dos agentes recebe escrita em sistema de arquivos para fazer o trabalho. A maioria dos times não enumerou em quais diretórios o agente nunca deveria escrever e em quais nunca pode escrever. O primeiro é preferência. O segundo é política. O agente não distingue se você não distinguir.

A fronteira entre o que sua plataforma revisa e o que sua plataforma de fato entrega. Se o artefato inspecionado não é o artefato que os usuários rodam, sua revisão é teatro. O caso da Apple é a versão macro. A versão micro é a sua pipeline de CI aprovando uma imagem de container cujo comportamento em runtime é determinado por uma variável de ambiente que ninguém na auditoria consegue ver.

A fronteira entre o dono de uma credencial e o raio de impacto dessa credencial. Cobrimos isso na lacuna de disciplina operacional. O dono é a pessoa no organograma. O raio de impacto é tudo o que aquela credencial pode tocar. Os dois deveriam coincidir. Quase nunca coincidem.

A fronteira entre a postura da Apple quanto a vibe coding e os produtos que circulam em volta dela. Se a plataforma da qual você depende não consegue governar o formato de produto que você está construindo, a política daquela plataforma é informativa, não operacional. Planeje de acordo.

O Problema do Reconhecimento

O time da PocketOS não carecia de sofisticação técnica. O processo de revisão da Apple não carecia de rigor. Ambos tinham disciplinas operacionais adequadas para os problemas que haviam sido construídas para endereçar. Nenhum atualizou o seu modelo do que contava como fronteira a tempo de capturar o novo formato de falha.

Esse é o trabalho deste ano. Não é construir mais contenção. É reconhecer onde contenção está faltando porque a fronteira que ela imporia nunca foi desenhada. O agente não precisa ser malicioso. Não precisa alucinar. Precisa apenas encontrar uma fronteira implícita que você não tornou explícita. Sempre há pelo menos uma.

Os times que se sairão bem nos próximos dois anos de operação de agentes não serão os times com os controles mais estritos. Serão os times que rodarem o inventário de fronteiras antes que outra coisa o faça por eles.

Fontes

DEV Community / AgentGuard. “Your AI Agent Will Eventually Delete Prod.” Maio de 2026.
Adaptive Software. “The Wrapper and the Code.” Maio de 2026.

A Victorino projeta stacks de contenção para empresas antes que os agentes encontrem as fronteiras implícitas: contato@victorino.com.br | www.victorino.com.br