O modelo precisa mesmo tocar no sistema? Por que separar decisão e execução deixa Agentes mais controláveis

Quando um Agente de IA precisa consultar um CRM, enviar uma mensagem, criar um evento na agenda ou gerar uma cobrança, existe uma decisão arquitetural que parece pequena, mas muda bastante o nível de controle sobre o sistema: o próprio componente que raciocina também deve possuir as credenciais e executar diretamente essas ações?

Em muitas implementações, a resposta acaba sendo sim por conveniência. O modelo interpreta o pedido do usuário, escolhe uma ferramenta e fornece os parâmetros. A ferramenta utiliza uma credencial capaz de modificar o sistema externo.

Raciocínio, autorização e execução ficam muito próximos.

Isso funciona. Em aplicações simples, pode funcionar muito bem.

O problema aparece conforme o Agente ganha autonomia. Se o mesmo componente interpreta linguagem natural, decide o que fazer, escolhe os parâmetros e tem acesso suficiente para disparar a ação final, um erro deixa de produzir apenas uma resposta incorreta.

Ele pode virar uma alteração real no CRM, uma mensagem enviada para a pessoa errada, um horário reservado indevidamente ou uma operação financeira que nunca deveria ter sido autorizada.

Essa preocupação surge justamente porque Agentes precisam de ferramentas para participar da operação real. Quanto maior a capacidade de ação, mais importante fica definir onde termina a decisão do modelo e onde começa o controle do sistema.

Uma arquitetura mais controlável trata duas perguntas como problemas diferentes:

O que deveria ser feito?

Essa ação pode realmente ser executada?

A primeira pergunta pode continuar sendo respondida por inteligência artificial.

A segunda não precisa ser.

Raciocínio é probabilístico. Autorização não deveria ser

Modelos de linguagem são sistemas não determinísticos. Pequenas diferenças de contexto podem produzir interpretações ou caminhos diferentes.

Essa flexibilidade é parte do que os torna úteis.

Um Agente pode compreender que duas frases diferentes representam a mesma intenção, interpretar informações dispersas em uma conversa, escolher entre ferramentas e adaptar um processo ao contexto.

A mesma propriedade é muito menos desejável quando a pergunta muda para:

este Agente pode transferir R$ 8.000 para esta conta?

Nesse momento, não queremos uma interpretação aproximadamente correta. Queremos regras verificáveis.

A Anthropic explica essa diferença em seu trabalho sobre como projetar ferramentas para Agentes. Software tradicional costuma estabelecer contratos entre sistemas determinísticos. Ao introduzir um Agente, aparece um componente que pode escolher ferramentas diferentes, interpretar parâmetros de maneiras diferentes ou decidir não utilizar uma ferramenta que parecia óbvia para quem projetou o sistema.

Isso sugere uma divisão de responsabilidades.

O modelo pode concluir que um pagamento deveria ser realizado.

Outra camada verifica se aquele Agente tem autorização para pagamentos, qual é o limite permitido, qual organização está envolvida, se o beneficiário é válido, se a operação já foi executada e se aquele valor exige aprovação humana.

Somente depois dessas verificações a solicitação chega ao sistema financeiro.

O modelo continua raciocinando.

O poder operacional passa a ser mediado.

Esse desenho se aproxima de uma arquitetura híbrida: inteligência onde existe ambiguidade e regras onde existe necessidade de previsibilidade. É a mesma tensão discutida ao comparar Agente de IA e workflow determinístico.

A arquitetura de “brain” e “hands”

Em abril de 2026, a Anthropic publicou detalhes sobre a arquitetura de seu serviço Managed Agents.

Um dos princípios adotados foi separar aquilo que a empresa chama de brain, o Claude e seu sistema de orquestração, das hands, os ambientes e ferramentas capazes de executar ações.

No artigo Scaling Managed Agents: Decoupling the brain from the hands, a empresa explica que o harness deixou de viver dentro do mesmo ambiente de execução utilizado pelo Agente.

Cada “mão” passou a ser tratada como uma interface.

Para o cérebro, um ambiente de execução pode funcionar como uma ferramenta: um nome e determinados parâmetros são enviados e um resultado é devolvido.

Essa separação trouxe benefícios operacionais para a Anthropic. Ambientes podem ser criados somente quando necessários, diferentes cérebros podem utilizar diferentes ambientes, componentes podem falhar ou ser substituídos separadamente e o tempo até o primeiro token caiu de forma relevante na arquitetura descrita pela empresa.

Mas existe outra consequência interessante para quem está construindo Agentes dentro de empresas:

o componente que pensa não precisa ser o componente que possui acesso direto aos recursos sobre os quais está pensando.

