Segurança antes de colocar no ar

Dá para construir software com Claude Code ou Codex sem entender de segurança. O que não dá é confundir ter construído alguma coisa com saber se aquilo aguenta o mundo real.

Este é o mínimo que vale pedir para a IA revisar antes de qualquer projeto entrar no ar.

1. Quem acessa o quê

Se alguém não deveria conseguir fazer algo, a trava precisa viver no backend. Interface esconde, backend impede.

2. Onde estão as chaves

Nada de API key, senha, token, credencial de banco, chave privada ou secret dentro do código ou de repositório público. Isso a maioria já sabe.

O que escapa é onde essas chaves vazam sem ninguém reparar:

Chave exposta não se resolve apagando do código. Ela precisa ser revogada e trocada.

3. O que chega de fora

Todo dado que vem de fora é não confiável até prova em contrário: formulário, parâmetro de URL, API, upload, arquivo, texto digitado por usuário e dado que vem de outra integração.

Peça a revisão nomeando o que procurar: SQL injection, XSS, command injection, manipulação de parâmetro e upload de arquivo malicioso.

4. A configuração

Boa parte das brechas nunca esteve no código.

Um projeto com código decente cai por uma variável de ambiente errada.

5. Do que o projeto depende

Seu código carrega dezenas ou centenas de bibliotecas que você não escreveu.

Quanto mais software você importa, maior a superfície que alguém pode atacar.

6. O que vai para o log

Log existe para você descobrir que algo deu errado, e vira problema quando guarda o que não devia.

Log sem alerta não é monitoramento.

7. Como o sistema falha

Pergunte o que acontece quando uma API externa cai, quando o banco responde algo inesperado, quando chega um parâmetro que não deveria existir, quando a autenticação falha e quando a permissão não pode ser verificada.

Em todos esses casos, o sistema precisa fechar. O erro que libera acesso, expõe informação ou executa a ação mesmo assim é o mais caro de todos.

Quando é a IA que constrói

Os sete pontos acima valem para qualquer software. Estes três nasceram com os agentes.

8. Até onde o agente alcança

Claude Code, Codex e companhia fazem muito mais do que escrever código. Eles chegam em arquivo, terminal, repositório, banco, API, serviço externo, credencial e em toda ferramenta que você conectar.

A pergunta a fazer para cada acesso é se ele é necessário para o trabalho. Quando a resposta for não, corte. Acesso amplo transforma um erro pequeno em incidente grande.

9. Instrução maliciosa chegando pela porta da frente

Se o seu sistema usa IA para ler email, documento, página da internet, arquivo enviado por usuário, ticket ou mensagem, você precisa considerar prompt injection.

Um texto externo pode tentar convencer o modelo a revelar informação, executar ação, chamar ferramenta, ignorar instrução ou alcançar dado que não deveria.

10. O que o agente faz sozinho

Existe uma distância enorme entre a IA sugerir uma alteração e a IA alterar produção.

Para ação de alto impacto, exija aprovação humana:

O controle acompanha o estrago que a ação pode causar.

Quem responde por isso

Antes de um projeto ir para o ar, alguém precisa saber responder quem pode criar, quem pode acessar, quem pode alterar, quem pode publicar, quem revisa, quem enxerga os dados e quem percebe quando algo dá errado.

Política de segurança perde o sentido quando qualquer pessoa consegue montar uma integração com o banco de produção usando um agente. Isso é governança, e ela ficou mais urgente justamente porque a IA democratizou a capacidade de construir.

O prompt para copiar

Antes de colocar em produção, cole isto no seu agente:

Faça uma revisão completa de segurança deste projeto.

Analise autenticação, autorização, controle de acesso, exposição de
dados, secrets, APIs, validação de entradas, injection, dependências,
configurações, logs, tratamento de erros, infraestrutura e permissões.

Considere também os riscos específicos de aplicações que usam IA:
prompt injection, acesso do agente a ferramentas e dados, excesso de
permissões e possibilidade de executar ações de alto impacto.

Para cada problema encontrado, explique:
1. qual é a vulnerabilidade
2. como ela poderia ser explorada
3. qual seria o impacto
4. como corrigir
5. como testar se a correção funcionou

Os testes passarem não significa que o projeto está seguro. Procure
ativamente formas de contornar as proteções que já existem.

No fim, me dê uma lista priorizada por criticidade e diga quais
problemas precisam ser corrigidos antes de ir para produção.