Guia de Segurança em Cinco Camadas da Mend Mira Riscos de IA em Produção Além das Barreiras de Prompt

A Mend.io publicou uma abordagem de segurança em cinco camadas que chegou ao Google News, mas sua mensagem central desafia a forma como muitas equipes protegem a IA em produção. Barreiras de prompt, por si só, não conseguem proteger agentes que mantêm credenciais, chamam ferramentas, retêm memória e alteram sistemas externos.

O guia, coberto pela MarkTechPost em 3 de agosto, organiza a superfície de ataque entre as camadas de interação, agente, integração, modelo e código. Seu valor prático está em tratar uma aplicação de IA como um sistema executável, e não apenas como um chatbot com riscos de entrada incomuns.

Essa distinção cria o conflito real. Desenvolvedores querem que os agentes concluam mais trabalho com menos interrupções. As equipes de segurança precisam de limites determinísticos quando esses agentes encontram documentos hostis, ferramentas envenenadas, permissões excessivas ou caminhos de execução inesperados.

MCP, abreviação de Model Context Protocol, oferece às aplicações de IA uma interface padrão para descobrir e chamar ferramentas externas. Ele pode conectar um modelo a bancos de dados, sistemas de arquivos, APIs, aplicações empresariais e ambientes de desenvolvimento.

O protocolo melhora a interoperabilidade, mas essa conveniência amplia o número de fronteiras de confiança dentro de cada fluxo de trabalho. Um agente agora pode transformar texto não confiável em uma ação consequente em questão de segundos.

A questão já não é se um modelo produz uma resposta inadequada. É se um modelo manipulado pode usar uma ferramenta autorizada para uma finalidade não autorizada.

Google News Coloca a Segurança de IA em Produção em Foco

O evento importante é a mudança de discutir o comportamento do modelo para proteger todo o caminho entre a entrada e a execução.

O guia de segurança em produção destacado pelo Google News apresenta a segurança de agentes como um problema de engenharia em cinco camadas. A camada de interação abrange prompts, documentos recuperados, arquivos de usuários e outras informações que entram na aplicação.

A camada do agente inclui planejamento, memória, seleção de ferramentas e tarefas delegadas. A camada de integração abrange servidores MCP, APIs, bancos de dados, plugins e outras conexões que levam as decisões do agente a sistemas externos.

A camada do modelo inclui o modelo de linguagem, sua configuração e suas limitações comportamentais. A camada de código inclui a lógica da aplicação, dependências, infraestrutura, credenciais e pipelines de implantação.

Esse enquadramento importa porque as falhas frequentemente atravessam várias camadas. Uma instrução maliciosa pode entrar por um documento, influenciar o raciocínio do modelo, acionar uma ferramenta MCP permitida e expor dados por meio de uma solicitação comum de API.

Cada componente pode parecer funcionar como projetado. A falha de segurança surge da composição entre eles.

A segurança de aplicações tradicional continua sendo importante nessa pilha. As equipes precisam corrigir dependências, proteger segredos, validar entradas, isolar cargas de trabalho e revisar código. No entanto, esses controles não explicam por completo por que um agente selecionou uma ferramenta válida no momento errado.

O modelo opera com instruções e dados expressos pelo mesmo meio básico. Uma página recuperada pode conter informações que respondem à pergunta de um usuário, instruções que redirecionam o agente ou ambos.

Isso cria a injeção indireta de prompt, em que orientações maliciosas chegam por conteúdo externo, em vez do prompt visível do usuário. Um agente que lê e-mails, páginas da web, tickets de suporte ou documentos internos pode encontrar esse conteúdo durante o trabalho normal.

O ataque pode permanecer invisível para a pessoa que iniciou a tarefa. O agente pode resumir o documento esperado enquanto, discretamente, chama outra ferramenta ou incorpora informações envenenadas à memória.

A estrutura de cinco camadas da Mend.io, portanto, funciona como um método de inventário. Ela pede que as equipes identifiquem todos os locais em que instruções, autoridade, código, dados e estado podem entrar ou sair do sistema.

Esse inventário deve incluir mais do que modelos implantados. Deve registrar configurações de agentes, prompts de sistema, servidores MCP, ferramentas disponíveis, escopos de permissão, armazenamentos de memória, provedores de modelos, dependências e responsáveis.

Sem esse mapa, as equipes não conseguem determinar se um componente comprometido pode alcançar outro. Tampouco conseguem revogar o acesso com confiança quando uma integração muda de comportamento.