A arquitetura da Anthropic não é uma receita pronta para CRM, cobrança ou agenda. O princípio, porém, é útil.

Separar cérebro e mãos cria um ponto intermediário.

E nesse ponto podem existir regras.

O modelo não precisa carregar a chave do cofre

Imagine um Agente conectado ao sistema financeiro de uma empresa.

Uma implementação direta poderia disponibilizar uma ferramenta `realizar_pagamento`, ligada a uma API que utiliza uma credencial capaz de movimentar recursos.

O Agente interpreta a solicitação, define beneficiário, valor e descrição e chama a ferramenta.

Tecnicamente, funciona.

Mas observe a concentração de responsabilidade.

O sistema que interpreta uma frase escrita em linguagem natural também determina, na prática, que aquela frase constitui autorização suficiente para movimentar dinheiro.

Uma arquitetura separada poderia funcionar de outra maneira.

O modelo analisa a conversa e produz uma ação estruturada:

Solicitação identificada: pagamento da fatura 4821, no valor de R$ 3.700.

Essa saída ainda não significa que R$ 3.700 serão pagos.

Ela é apenas uma proposta de ação.

Uma camada de autorização recebe essa proposta e verifica, por exemplo:

• identidade do solicitante;
• organização e conta financeira envolvidas;
• limite operacional daquele Agente;
• fornecedor informado;
• existência da fatura;
• possibilidade de pagamento naquele momento;
• duplicidade da operação;
• regras específicas para aquele valor;
• eventual necessidade de aprovação humana.

Somente depois dessas verificações a operação é encaminhada para um executor que possui a credencial necessária.

A lógica pode ser resumida em três etapas:

O modelo propõe.

A política autoriza.

O executor executa.

Isso também muda a forma como segredos são tratados.

Ao discutir contenção de Agentes em seus produtos, a Anthropic destaca que controlar aquilo que entra no ambiente do Agente e aquilo que esse ambiente consegue alcançar estabelece limites concretos para o impacto de uma falha.

Se determinada credencial nunca entra no ambiente de raciocínio, o modelo não precisa conhecê-la para solicitar uma operação permitida.

Ele recebe uma interface.

Não a chave do cofre.

O mesmo princípio vale para CRM, agenda e mensagens

Não é necessário chegar a pagamentos para essa arquitetura fazer sentido.

Considere um Agente comercial conectado a um CRM.

O modelo pode analisar a conversa e concluir que determinada oportunidade deveria passar de “Qualificação” para “Proposta enviada”.

A alteração não precisa acontecer imediatamente.

Uma camada de execução pode confirmar que o contato pertence à organização correta, que a oportunidade ainda existe, que aquela transição é permitida e que o Agente está autorizado a modificar aquele campo.

Agora pense em agenda.

O cliente escreve:

Pode marcar amanhã depois das três.

O modelo é útil justamente para transformar essa linguagem ambígua em uma intenção estruturada.

Ele pode identificar a data, interpretar “depois das três”, entender qual serviço está sendo discutido e sugerir uma faixa de horários.

Mas o executor ainda pode consultar a agenda real, verificar disponibilidade, duração da reunião, fuso horário, antecedência mínima e conflitos antes de criar o evento.

O mesmo vale para mensagens.

O modelo pode escrever perfeitamente a mensagem que deveria ser enviada sem possuir acesso irrestrito à API responsável pelo disparo.

Uma camada intermediária pode verificar destinatário, organização, canal, status do atendimento e políticas de envio.

A mudança parece pequena, mas altera o significado da ferramenta.

Em vez de entregar ao modelo algo equivalente a:

“Faça o que considerar adequado nesta API.”

o sistema oferece algo mais próximo de:

“Descreva a ação que considera adequada. O sistema verificará se ela pode acontecer.”

Permissão da ferramenta não é autorização da ação

Existe uma diferença importante entre dizer que um Agente pode acessar determinada ferramenta e dizer que qualquer operação disponível naquela ferramenta está autorizada.

Um Agente pode precisar consultar um CRM sem ter permissão para excluir registros.

Pode alterar o estágio de uma oportunidade sem conseguir modificar a propriedade da conta.

Pode gerar uma proposta sem ter autoridade para alterar os dados bancários utilizados no pagamento.

Pode criar reuniões, mas não cancelar compromissos existentes.

Pode consultar o status de uma cobrança sem conseguir emitir um reembolso.

A AI Agent Security Cheat Sheet da OWASP recomenda justamente permissões específicas por ferramenta, distinção entre leitura e escrita e autorização explícita para operações sensíveis. A própria orientação também inclui a separação entre decisão e execução para operações irreversíveis.

