Agente de IA já não é só uma janelinha esperta respondendo pergunta. No fluxo real de trabalho, ele lê repositório, abre issue, chama ferramenta, escreve arquivo, roda comando, busca página, resume e-mail, conversa com API e, em alguns casos, age com a credencial de alguém.
É aí que a conversa muda de tom. Enquanto a IA só sugeria texto, o pior erro costumava ser uma resposta ruim. Quando ela passa a executar ação, o erro pode virar alteração de arquivo, vazamento de dado, comando indevido ou uma automação rodando fora do limite esperado.
O ponto não é fazer pânico com agente de IA. É parar de tratar ferramenta autônoma como se fosse autocomplete com fantasia de produtividade.
O risco aparece quando texto vira ação
A Microsoft publicou um caso bem didático sobre falhas em frameworks de agentes: uma injeção de prompt deixou de ser apenas um problema de conteúdo e chegou perto de execução remota de código. Em uma das vulnerabilidades analisadas, uma função que deveria ficar fora do alcance do modelo acabou exposta como ferramenta chamável pelo agente. O resultado: a IA podia ser induzida a escrever arquivo em local perigoso do host.
Traduzindo para o dia a dia: o modelo não precisa “querer invadir” nada. Basta receber instruções maliciosas, ter uma ferramenta poderosa demais disponível e não existir uma camada técnica fazendo a checagem fora do prompt.
Essa é a diferença entre chatbot e agente. O chatbot responde. O agente responde e faz.
Prompt não é perímetro de segurança
Uma armadilha comum é achar que dá para resolver tudo com uma frase no system prompt: “não acesse segredos”, “não rode comando perigoso”, “não envie dados externos”. Isso ajuda, mas não é fronteira de segurança.
As recomendações da OWASP para agentes de IA batem em uma tecla simples: permissões precisam ser aplicadas no componente de execução, não só no texto que orienta o modelo. Se uma ação é destrutiva, administrativa, financeira ou pública, a aprovação precisa estar vinculada à ação exata, com escopo, usuário, recurso, parâmetros e validade.
Em português sem cerimônia: se o agente consegue fazer besteira, alguma camada fora dele precisa impedir a besteira.
O problema não é usar agente. É usar com privilégio demais
No mundo dev, isso fica ainda mais sensível. Coding agents conseguem ler código privado, instalar dependência, alterar múltiplos arquivos, rodar testes, chamar MCP server, abrir PR, acessar rede e, dependendo da configuração, tocar em credenciais do ambiente.
É produtivo? Pode ser muito. Mas também junta três ingredientes perigosos:
- acesso a dados privados;
- exposição a conteúdo não confiável, como issues, READMEs, páginas e respostas de ferramentas;
- capacidade de agir usando permissões reais.
Por isso o debate de segurança sai do “a IA hallucina?” e entra em perguntas mais operacionais: ela consegue ler .env? Consegue mandar request para qualquer domínio? Consegue fazer git push? Consegue instalar pacote sem revisão? Consegue usar a credencial pessoal do dev?
O checklist mínimo para time de TI
Para um time pequeno, não precisa começar com um comitê gigantesco de governança. Mas precisa de alguns limites antes de colocar agente com acesso real no fluxo.
1. Rodar em sandbox de verdade
Permissão de “pedir antes” é útil, mas isolamento é outra coisa. Sempre que possível, rode agente em container, VM descartável, ambiente cloud controlado ou sandbox com limite claro de filesystem e rede. O pior caso precisa caber dentro de uma caixa.
2. Tirar segredo do caminho
Se o agente consegue ler variável de ambiente, arquivo .env, chave SSH, token cloud ou cookie de sessão, uma injeção bem-sucedida pode transformar produtividade em incidente. Segredo deve ficar fora do ambiente do agente ou ser entregue com escopo curto, revogável e específico para a tarefa.
3. Dar permissão por tarefa, não por confiança abstrata
“Esse agente é bom” não é política de acesso. O ideal é permitir só o que a tarefa precisa: ler uma pasta, rodar um comando de teste, alterar arquivos do projeto, acessar domínios específicos. O restante fica bloqueado ou pede aprovação.
4. Registrar o que aconteceu
Quando algo estranho acontece, o log precisa responder: qual foi o prompt, que ferramenta foi chamada, quais arquivos mudaram, que comando rodou, qual domínio foi acessado e quem aprovou. Sem isso, investigar agente vira arqueologia de terminal.
Isso também é assunto de carreira
Para quem trabalha em TI, segurança de agente não é detalhe reservado para AppSec. Dev, suporte, infra, SRE, dados e liderança técnica vão esbarrar nisso porque a ferramenta está entrando no fluxo real antes de muita empresa amadurecer o processo.
Quem souber usar agente com bom senso vai ganhar velocidade. Quem souber usar agente com limite, log, sandbox e permissão bem pensada vai ganhar uma vantagem ainda maior: confiança operacional.
A pergunta madura não é “podemos usar IA no desenvolvimento?”. Essa fase já passou. A pergunta agora é: o que esse agente consegue fazer se alguém conseguir influenciar o que ele lê?
Se a resposta for “quase tudo que o dev consegue”, a conta está errada.