O evento não é uma nova versão de protocolo nem uma única vulnerabilidade divulgada. É uma fronteira de produção mais clara: a segurança de agentes precisa acompanhar toda a cadeia de execução.

Essa fronteira pressiona simultaneamente desenvolvedores, equipes de plataforma, engenheiros de segurança e fornecedores de IA. Cada grupo controla apenas parte do sistema, enquanto as falhas mais graves atravessam essas divisões organizacionais.

Agentes de IA Transformam Linguagem em Ações Privilegiadas

Um LLM se torna um problema de segurança materialmente diferente quando sua saída controla software com autoridade real.

Um chatbot convencional produz texto para que uma pessoa o revise. Um agente pode interpretar um objetivo, selecionar uma ferramenta, construir argumentos, inspecionar o resultado e continuar agindo sem outra decisão humana.

Esse ciclo altera a consequência de uma resposta ruim do modelo. Uma frase inventada é inconveniente, mas uma instrução inventada enviada a um banco de dados ou ferramenta de implantação pode se tornar um incidente operacional.

Considere um agente interno de pesquisa encarregado de comparar propostas de fornecedores. Ele lê documentos enviados, pesquisa o armazenamento compartilhado, consulta registros de compras e redige uma recomendação.

Uma proposta maliciosa pode ocultar instruções para que o agente recupere preços confidenciais de outra pasta. Se a ferramenta de armazenamento tiver permissões amplas, a decisão equivocada do modelo se torna um caminho real para divulgação.

Um agente de programação cria um problema semelhante. Ele pode ler repositórios, instalar dependências, executar testes, modificar arquivos e abrir pull requests. Texto não confiável em issues ou documentação de pacotes pode influenciar o mesmo modelo que detém essas capacidades.

O MCP torna essas conexões mais fáceis de criar de forma consistente. Isso beneficia os desenvolvedores, mas também significa que a descrição de uma ferramenta, a resposta de uma ferramenta ou um servidor remoto podem influenciar as escolhas posteriores de um agente.

A orientação de segurança para agentes da OWASP identifica injeção de prompt, abuso de ferramentas, exfiltração de dados, envenenamento de memória, autonomia excessiva e falhas em cascata entre os principais riscos. Essas categorias estão conectadas, não isoladas.

A memória é especialmente importante. A memória persistente de agentes armazena informações para sessões futuras, permitindo que uma aplicação se lembre de preferências, trabalhos anteriores ou conhecimento acumulado.

Se conteúdo não confiável entrar nesse armazenamento sem validação, um ataque pode sobreviver depois que a conversa original termina. Usuários posteriores podem receber fatos envenenados ou acionar comportamentos influenciados por um documento anterior.

Sistemas multiagente ampliam o possível raio de impacto. Um agente pode repassar instruções, resumos, credenciais ou resultados de ferramentas para outro agente com permissões diferentes.

Um agente de pesquisa comprometido talvez não tenha acesso de escrita ao banco de dados. No entanto, ele pode fornecer conclusões manipuladas a um agente de operações que tenha esse acesso.

As equipes não podem resolver esse problema dizendo a cada modelo para ignorar instruções maliciosas. Os modelos precisam processar linguagem natural para realizar seu trabalho, e atacantes podem variar a redação, o contexto, a codificação e os canais de entrega.

Portanto, o alvo da segurança precisa ser a fronteira da ação. Antes de uma ferramenta ser executada, um software determinístico deve decidir se o agente, o usuário, o recurso, a operação e os parâmetros formam uma combinação permitida.

Uma operação de leitura não deve se tornar silenciosamente uma escrita. O acesso a um repositório não deve conceder acesso a todos os repositórios. A permissão para redigir um e-mail não deve permitir automaticamente seu envio.

Operações de alto impacto exigem um tratamento mais rigoroso. Transferências financeiras, mudanças em produção, administração de contas, exclusão de dados, publicação externa e acesso a credenciais devem exigir autorização explícita ou aprovação humana.

A aprovação deve estar vinculada à ação real. Uma confirmação vaga, como “continuar”, é mais fraca do que uma aprovação que exibe o destino, a operação, o recurso afetado e os parâmetros materiais.

Credenciais de curta duração também reduzem a exposição. Um agente deve receber a autoridade mínima necessária para a tarefa atual e perder essa autoridade quando a tarefa terminar.

