Na segurança de agentes de IA, o modelo de linguagem nunca acessa diretamente o seu banco de dados. Quem executa qualquer ação é o Orquestrador, o software que recebe o pedido, consulta a IA e chama os sistemas com uma credencial própria. Proteger um agente é, portanto, proteger essa identidade que executa, e não o modelo.
A seguir, a arquitetura de um agente em três camadas, o fluxo de uma ação real e os três riscos que a edição 2026 do OWASP Top 10 para aplicações de LLM coloca no topo.
Existe um mito no mercado de que a Inteligência Artificial seria uma entidade onipresente, navegando pelos cabos da rede corporativa para coletar dados. Para projetar a segurança dos próximos anos, portanto, é preciso desmistificar o que a palavra “Agente” realmente significa.
O que é um agente de IA, na prática?
O que o mercado chama de “Agente de IA” não é um software único e mágico, e sim um ecossistema com três partes fundamentais. Cada uma cumpre um papel distinto na cadeia de segurança.
| Camada | O que é | Papel na segurança |
|---|---|---|
| Motor Cognitivo (o “cérebro”) | Os modelos de linguagem (LLMs), em nuvem ou hospedados localmente. Recebem contexto, processam a lógica e devolvem texto, inclusive um JSON pedindo que alguém execute uma ação. | Não possui “mãos” para clicar em botões, abrir conexões ou consultar bancos. Nunca executa nada por conta própria. |
| Orquestrador (o agente de verdade) | O software da sua TI ou de terceiros que recebe o pedido do usuário, envia o contexto ao Motor Cognitivo, lê a resposta e executa a ação. | É o sujeito da relação, ou seja, a identidade não-humana que pede acesso. Nenhum pedido do modelo vira operação real sem passar por ele. |
| Ferramentas (as APIs e o MCP) | Seus sistemas críticos, como ERPs, CRMs e bancos legados. O MCP (Model Context Protocol) padroniza como o ecossistema de IA descobre e chama cada ferramenta, sem substituir esses sistemas. | O próprio servidor MCP é uma carga de trabalho que guarda credenciais de acesso, portanto também precisa de identidade. |
Um erro comum de arquitetura aparece justamente no Orquestrador: ele não é a autoridade da política. Quem decide o que ele pode fazer é o mecanismo de política, e quem efetivamente barra a ação indevida precisa ser um ponto de aplicação externo ao agente, como o gateway de API, o servidor MCP ou a própria aplicação de destino validando o token. A razão é simples: se a regra morar dentro do agente, quem comprometer o agente compromete a regra junto.
Como um agente de IA executa uma ação com segurança?
O modelo apenas devolve a intenção em texto, enquanto o Orquestrador executa a ação apresentando uma credencial com escopo restrito, que a aplicação de destino valida antes de liberar. Veja o fluxo com um pedido real: “transfira 100 reais para o fornecedor X”.
Primeiramente, o Orquestrador repassa o pedido ao Motor Cognitivo. Em seguida, a IA processa a intenção e responde, em texto, algo como “para concluir a tarefa, chame a API financeira e efetue a transferência”. Repare que a IA não realiza a transferência.
Quem executa a ação é o Orquestrador, que chama o sistema interno apresentando a própria credencial, carregada apenas com os escopos concedidos pela política. A aplicação de destino confere esse token e decide se libera ou nega. Tratando-se de uma transferência financeira, a política ainda exige aprovação humana antes de efetivar a operação.
Por fim, concluída a chamada, o Orquestrador captura o comprovante e o devolve à IA para formular a resposta final.
E quando o provedor do modelo executa a chamada?
Existe uma exceção que, em vez de contradizer a tese, a deixa mais afiada. Hoje já é possível conectar servidores MCP remotos diretamente pela API dos grandes provedores de modelo. Nesse desenho, quem abre a conexão HTTP com a ferramenta é a plataforma do provedor, e não o Orquestrador que roda no seu data center.
O modelo continua sem executar nada. O que muda é de quem é a identidade que executa e onde fica a fronteira de confiança. Uma vez que essa fronteira sai do seu ambiente, você deixa de controlar quem chama as suas APIs em nome do agente. Trata-se de uma decisão de arquitetura, e ela precisa ser tomada de olhos abertos.
Onde a segurança de agentes de IA deve focar?
O foco é o Orquestrador, detentor das “mãos” que executam operações críticas, que precisa de uma identidade de carga de trabalho (Workload Identity) blindada, atestada criptograficamente, sem senhas estáticas em arquivos .env que, salvos em disco, viram alvo fácil caso o servidor seja comprometido. Essa é a fundação sobre a qual a camada de software se apoia.
Autenticado o Orquestrador, restam três riscos que a edição 2026 do OWASP Top 10 para aplicações de LLM posiciona, não por acaso, nas primeiras colocações:
| Risco (OWASP LLM 2026) | O que é | Como mitigar |
|---|---|---|
| Prompt Injection (LLM01) | O modelo é manipulado por conteúdo malicioso e o Orquestrador obedece cegamente. É o clássico confused deputy: um componente legítimo usando os próprios privilégios para executar a ordem de um terceiro. | Manter a autorização fora do modelo, com regras de negócio e aprovação humana para ações de alto impacto, em vez de apostar em filtros de prompt. |
| Divulgação de informações sensíveis (LLM02/vazamento de dados) | O Orquestrador empurra dados para dar contexto à IA. Mascarar ou tokenizar é pseudonimização, e dado pseudonimizado continua sendo dado pessoal para a LGPD. | Tratar o dado sensível antes do envio. Só a anonimização real retira o dado do escopo da lei. |
| Excesso de autonomia (LLM03) | O agente tende a receber mais permissão do que a tarefa exige, apenas para “não travar”. | Escopo mínimo e token amarrado ao destino. A especificação do MCP já obriga o servidor a validar que o token foi emitido para ele. |
Autenticação responde “quem é você”. Autorização responde “o que você pode fazer agora”. Um agente de IA precisa das duas, e nenhuma delas pode morar dentro do modelo.
