A primeira onda de segurança de IA parecia muito com um WAF para LLMs: inspecionar o prompt, filtrar a saída, bloquear os padrões maliciosos óbvios.
Isso foi útil. E ainda é.
Mas foi construído para sistemas que, em sua maioria, conversavam.
Os agentes são diferentes. Eles usam ferramentas, chamam APIs, acessam dados e alteram coisas.
A confusão que continuo a ver é simples: muitas equipes pensam que proteger o modelo significa proteger o agente. Não é o caso.
A segurança de IA protege a conversa. A segurança de agentes protege a consequência.
O mercado tem usado "segurança de IA" como um termo genérico para quase tudo: injeção de prompt, jailbreaks, saídas inseguras, acesso a modelos, política de uso de IA, gateways de LLM, DLP básico e governança de modelos. Esses são problemas reais. Mas não são todo o problema.
Um chatbot conversa. Um agente age. Uma resposta ruim de um chatbot é um problema, mas uma ação ruim de um agente pode se tornar um incidente. Essa é a linha que a indústria ainda está aprendendo a traçar.
Um chatbot pode alucinar, vazar algo em uma resposta ou ser manipulado para dizer algo inseguro. Um agente pode fazer tudo isso, mas também pode chamar uma ferramenta, recuperar dados de clientes, emitir um reembolso, atualizar um ticket, alterar uma configuração, acionar um fluxo de trabalho ou tocar em um sistema que realmente opera o negócio.
O modelo não está mais apenas conversando. Ele está se tornando parte de um caminho de execução.
O agente não é uma coisa só. É um corpo.
A maneira mais fácil de explicar um agente é com o corpo humano. O LLM é o cérebro. Ele raciocina, interpreta a intenção e decide o que fazer a seguir. O prompt são os ouvidos. Ele recebe a solicitação. A resposta é a boca. Ela comunica o resultado de volta. As ferramentas e os servidores MCP são as mãos. Eles dão capacidades ao agente. As APIs são os botões. É assim que o agente interage com o negócio. Os sistemas por trás dessas APIs são o que os botões controlam.
A maioria das conversas sobre segurança de IA foca nos ouvidos, no cérebro e na boca. O prompt era malicioso? A resposta era segura? O modelo disse algo que não deveria? Perguntas importantes. Mas incompletas.
Porque as mãos ainda podem ter as chaves.
Você pode colocar um capacete no cérebro, instalar um filtro nos ouvidos e observar o que a boca diz. Mas se as mãos ainda puderem pressionar o botão de reembolso, exportar a lista de clientes, atualizar a conta ou chamar uma API interna com autorização fraca, você ainda terá um problema sério.
Você protegeu a conversa. Você não protegeu a ação.
O prompt pode parecer limpo enquanto o caminho é perigoso.
Imagine um agente de suporte ao cliente. Um cliente pergunta: “Fui cobrado duas vezes. Pode ajudar?” O prompt parece normal. O modelo decide ajudar. O agente chama uma ferramenta de faturamento. A ferramenta de faturamento chama uma API interna. A API retorna dados da conta. O agente emite um crédito. A resposta final parece inofensiva: “Revisei sua conta e emiti um crédito.”
Da camada do modelo, tudo pode parecer bem. Nenhum jailbreak óbvio. Nenhuma saída tóxica. Nenhum dado sensível na resposta final. Mas o caminho intermediário pode contar uma história muito diferente.
Talvez a ferramenta de faturamento fosse excessivamente permissiva. Talvez o servidor MCP tivesse uma chave de API codificada. Talvez a API não tivesse limite de taxa. Talvez a API de reembolso nunca tenha sido projetada para acesso autônomo.
Agora imagine isso acontecendo na velocidade da máquina centenas de milhares de vezes antes que alguém percebesse.
O modelo não disse nada perigoso. O agente agiu e impactou a receita.
Essa é a lacuna. O risco não está apenas no prompt ou na resposta. Está no caminho de execução entre eles.
Visibilidade, governança e proteção em tempo de execução não são a mesma coisa.
A segurança de agentes tem três funções: visibilidade, governança e proteção em tempo de execução. A visibilidade informa o que existe, a governança informa o que deve ser permitido, e a proteção em tempo de execução informa o que está realmente acontecendo quando o agente está ativo.
A visibilidade pode informar quais agentes existem, onde eles são executados, quais ferramentas eles usam e quais APIs eles podem acessar. A governança pode informar quais ferramentas estão habilitadas, quais identidades são usadas, quais políticas estão faltando e quais ações são excessivamente permissivas. A proteção em tempo de execução responde à pergunta em tempo real: O agente está fazendo algo inseguro neste exato momento?
Um painel não é proteção em tempo de execução. Um inventário não é proteção em tempo de execução. Um documento de política não é proteção em tempo de execução. Eles são necessários, mas não são o mesmo que observar as mãos enquanto se movem.
Agentes precisam de visibilidade. Agentes precisam de governança. Mas os agentes também precisam de freios.
O código informa o que foi construído. A configuração informa como é governado. O tempo de execução informa o que aconteceu.
Para entender o risco de agentes, você precisa de três fontes de verdade.
O código mostra o que foi construído: segredos codificados, ferramentas inseguras, verificações de autorização ausentes, padrões de API arriscados.
A configuração mostra como é governado: quais ferramentas estão habilitadas, quais identidades são usadas, quais políticas se aplicam, quem o possui e quais APIs são acessíveis.
O tempo de execução mostra o que aconteceu: qual prompt levou a qual chamada de ferramenta, qual ferramenta chamou qual API, quais dados retornaram e qual ação foi tomada.
Isso importa porque nem todo agente vive dentro de uma plataforma de IA gerenciada e organizada. O caso mais fácil é um plano de controle conhecido onde você pode extrair a configuração e construir um painel útil. Útil? Sim. Suficiente? Não.
O caso mais difícil é um agente que se parece com software: um LLM rodando em EC2 ou Kubernetes, usando um servidor MCP personalizado, chamando APIs internas por trás de um balanceador de carga F5, e acessando sistemas mais antigos nunca projetados para acesso autônomo.
Isso não é um produto de IA organizado. É uma aplicação em produção.
E como qualquer aplicação em produção, você precisa do caminho completo: do prompt ao modelo, do modelo à ferramenta, da ferramenta à API, da API aos dados e vice-versa.
Esse é o grafo agêntico: o que foi construído, como foi governado e o que realmente aconteceu.
A pergunta deve mudar.
“Você protege a IA?” agora é uma pergunta fraca e insuficiente. Na verdade, quase todo mundo pode dizer sim.
A melhor pergunta é: onde sua visibilidade termina? Você vê o modelo, ou também as ferramentas e APIs? Você oferece visibilidade, governança e proteção em tempo de execução, ou apenas um deles? Você consegue seguir o caminho do prompt à ferramenta, da ferramenta à API e à ação subsequente? Você consegue proteger um agente rodando como uma carga de trabalho normal em EC2, Kubernetes, contêineres, VMs ou on-premise? Você consegue conectar código, configuração e tempo de execução em uma única visão?
E talvez o mais importante: onde sua resposta se torna: “Não vemos essa parte”?"
Todo controle de segurança tem um limite. Bons fornecedores sabem onde esse limite está. Grandes equipes de segurança perguntam diretamente por ele.
Os agentes ainda têm as chaves do carro.
A primeira onda de segurança de IA foi necessária. Ela nos deu guardrails para prompts, modelos e saídas. Mas os agentes mudaram a questão da segurança.
Não basta mais perguntar: “O que o modelo disse?” Temos que perguntar o que o agente fez, qual ferramenta usou, qual API chamou, quais dados retornaram, qual ação foi tomada, se era esperada, se era permitida e se era segura.
Essa é a linha entre a segurança de IA e a segurança agêntica.
E agora, muitas empresas têm protegido o modelo enquanto os agentes ainda têm as chaves do carro.
Pronto para ver seu Grafo de Segurança Agêntica? A Salt Security está oferecendo uma avaliação gratuita de segurança agêntica para que você possa mapear toda a sua superfície de ataque agêntica em minutos, não em meses. Obtenha sua avaliação gratuita em salt.security/agentic-assessment