Essa abordagem pode adicionar atrito, especialmente quando desenvolvedores medem o sucesso pela conclusão e velocidade das tarefas. Ainda assim, a alternativa é permitir que o raciocínio probabilístico funcione como um sistema de controle de acesso.

Modelos de linguagem podem propor ações. Eles não devem definir unilateralmente sua própria autoridade.

MCP Padroniza Conexões, Não uma Governança Completa

O MCP resolve um problema de compatibilidade, enquanto as equipes de produção ainda precisam construir em torno dele a camada de políticas e responsabilização.

Um cliente MCP pode recuperar as definições de ferramentas disponíveis de um servidor e apresentá-las a um modelo. O modelo usa essas descrições e esquemas de parâmetros para selecionar e invocar uma ferramenta.

Essa estrutura reduz o trabalho de integração personalizada. Um cliente compatível pode se conectar a muitos servidores por meio de um protocolo compartilhado, em vez de aprender uma interface separada para cada serviço.

No entanto, a descoberta padronizada não torna confiável toda ferramenta descoberta. Um servidor pode ser comprometido, falsificado, configurado incorretamente ou atualizado após uma análise inicial de segurança.

O envenenamento de ferramentas explora essa confiança. Instruções maliciosas inseridas na descrição de uma ferramenta podem influenciar o modelo enquanto permanecem ocultas da interação comum do usuário.

A resposta de uma ferramenta pode carregar instruções semelhantes. O agente pode tratar a resposta como dados, mas o modelo de linguagem pode interpretar texto incorporado como uma orientação que afeta ações posteriores.

As mais recentes regras de autorização do MCP incluem requisitos relacionados à validação de tokens, vinculação de audiência, roubo de tokens, segurança das comunicações, riscos de redirecionamento e ataques de confused deputy.

Esses requisitos reforçam a infraestrutura de autenticação e autorização. Eles não decidem se uma ação empresarial específica é apropriada para o objetivo atual do usuário.

Um token de acesso válido estabelece autoridade reconhecida dentro de seu escopo. Ele não prova que um modelo tomou a decisão correta após ler conteúdo não confiável.

Sistemas de produção precisam de um ponto de controle entre a intenção do modelo e a execução da ferramenta. Essa camada pode avaliar identidade, operação solicitada, recurso, parâmetros, risco da sessão, classificação de dados e ações anteriores.

A Microsoft descreveu essa lacuna ao apresentar uma abordagem open source para governança em tempo de execução. Seu benchmark de governança interno testou 60 prompts, incluindo 45 casos adversariais e 15 casos válidos.

A Microsoft relatou uma taxa de 26,67% de violações de política quando o sistema se baseava em instruções de segurança apenas por prompt. A empresa forneceu metodologia e materiais de reprodução, mas o resultado continua sendo sua própria avaliação.

A descoberta ainda ilustra um princípio importante de design. O desempenho em seguir instruções não deve ser tratado como uma fronteira de segurança determinística.

Um plano de controle em tempo de execução pode permitir, negar ou escalar cada solicitação de ferramenta. Ele também pode inspecionar definições de ferramentas antes de expô-las ao modelo e analisar respostas antes de devolvê-las ao agente.

Essa camada deve impor esquemas, restrições de parâmetros, listas de recursos permitidos, limites de taxa, limites de custo e profundidade máxima de encadeamento. Ela deve interromper falhas repetidas em vez de permitir que um agente entre em um ciclo de tentativas descontrolado.

Por exemplo, um agente de suporte ao cliente pode precisar ler o registro de uma conta e preparar uma recomendação de reembolso. Ele não precisa de acesso irrestrito ao banco de dados nem de permissão imediata para emitir todos os reembolsos que propõe.

A camada de política pode restringir as leituras ao cliente atual, ocultar campos sensíveis, limitar o valor do reembolso e exigir aprovação humana antes do pagamento. O modelo continua útil sem receber ampla autoridade operacional.

O isolamento também é importante. Ferramentas com altos privilégios não devem compartilhar o mesmo contexto de agente com servidores MCP externos arbitrários.

Um agente que lê conteúdo público da web não deve ganhar automaticamente um caminho para ferramentas internas de administração. Separar essas capacidades reduz a chance de conteúdo externo hostil chegar a superfícies sensíveis de execução.

