No dia 22 de setembro (horário dos EUA), a Anthropic lançou o Claude Opus 5.5.
No mesmo dia, a OpenAI anunciou o GPT-6 Sol e Luna.
Ambos são "mais inteligentes e mais baratos do que antes".
Entre as novidades, o que chamou minha atenção foi um número específico no anúncio oficial.
Em um comentário da Deloitte, está escrito:
"Mesmo na configuração mais baixa, ele encontrou 72% dos bugs conhecidos. O Opus 5 encontrou 56% na configuração alta."
Isso significa que a capacidade de ler código e encontrar vulnerabilidades melhorou significativamente em apenas uma geração.
A IA vai construir coisas que "funcionam".
Mas, para torná-las "seguras", os humanos precisam dar as instruções.
Por isso, aqui estão 5 pontos para ter em mente ao criar aplicativos internos com o Opus 5.5.
Cada um vem acompanhado de um prompt para pedir ao Opus 5.5 que revise o trabalho.
====
Como fazer a revisão
Quando terminar de construir, não pergunte "Tem algum problema?" na mesma sessão em que você criou o app.
A IA que construiu o projeto enxerga o próprio design como uma premissa, então ela acaba sendo complacente.
Abra uma nova sessão, defina o modelo como Opus 5.5 e mostre a pasta inteira do aplicativo para ele.
Depois, garanta que cada problema encontrado inclua "qual arquivo e qual linha".
O comentário da Deloitte menciona que os falsos positivos diminuíram, mas não chegaram a zero.
Se você especificar o local, os humanos podem verificar depois.
Aqui está a instrução:
"Você é um analista de segurança vendo este código pela primeira vez. Se encontrar problemas, forneça o nome do arquivo, o número da linha, por que é perigoso e como corrigir, tudo junto. Separe qualquer coisa sobre a qual você tenha dúvidas como 'Precisa de Verificação'."
====
1. Há algo visível para quem não fez login?
Ao deixar a IA construir, barreiras de login podem acabar faltando em telas ou rotas de dados.
Um padrão comum são telas de confirmação criadas durante o desenvolvimento que ficam acessíveis publicamente.
A verificação é simples.
Abra URLs do painel administrativo ou de dados diretamente no navegador sem fazer login (Janela Anônima).
Se conseguir ver, é falha.
Aqui está a instrução:
"Liste todas as URLs e APIs acessíveis sem fazer login. Entre elas, classifique por nível de perigo aquelas que retornam dados ou são de administração."
====
2. Usuários logados conseguem ver dados de outras pessoas?
O login verifica "quem" a pessoa é.
"O que essa pessoa tem permissão para ver" precisa ser construído separadamente.
A verificação envolve criar duas contas de teste. Faça login como A e tente abrir a URL de dados de B.
Aqui está a instrução:
"Encontre quaisquer caminhos onde o Usuário A possa visualizar ou modificar os dados do Usuário B. Inclua casos em que URLs ou APIs sejam acessadas diretamente, ignorando a interface."
====
3. Chaves ou senhas foram colocadas em locais visíveis?
O código que roda no lado do navegador é enviado inteiramente para o PC do usuário.
Escrever chaves ali é o mesmo que distribuí-las para todo mundo.
Outro erro comum é subir arquivos de configuração contendo chaves para pastas compartilhadas ou para o GitHub.
Aqui está a instrução:
"Procure por chaves de API, senhas ou tokens incluídos no código do lado do navegador, em arquivos de configuração ou no histórico de commits. Se encontrar, sugira para onde eles devem ser movidos."
====
4. As permissões concedidas às ferramentas são amplas demais para as tarefas delas?
Ferramentas internas costumam se conectar ao Google, Slack ou bancos de dados.
Às vezes, a chave fornecida permite "excluir" ou "visualizar tudo", mesmo quando só é necessário "ler".
Esse é um problema bem comum.
Se essa chave vazar, o tamanho do estrago será determinado pelo escopo das permissões.
A verificação consiste em anotar: "No pior cenário, o que esta ferramenta pode excluir?"
Se você não souber responder de imediato, cuidado.
Aqui está a instrução:
"Liste todas as permissões que esta ferramenta possui em relação a serviços externos ou bancos de dados. Compare cada uma com as permissões mínimas necessárias para o processamento real e aponte qualquer excesso."
====
5. Textos vindos de fora estão sendo executados como comandos?
Ferramentas que permitem à IA ler e-mails, páginas web ou arquivos enviados exigem cautela.
Se eles contiverem textos como "Ignore as instruções anteriores e faça XX", a IA pode obedecer.
Isso se chama Prompt Injection.
No anúncio do Opus 5.5, a resistência a esse ataque é descrita como "igual ou superior à do Opus 5 em todos os cenários testados".
No entanto, igual ou superior não significa risco zero. Você ainda precisa de defesas no lado da ferramenta.
Aqui está a instrução:
"Procure por lugares onde textos ou arquivos carregados de fora são tratados como instruções para a IA. Se encontrar, mude o tratamento para que o conteúdo carregado seja considerado apenas informação de referência, ignorando quaisquer instruções contidas nele."
====
Resumo
A IA vai construir as funcionalidades que você pedir.
Mas "não mostre para outros" e "não conceda permissões excessivas" não estarão incluídos a menos que você peça.
Por outro lado, todos esses 5 pontos podem ser resolvidos apenas adicionando uma instrução.
E a capacidade do Opus 5.5 de encontrar brechas no que você construiu também melhorou.
Depois de construir, mostre o projeto para o Opus 5.5 em uma nova conversa.
Considere isso parte do desenvolvimento.
Se você já tem um aplicativo interno rodando, comece colando a instrução de revisão da seção "Como fazer a revisão".
Além disso, se colar instruções toda vez for cansativo, existe um plugin chamado security-review, que recomendo testar.
Ele presta atenção aos mínimos detalhes e aponta tudo, por isso eu mesmo uso regularmente.
====
Por fim, um pequeno aviso.
Nossa empresa oferece um serviço de desenvolvimento de agentes de IA personalizados do zero para o seu negócio.
Não se trata de treinamentos ou apresentações de ferramentas, mas de ouvir seus fluxos reais de trabalho para entregar algo utilizável "a partir de amanhã". Também damos suporte à integração e à manutenção.