A Microsoft segue uma direção semelhante.

Em sua orientação sobre menor privilégio para Agentes de IA, a empresa recomenda identidades dedicadas, escopos definidos, allowlists de ferramentas, revisão das permissões efetivas e registros suficientes para reconstruir as ações executadas.

Essa discussão é aprofundada em Quem autorizou a IA? Identidade, permissões e responsabilidade em Agentes IA.

O princípio é simples:

ter acesso a uma ferramenta não deveria significar possuir autoridade irrestrita sobre tudo que aquela ferramenta consegue fazer.

O ponto mais importante é criar uma fronteira determinística

Prompts ajudam.

Treinamento ajuda.

Classificadores ajudam.

Modelos melhores também ajudam.

Mas todos esses mecanismos continuam dependendo, em algum grau, do comportamento de sistemas probabilísticos.

Em maio de 2026, a Anthropic publicou sua experiência construindo mecanismos de contenção para Claude. Uma das conclusões do trabalho é que defesas comportamentais não eliminam completamente a possibilidade de falha.

Por isso, a empresa dá prioridade a controles no ambiente capazes de estabelecer aquilo que o Agente realmente consegue alcançar.

A ideia pode ser traduzida para uma pergunta simples:

o que acontece se o Agente tentar fazer algo que não deveria?

Considere duas respostas.

Na primeira:

O prompt diz que ele não deve fazer isso.

Na segunda:

Mesmo que ele tente, a camada de autorização rejeita a operação.

As duas proteções podem coexistir, mas não entregam o mesmo tipo de garantia.

Na primeira situação, a segurança depende principalmente do comportamento do modelo.

Na segunda, existe uma impossibilidade técnica definida pela arquitetura.

É essa fronteira que limita o impacto quando as outras proteções falham.

Prompt injection torna essa separação ainda mais importante

O risco fica mais claro quando lembramos que a decisão do Agente não é influenciada apenas pelo usuário.

Agentes podem ler e-mails, páginas, documentos, PDFs, resultados de busca, tickets e respostas retornadas por outras ferramentas.

Esse conteúdo pode conter instruções maliciosas ou simplesmente informações capazes de desviar o comportamento do modelo.

É o problema da prompt injection indireta, discutido em como sites, PDFs e e-mails podem manipular um Agente IA.

Imagine que um Agente receba um documento contaminado e seja convencido de que precisa enviar determinada informação para um endereço externo.

Se a única proteção for uma instrução dizendo “não compartilhe dados sensíveis”, a defesa ainda depende da interpretação do modelo.

Se o executor só permite envios para domínios autorizados, o problema muda de natureza.

O modelo pode até solicitar a ação.

O sistema recusa.

No artigo sobre contenção, a Anthropic descreve justamente o uso de limites de filesystem, rede, máquinas virtuais, proxies e controles de saída para restringir o alcance real dos Agentes.

O objetivo não é tornar o modelo incapaz de errar.

É impedir que todo erro possível tenha o mesmo impacto.

Uma camada de execução também melhora a auditoria

Separar decisão de execução não serve apenas para bloquear operações.

Serve também para explicar o que aconteceu.

Quando uma ação atravessa uma camada de autorização e execução, o sistema pode registrar informações como:

• qual usuário iniciou a solicitação;
• qual Agente interpretou a situação;
• qual ação foi proposta;
• quais parâmetros foram enviados;
• quais políticas foram avaliadas;
• qual identidade recebeu autorização;
• se houve aprovação humana;
• qual executor realizou a operação;
• qual foi o resultado;
• qual identificador permite correlacionar toda a cadeia.

Isso produz uma trilha de auditoria muito mais útil do que simplesmente registrar a chamada HTTP final.

Se um problema aparecer seis meses depois, a pergunta deixa de ser somente:

qual API foi chamada?

Também podemos tentar responder:

por que essa operação foi permitida?

A Microsoft reforça esse ponto em seu trabalho sobre identidade, acesso e tool binding para Agentes. A recomendação inclui rastrear identidade, papel, escopo efetivo, ação, recurso e usuário em nome de quem a operação ocorreu.

Quanto maior o número de sistemas envolvidos em um fluxo, mais útil essa rastreabilidade se torna.

Separar execução não significa pedir aprovação humana para tudo

Existe um risco de interpretar essa arquitetura como uma defesa de processos burocráticos.

Não é.

Separar decisão e execução pode permitir mais autonomia, não menos.

Imagine um Agente comercial que esteja autorizado a:

• atualizar determinados campos do CRM;
• criar reuniões em agendas específicas;
• enviar materiais já aprovados;
• gerar propostas dentro de determinadas regras;
• conceder descontos de até um limite definido.

Se essas fronteiras forem aplicadas pelo sistema, o Agente pode trabalhar livremente dentro delas.

Não é necessário perguntar a uma pessoa a cada passo.

A aprovação humana fica reservada para situações em que o risco realmente muda.

A Anthropic descreveu algo semelhante ao apresentar o sandboxing do Claude Code. Ao estabelecer previamente limites de filesystem e rede, a empresa conseguiu reduzir fortemente a quantidade de solicitações de permissão sem simplesmente liberar acesso irrestrito.

Isso importa porque pedir confirmação constantemente também cria risco.

Depois de dezenas de solicitações semelhantes, a revisão humana pode virar um reflexo. O usuário deixa de analisar e começa a aprovar.

Esse problema é aprofundado no post Pedir aprovação para tudo também é um risco: quando o humano vira carimbador do Agente.

A alternativa não precisa ser escolher entre autonomia total e aprovação total.

Pode ser estabelecer poucas fronteiras claras.

Dentro delas, o Agente trabalha.

Fora delas, o sistema bloqueia ou escala.

O Agente deveria possuir credenciais?

Essa é uma pergunta útil durante o desenho de qualquer integração.

A resposta não precisa ser sempre “não”.

Existem situações em que uma credencial de baixo privilégio, restrita a poucos recursos e com duração limitada pode existir no ambiente utilizado pelo Agente sem criar um risco desproporcional.

O ponto é não tomar essa decisão por conveniência.

Quanto maior o impacto de uma ferramenta, mais sentido faz perguntar:

• a credencial precisa realmente entrar no ambiente do modelo?
• o Agente precisa de acesso à API inteira ou apenas a algumas operações?
• leitura e escrita precisam utilizar a mesma identidade?
• a autorização pode ser verificada novamente antes da execução?
• operações irreversíveis precisam de uma camada adicional?
• o executor pode receber uma credencial temporária e limitada à tarefa?
• existe alguma forma de revogar o acesso imediatamente?

Para ações de maior impacto, uma arquitetura comum é manter o segredo em um serviço separado.

O Agente recebe uma interface limitada.

A interface recebe uma solicitação estruturada, verifica políticas, utiliza a credencial necessária e devolve o resultado.

O modelo continua capaz de trabalhar.

Ele apenas deixa de possuir sozinho todo o poder necessário para concluir qualquer ação.

Quanto mais autonomia, mais importante fica estruturar o poder

Existe uma diferença importante entre um chatbot que responde incorretamente e um Agente que age incorretamente.

Uma resposta ruim pode confundir um cliente.

Uma ação ruim pode modificar um sistema.

À medida que Agentes passam a operar CRM, agenda, cobrança, e-mail, arquivos e ferramentas internas, a arquitetura precisa acompanhar esse aumento de capacidade.

Segurança não pode depender exclusivamente da qualidade do prompt ou da expectativa de que o modelo sempre compreenderá corretamente aquilo que deveria fazer.

Modelos podem continuar responsáveis pelo trabalho em que sua flexibilidade é útil: interpretar situações ambíguas, compreender contexto, elaborar planos, escolher caminhos e transformar linguagem humana em intenções estruturadas.

Ações concretas podem atravessar outra fronteira.

Uma fronteira onde identidade é conhecida, permissões são explícitas, parâmetros são validados, regras são verificadas, credenciais são controladas e tudo que aconteceu pode ser reconstruído depois.

A separação é conceitualmente simples:

o cérebro pode continuar probabilístico. As mãos não precisam ser.

Antes de dar mais autonomia ao seu Agente

Vale revisar cada integração e fazer uma pergunta simples:

essa decisão realmente precisa terminar diretamente em uma execução?

Talvez o modelo possa decidir que um lead deve mudar de etapa sem possuir acesso irrestrito ao CRM.

Pode concluir que um pagamento deveria acontecer sem carregar a credencial bancária.

Pode entender que uma reunião precisa ser marcada sem ter autoridade para cancelar qualquer compromisso.

Pode escrever uma mensagem sem controlar sozinho quando, para quem e por qual conta ela será enviada.

Pode solicitar uma ação administrativa sem ter capacidade técnica para ultrapassar os limites definidos para sua organização.

O caminho para Agentes mais capazes não precisa ser entregar cada vez mais acesso ao modelo.

Em muitos casos, o caminho pode ser deixar o modelo cada vez melhor em decidir enquanto a infraestrutura fica cada vez melhor em controlar aquilo que realmente pode acontecer.