As equipes de segurança também devem manter um registro de servidores aprovados. Cada entrada deve identificar o responsável pelo servidor, a origem do código, o local de implantação, o método de autenticação, as ferramentas disponíveis, o acesso a dados, a versão e o status da revisão.

As atualizações devem acionar uma revisão quando alterarem descrições de ferramentas, esquemas, dependências, permissões ou destinos de rede. Um servidor aprovado meses antes não deve receber confiança permanente.

Servidores MCP também exigem proteções convencionais de serviço. As equipes precisam de transporte seguro, autenticação, aplicação de patches, gestão de dependências, validação de entradas, isolamento de segredos, registros e resposta a incidentes.

O protocolo não substitui esses controles. Ele cria outro ponto em que eles devem ser aplicados de forma consistente.

A Verdadeira Troca É Entre Autonomia e Contenção

Cada capacidade adicional aumenta a utilidade de um agente, ao mesmo tempo que amplia o dano possível em caso de manipulação bem-sucedida.

Essa troca explica por que a segurança de agentes não pode se tornar uma lista de verificação anexada pouco antes da implantação. O design do produto determina a autoridade máxima do sistema muito antes de um scanner de segurança examiná-lo.

Um agente sem ferramentas pode produzir texto nocivo ou impreciso. Um agente com acesso a arquivos pode expor documentos. Um agente com acesso ao shell pode executar comandos, enquanto outro conectado a sistemas de produção pode modificar infraestrutura em operação.

Permissões amplas costumam entrar nos protótipos por conveniência. Desenvolvedores querem testar se um agente consegue concluir um fluxo de trabalho de ponta a ponta antes de investir em autorização detalhada.

Esses protótipos podem chegar à produção mais rápido do que o esperado. Credenciais temporárias permanecem na configuração, servidores MCP experimentais tornam-se infraestrutura compartilhada e esquemas permissivos de ferramentas se transformam em dependências não documentadas.

O modelo de cinco camadas ajuda a expor esses atalhos. No entanto, um inventário por si só não os contém.

Cada agente precisa de uma fronteira de confiança definida. Essa fronteira deve estabelecer quem pode invocá-lo, quais dados ele pode receber, quais ferramentas pode usar, quais recursos pode alcançar e quais resultados exigem aprovação.

As equipes devem distinguir entre os modos de leitura, rascunho, recomendação e execução. Esses rótulos precisam corresponder a permissões aplicáveis, e não apenas à redação de prompts.

Um agente de pesquisa pode ler fontes aprovadas e redigir conclusões. Um agente de operações pode preparar um plano de implantação. Um processo separado e controlado pode verificar e executar esse plano.

Essa separação reduz a autonomia, mas também cria transições passíveis de revisão. Investigadores podem ver quando uma informação se tornou uma recomendação e quando essa recomendação se tornou uma ação.

A observabilidade apoia o mesmo objetivo. Os registros devem capturar o usuário iniciador, a identidade do agente, a versão do modelo, a versão do prompt ou da política, o servidor MCP, o nome da ferramenta, os argumentos, a classificação da resposta, o registro de aprovação e o resultado final.

Dados sensíveis não devem ser copiados de forma descuidada para esses registros. A telemetria de segurança precisa de contexto suficiente para a investigação sem criar outro repositório de segredos expostos.

A identidade do agente merece atenção especial. Compartilhar uma conta de serviço entre muitos agentes dificulta a atribuição de responsabilidades ou a revogação de um fluxo de trabalho comprometido.

Identidades separadas permitem permissões por agente e trilhas de auditoria mais claras. Elas também ajudam as equipes de segurança a identificar comportamentos anormais, como um agente de pesquisa que de repente solicita acesso de gravação.

A orientação governamental agora trata o MCP como infraestrutura que exige design de segurança deliberado. A orientação de segurança para MCP da NSA, de maio de 2026, aborda autenticação, autorização, isolamento, validação de servidores, gestão de ciclo de vida e riscos que abrangem os componentes do protocolo.

Essa atenção sinaliza uma mudança de maturidade. O MCP já não é apenas uma conveniência para desenvolvedores debatida em demonstrações locais. Organizações o estão avaliando para ambientes em que ferramentas comprometidas podem afetar dados e operações sensíveis.

Os controles de segurança para agentes do Google Cloud apresentam um ponto semelhante. A orientação recomenda uma identidade distinta para o agente, funções de privilégio mínimo e restrições que impeçam o acesso de leitura e gravação a recursos de produção.

