Uma arquitetura para agentes seguros precisa limitar o que cada identidade pode fazer, verificar as condições no ponto que executa a ação e registrar como o resultado foi confirmado. Comece por uma operação delimitada: conectar o modelo, por si só, não estabelece controle sobre as ferramentas e os sistemas que o agente usa.
Onde o controle deve acontecer?
Desenhe o caminho entre pedido, agente, modelo, ferramenta e sistema de destino. Identifique quem mantém cada componente e quais caminhos alternativos existem. Se o agente pode usar uma credencial diretamente contra o sistema financeiro, um controle colocado apenas no acesso ao modelo não recebe essa chamada. O mapa precisa revelar esse caminho antes de afirmar que a operação está coberta.
Separe a decisão sugerida pelo modelo da autorização técnica para executá-la. A integração deve conferir identidade, recurso, operação e condições relevantes de negócio antes da mudança. A instrução “não ultrapasse o limite” dentro de um prompt orienta o comportamento, mas não equivale a uma permissão aplicada pelo sistema que recebe a ação. O desenho deve explicitar o que será verificado em cada ponto integrado.
Como integrar agentes existentes sem começar do zero?
Faça um inventário dos agentes e ferramentas que participam da operação escolhida. Para cada ferramenta, registre entrada, saída, autenticação, efeitos possíveis e responsável. A equipe pode começar conectando um ponto crítico, como a escrita em um cadastro, sem substituir todos os agentes. Esse recorte deve ficar visível: integrar uma ferramenta não comprova cobertura das demais.
Combine contratos de saída e estados que a equipe consiga interpretar. Uma proposta pronta, uma autorização concedida, uma tentativa enviada e um resultado confirmado são eventos diferentes. Quando houver aprovação humana, a integração precisa vincular a decisão aos parâmetros que serão executados; alterar valor ou destinatário depois da aprovação deve levar a uma nova verificação. O contrato também precisa representar ausência de confirmação.
O que fazer quando uma ferramenta não responde?
Uma resposta que não chegou deixa uma incerteza: o sistema pode ter realizado a alteração. Repetir imediatamente pode duplicar o trabalho. Defina como consultar o estado no destino, relacionar tentativas à mesma operação e decidir quando uma pessoa deve intervir. A política depende da integração e de suas garantias; um código de erro isolado não informa todo o estado do negócio.
A recuperação precisa fazer parte do desenho inicial. Especifique como tratar indisponibilidade, repetição, retorno atrasado e confirmação parcial. Quando uma operação envolve vários itens, como diferentes exames, uma confirmação de um item não confirma os demais. Se o sistema não oferecer uma forma confiável de conferir a alteração, registre a limitação e reduza a autonomia até existir um caminho de acompanhamento.
Como validar antes de ampliar o uso?
Monte cenários representativos com entradas e ambientes apropriados ao teste: ação permitida, ação bloqueada, dados incompletos, aprovação vencida, alteração após aprovação, integração indisponível e retorno duplicado. Para cada cenário, descreva o efeito esperado no destino e o que a equipe deve conseguir observar. Um teste que confere apenas o texto da resposta do agente não valida a integração.
Libere um recorte com responsáveis e caminho de retorno definidos. Compare a nova versão usando o mesmo critério e registre o que não foi testado. Uma versão que funciona com revisão humana ainda precisa de avaliação própria antes de receber permissão para executar automaticamente. Na Starya, esse desenho conecta engenharia, NebulaOS e o acompanhamento do trabalho; o escopo efetivo depende das integrações da implantação.
Exemplo ilustrativo · sem dados de cliente
Uma alteração de cadastro com resultado desconhecido
Exemplo fictício: o agente propõe atualizar um endereço. A integração verifica a permissão e envia a alteração, mas o retorno não chega. A conversa não pode apresentar essa tentativa como uma conclusão confirmada.
O fluxo consulta o cadastro com a identidade autorizada. Se confirmar a alteração, encerra a pendência; se encontrar outro estado ou não conseguir consultar, encaminha para investigação antes de repetir. O objetivo é preservar a continuidade sem fabricar certeza sobre o resultado.
Quando o caminho precisa mudar
Quando a integração permite somente leitura, limite a primeira entrega à preparação de propostas. Quando não existe confirmação confiável, mantenha conferência humana e um estado explícito de pendência. Escolher um escopo menor pode ser a condição para operar com responsabilidade enquanto a dependência é resolvida.
Um ponto de atenção: Tratar o gateway de modelos como cobertura automática de todas as ferramentas do agente.
O roteiro está pronto para avançar quando…
- O mapa identifica os caminhos de leitura e escrita e seus responsáveis.
- Permissão, aprovação e execução estão ligados aos mesmos parâmetros.
- Falha, conclusão parcial e resultado desconhecido têm tratamento e testes definidos.
Use o roteiro para revisar uma integração real. Depois compare as necessidades com os componentes e controles disponíveis na implantação.
Seu roteiro
Preencha com sua equipe.
Registre o que já sabe e o que ainda precisa confirmar. As respostas permanecem em memória, sem envio.
Referências para aprofundar
- OWASP — Agentic AI: Threats and Mitigations ↗
Referência para modelar ameaças de sistemas de agentes e discutir mitigações. O roteiro e os cenários abaixo são propostas de trabalho da Starya, não uma reprodução integral do documento.
- RFC 9110 — métodos idempotentes ↗
A semântica HTTP ajuda a discutir repetição de requisições. Uma operação de negócio ainda precisa definir deduplicação e reconciliação com o sistema de destino.