Esses são princípios de segurança conhecidos. Sua aplicação se torna mais difícil porque os agentes selecionam ações dinamicamente e combinam ferramentas individualmente válidas em fluxos de trabalho que os desenvolvedores não enumeraram.

O encadeamento inseguro de ferramentas ocorre quando o resultado de uma operação permitida viabiliza uma sequência nociva. Uma ferramenta de busca, um leitor de arquivos e uma ferramenta de mensagens de saída podem parecer de baixo risco quando avaliados separadamente.

Juntas, elas podem criar uma rota de exfiltração de dados. O agente busca informações sensíveis, lê essas informações e as transmite para fora da organização.

Portanto, a política deve examinar sequências, além de chamadas individuais. Uma solicitação pode ser válida isoladamente, mas suspeita após outro evento na mesma sessão.

Controles sensíveis ao contexto podem bloquear combinações que envolvem entrada não confiável e saída privilegiada. Eles também podem exigir nova autorização quando um agente passa da coleta de informações para uma ação externa.

Esse design é mais exigente do que adicionar um filtro em torno do prompt do usuário. Ele requer coordenação entre equipes de produto, plataforma, identidade, segurança de aplicações e operações.

Esse custo organizacional faz parte da troca. Empresas não podem reivindicar ampla capacidade autônoma enquanto atribuem a responsabilidade pela segurança apenas ao fornecedor do modelo.

O Que a Segurança de Produção Ainda Não Pode Garantir

Controles em camadas reduzem a exposição, mas nenhum framework atual prova que um agente permanecerá seguro em todas as combinações de modelo, ferramenta e contexto.

A primeira incerteza é a qualidade da avaliação. Testes de segurança podem medir ataques conhecidos, mas as entradas de produção mudam continuamente e os adversários se adaptam às defesas publicadas.

Uma suíte de red team deve incluir injeção de prompt direta e indireta, uso não autorizado de ferramentas, escalonamento de privilégios, envenenamento de memória, exfiltração de dados, contorno de aprovação, execução recursiva e propagação entre múltiplos agentes.

As equipes devem executar esses testes antes da implantação e após mudanças relevantes. Um novo modelo, prompt de sistema, design de memória, servidor MCP, esquema de ferramenta, fonte de recuperação ou política pode alterar a superfície de ataque.

Passar em um teste não estabelece segurança permanente. Isso mostra que controles definidos resistiram a ataques definidos sob condições específicas.

Falsos positivos criam outro problema. Se os controles interrompem tarefas legítimas em excesso, os usuários buscam soluções alternativas ou exigem permissões mais amplas.

Falsos negativos são mais perigosos, mas mais difíceis de observar. Um agente pode concluir a tarefa solicitada enquanto também vaza dados, salva memória envenenada ou toma uma ação desnecessária.

A aprovação humana não é uma solução completa. Usuários podem se habituar às confirmações, especialmente quando uma aplicação apresenta prompts frequentes ou pouco claros.

Atacantes também podem manipular as informações mostradas ao aprovador. Interfaces de aprovação devem obter os detalhes da ação a partir de dados confiáveis de execução, e não apenas da explicação do modelo.

O risco da cadeia de suprimentos também permanece sem solução. Implantações de MCP podem incluir servidores, SDKs, registros, pacotes, modelos, contêineres e serviços hospedados mantidos por diferentes partes.

Um pacote assinado pode estabelecer origem e integridade. Ele não pode garantir que o comportamento assinado seja seguro nem que um serviço remoto permanecerá inalterado.

As organizações devem preferir implantações reproduzíveis, versões fixadas, código-fonte revisado, registros controlados e processos de atualização documentados. Servidores remotos exigem validação contínua, não uma aprovação única.

A revogação de emergência deve ser prática. As equipes devem poder desativar um agente, servidor, ferramenta, credencial ou permissão sem esperar pelo lançamento de uma aplicação.

Sistemas de memória precisam de controles equivalentes. Operadores exigem métodos para inspecionar, colocar em quarentena, expirar e remover entradas suspeitas, preservando evidências para investigação.

O ceticismo também se aplica às alegações de fornecedores. Produtos de segurança prometem cada vez mais proteção de prompts, red teaming automatizado, descoberta de agentes, gestão de postura ou aplicação de políticas em tempo de execução.

Essas capacidades podem contribuir para a defesa, mas os compradores devem perguntar onde cada controle se encontra e o que acontece quando ele falha. Um detector que apenas sinaliza texto suspeito não pode substituir a autorização para a ação resultante.

As equipes devem solicitar evidências mensuráveis. Perguntas úteis incluem quais classes de ataque foram testadas, se dados de avaliação estão disponíveis, como contornos são tratados e se a aplicação de políticas falha de forma segura.

Elas também devem examinar latência e disponibilidade. Um serviço de política posicionado antes de cada chamada de ferramenta se torna infraestrutura crítica.

Se esse serviço falhar de forma aberta, os agentes poderão agir sem controles. Se falhar de forma fechada, os fluxos de trabalho dependentes serão interrompidos. O design de produção deve abordar explicitamente ambos os resultados.

A abordagem de cinco camadas é, portanto, uma base, não uma garantia. Ela ajuda as equipes a localizar riscos que uma revisão focada apenas no modelo não identificaria.

Seu sucesso depende de transformar as camadas em responsabilidade definida, política aplicável, testes repetíveis e resposta operacional. Sem essas etapas, o framework se torna mais um diagrama que documenta a exposição sem reduzi-la.

Três Sinais Mostrarão se a Segurança de Agentes Está Amadurecendo

A próxima fase será medida por padrões aplicáveis, testes independentes e evidências de implantações reais.

O primeiro sinal é se clientes e servidores MCP adotam, por padrão, autorizações mais restritas. O suporte a padrões modernos de autorização é importante, mas implantações seguras também exigem escopos específicos por recurso e uma separação clara entre operações de leitura e gravação.

Um ecossistema mais robusto tornaria permissões amplas visivelmente excepcionais. Os clientes mostrariam aos usuários o que cada servidor pode acessar, enquanto os servidores rejeitariam tokens destinados a outro recurso.

Restrições padrão fortaleceriam o argumento de que conectividade padronizada pode coexistir com contenção. A dependência contínua de credenciais ambientais e escopos excessivamente amplos o enfraqueceria.

O segundo sinal é a avaliação independente da governança em tempo de execução. Benchmarks de fornecedores oferecem pontos de partida úteis, mas os compradores precisam de testes repetíveis em vários modelos, ferramentas e estilos de ataque.

Os avaliadores devem relatar tanto a prevenção de ataques quanto a conclusão de tarefas legítimas. Um sistema que bloqueia todas as chamadas de ferramentas é seguro em um sentido restrito, mas falha em seu propósito operacional.

Os resultados também devem separar a detecção de prompts da aplicação de ações. Detectar linguagem suspeita é diferente de impedir uma leitura de arquivo, atualização de banco de dados ou solicitação de saída proibida.

O terceiro sinal é se as empresas conseguem produzir inventários completos de agentes e registros de incidentes. As organizações devem saber quais agentes estão implantados, quem é responsável por eles, quais modelos utilizam e quais servidores MCP podem alcançar.

Eles também devem conseguir reconstruir ações consequentes a partir de registros autenticados. Identidades ausentes, registros de ferramentas incompletos ou mudanças de permissão sem explicação indicam que a adoção avançou mais rápido do que a governança.

É nesse ponto que a gestão do conhecimento se cruza com as operações de segurança. As equipes precisam de registros pesquisáveis que conectem requisitos, configurações de agentes, resultados de testes, aprovações, incidentes e decisões de remediação.

Uma base de conhecimento técnico controlada pode ajudar engenheiros a recuperar esses registros, mas deve respeitar os mesmos limites de acesso e tratamento de dados.

A aparição no Google News dá maior visibilidade ao modelo de segurança em cinco camadas. Sua importância duradoura depende de as equipes transformarem essa visibilidade em permissões mais restritas e controles de execução mais robustos.

Os desenvolvedores devem começar com um fluxo de trabalho de produção e mapear cada entrada, decisão do modelo, gravação de memória, integração, credencial, chamada de ferramenta e saída. Em seguida, devem identificar onde uma política determinística interrompe movimentações inseguras entre esses pontos.

Sua organização consegue explicar o que cada agente de produção pode fazer, qual identidade o autoriza e como um documento comprometido seria contido? Se a resposta for incompleta, a próxima ação não é criar outra regra de prompt. É estabelecer um limite de execução mais restrito, um caminho de aprovação testado e uma trilha de auditoria que sobreviva ao raciocínio do agente.