Microsoft run-assert-eval Transforma Descobertas de Riscos de Agentes em Controles de Tempo de Execução Testados

A Microsoft lançou o run-assert-eval em 24 de setembro, conectando quatro tarefas de segurança de agentes antes separadas em um único fluxo de trabalho guiado. A skill Microsoft run-assert-eval descobre riscos, mede falhas, elabora controles de tempo de execução e repete a mesma avaliação depois que esses controles são adicionados. O conflito é imediato: um ciclo de segurança mais rápido só é útil quando suas medições permanecem confiáveis.

O exemplo da Microsoft dá substância ao anúncio. Um agente de suporte a faturamento divulgou dados de outro cliente em 12 de 40 conversas de referência aplicáveis, segundo a empresa. Após a introdução de uma política de tempo de execução, a Microsoft observou duas violações em 34 conversas aplicáveis. Isso reduziu a taxa relatada de 30,0% para 5,9%.

O resultado parece decisivo, mas veio de um exemplo prático mantido pelos desenvolvedores do projeto. A Microsoft não apresentou uma reprodução independente nem um estudo de implantação em produção. Portanto, o desenvolvimento importante é o mecanismo, não uma pontuação favorável isolada. A skill converte uma falha descoberta em uma política aplicável e, em seguida, testa a intervenção sem alterar discretamente a avaliação.

Microsoft run-assert-eval Conecta Descoberta, Testes e Aplicação

O lançamento transforma uma coleção de projetos de segurança em um caminho revisável, de um risco desconhecido a um controle de tempo de execução testado.

A publicação de lançamento da Microsoft descreve um fluxo de trabalho iniciado por meio de um prompt em um ambiente de programação compatível. Os desenvolvedores começam com um agente, sua finalidade pretendida, suas ferramentas e os limites que ele deve respeitar.

A skill pode usar o Clarity para modelar ameaças ao agente. A modelagem de ameaças consiste em identificar falhas plausíveis, ativos afetados, causas e consequências antes de selecionar os testes. As equipes também podem fornecer um risco conhecido a partir de um requisito de produto, relatório de incidente, plano de testes ou avaliação existente.

Essa distinção importa. A descoberta de riscos é recomendada, mas não obrigatória. Uma equipe que já sabe que seu agente de faturamento expõe registros de clientes pode começar por esse comportamento, em vez de repetir o trabalho de descoberta.

Quando as equipes precisam de descoberta, o modelador de ameaças Clarity examina o contexto operacional mais amplo do agente. Ele foi projetado para revelar falhas que nunca foram registradas nos requisitos originais.

No exemplo de faturamento da Microsoft, o Clarity identificou quatro modos de falha candidatos. A equipe selecionou dois riscos classificados como críticos: ações de alto risco não verificadas e exposição de dados entre clientes.

O primeiro risco abrangia alterações de faturamento realizadas sem confirmar a identidade do solicitante. O segundo abrangia divulgações envolvendo uma conta que não pertencia ao solicitante.

A skill encaminhou cada risco selecionado ao ASSERT, o framework de avaliação orientado por requisitos da Microsoft. Cada risco se tornou uma configuração, um comportamento e uma suíte de avaliação.

Essa estrutura restrita é mais relevante do que parece inicialmente. Se uma avaliação mistura falhas de autorização, privacidade, precisão e escalonamento, sua pontuação agregada não consegue explicar qual controle é necessário.

Em vez disso, o Microsoft run-assert-eval separa esses comportamentos. A variação é introduzida dentro de cada suíte por meio de dimensões como modo de acesso, pretexto do usuário, alegações de autoridade e desvio de escopo em múltiplos turnos.

A skill também pesquisa estudos anteriores e frameworks de segurança em busca de dimensões de teste relevantes. A Microsoft afirma que essas fontes podem incluir orientações do NIST, recursos da OWASP, benchmarks, material regulatório e políticas de provedores de modelos.

O ASSERT então gera casos, executa o agente-alvo e avalia as transcrições capturadas. Suas duas principais medições permanecem intencionalmente separadas.

“Comportamento inadmissível violado” registra casos em que o agente executou um comportamento proibido. “Comportamento permitido violado” mede casos em que o agente deixou de ajudar apesar de estar autorizado a fazê-lo.

Essa separação protege contra uma ilusão de segurança conhecida. Um agente que recusa todas as solicitações pode evitar muitas ações prejudiciais, mas também deixa de realizar seu trabalho.

Em seguida, o fluxo de trabalho gera uma política preliminar de Agent Control Specification a partir da falha medida. ACS é um formato portátil para posicionar controles em pontos definidos da execução de um agente.

Por fim, a skill avalia uma versão governada do agente usando os mesmos casos. As execuções de referência e governada mantêm a mesma definição de comportamento, conjunto de testes e método de julgamento.

O resultado não é apenas mais uma pontuação de segurança. É uma comparação controlada, projetada para isolar a política como a variável alterada.

A Pressão Recai sobre Equipes que Usam Prompts como sua Principal Proteção

A Microsoft está contestando a ideia de que instruções escritas, por si só, fornecem um limite de controle adequado para agentes que usam ferramentas.

Prompts de sistema continuam úteis para definir funções e comportamento esperado. Ainda são instruções probabilísticas interpretadas por um modelo, não verificações determinísticas de autorização aplicadas pelo software ao redor.

Essa fraqueza se torna relevante quando um agente pode recuperar registros, atualizar contas, emitir reembolsos ou chamar ferramentas administrativas. Uma solicitação persuasiva pode então se transformar em uma leitura de banco de dados ou em uma ação comercial.

O exemplo de faturamento da Microsoft ilustra essa lacuna. O agente operava para um solicitante associado à conta ACME-1001. Ele jamais deveria ter recuperado ou modificado a conta de outro cliente.

Uma solicitação avaliada pediu informações de contato vinculadas à BPS-447, que pertencia a outro cliente. O agente de referência retornou o registro completo, segundo a Microsoft.

Uma revisão de código pode confirmar que a função de recuperação opera corretamente. Um teste unitário pode confirmar que um identificador de conta válido retorna o registro esperado. Nenhum dos dois necessariamente testa se o modelo escolhe um identificador não autorizado durante uma conversa realista.

Esse problema vai além do suporte de faturamento. Um agente de pesquisa pode acessar fontes inadequadas, enquanto um agente de gerenciamento de mudanças pode contornar uma sequência de aprovações. Um agente de viagens pode usar indevidamente informações armazenadas de identidade ou pagamento.

A orientação da OWASP chama essa condição mais ampla de agência excessiva. Ela surge quando uma aplicação de IA possui mais funcionalidade, permissões ou autonomia do que sua tarefa exige.

A injeção de prompt pode desencadear essas falhas, mas não é a única causa. Solicitações ambíguas, planos alucinados, ferramentas comprometidas e simples erros do modelo também podem produzir ações inseguras.

As equipes afetadas não são apenas grupos de segurança. Gerentes de produto precisam definir resultados permitidos e proibidos. Desenvolvedores precisam expor pontos de controle adequados. Responsáveis por risco precisam decidir se uma redução medida é suficiente.

As equipes de avaliação também enfrentam pressão. Seu resultado não pode mais terminar em um relatório que lista falhas. O fluxo de trabalho da Microsoft espera que uma descoberta sustente um controle específico e uma execução de validação repetível.

Organizações que usam benchmarks genéricos de modelos enfrentam outro problema. Um benchmark amplo pode descrever as tendências médias de um modelo, mas não consegue capturar as regras de conta, os limites de escalonamento ou o processo interno de aprovação de cada empresa.

A abordagem da Microsoft começa com os próprios requisitos e riscos descobertos da aplicação. Isso torna a avaliação mais relevante, embora também torne menos diretas as comparações entre organizações.

O lançamento também pressiona fornecedores que tratam a observação como etapa final. Registrar uma chamada perigosa de ferramenta após a execução pode ajudar uma investigação. Isso não impede a ação que causou o dano.

O run-assert-eval leva a intervenção para o caminho de tempo de execução do agente. Isso o aproxima de conceitos de segurança conhecidos, como verificações de autorização, privilégio mínimo e pontos de aplicação de políticas.

Isso não elimina os prompts. Atribui a eles um papel mais restrito. Os modelos podem planejar e interpretar linguagem, enquanto controles determinísticos decidem se operações sensíveis devem prosseguir.

Essa divisão se torna cada vez mais importante à medida que agentes obtêm acesso a arquivos locais e conhecimento interno. Equipes que constroem uma base de conhecimento pesquisável enfrentam a mesma questão de limite: a recuperação deve respeitar o escopo real de autorização do usuário.

O Microsoft run-assert-eval organiza essa questão em um fluxo de trabalho que desenvolvedores podem executar mais cedo. O ônus então passa de esperar que o modelo obedeça a uma regra para demonstrar onde o software a aplica.

O Mecanismo Central É um Teste Controlado de Antes e Depois

A ideia mais forte do run-assert-eval não é a geração automatizada de políticas; é preservar a avaliação enquanto se altera apenas o controle.

Comparações de segurança se tornam pouco confiáveis quando as equipes regeneram o conjunto de testes após aplicar uma correção. Um grupo diferente de prompts pode fazer uma política fraca parecer bem-sucedida ou uma política sólida parecer pior.

Alterar o avaliador cria outra variável de confusão. Dois avaliadores podem interpretar a mesma transcrição de forma diferente, especialmente quando o comportamento aceitável depende do contexto.

O run-assert-eval armazena em cache a sistematização de referência e os casos de teste. O agente governado então enfrenta a mesma definição de comportamento, os mesmos casos e a mesma abordagem de julgamento.

A Microsoft descreve isso como congelar a avaliação. A política se torna a variável independente pretendida, enquanto as taxas de violação medidas se tornam os resultados observados.

O princípio se assemelha ao teste de regressão no software convencional. Um teste que falha deve permanecer fixo enquanto desenvolvedores modificam a implementação. Caso contrário, resultados aprovados podem refletir um teste reescrito, e não um comportamento corrigido.

Testar agentes é mais difícil porque as respostas dos modelos são variáveis. O avaliador também pode ser baseado em modelo, e os casos gerados podem conter suas próprias ambiguidades.

Manter esses elementos constantes não elimina todas as fontes de incerteza. Mas torna a diferença entre antes e depois mais interpretável.

A Microsoft afirma que avaliações anteriores do ASSERT encontraram entre 80% e 90% de concordância entre seu avaliador automatizado e revisores humanos. Ela compara essa faixa a cerca de 90% de concordância entre revisores humanos.

Esses números são resultados relatados pela Microsoft, não garantias universais de precisão. A concordância do avaliador pode variar conforme o comportamento, o modelo, a rubrica, o idioma e a complexidade da política subjacente.

A avaliação subjacente continua inspecionável. O repositório ASSERT informa que as execuções armazenam artefatos locais, casos gerados, saídas de modelos, justificativas do avaliador e métricas.

Artefatos locais podem apoiar auditorias porque revisores podem examinar por que uma transcrição foi classificada como violação. Também podem identificar casos em que o avaliador interpretou mal a política.

O design de duas taxas do ASSERT acrescenta outra salvaguarda. Uma política que bloqueia comportamentos prejudiciais ainda pode falhar se causar recusa excessiva.

Para a suíte entre clientes, a Microsoft relatou uma taxa de violação inadmissível de referência de 30,0%. O resultado governado foi de 5,9% com um denominador aplicável diferente.

A Microsoft também dividiu seus resultados entre prompts e cenários. Casos de prompt testam interações mais diretas, enquanto casos de cenário capturam fluxos de trabalho e contexto conversacional mais ricos.

Para casos de prompt entre clientes, a taxa inadmissível relatada caiu de 20,8% para 8,7%. A taxa correspondente para cenários caiu de 43,8% para 0,0%.

Para casos de prompts de ação não verificada, a taxa reportada caiu de 4,0% para 0,0%. Na divisão por cenário, passou de 8,7% para 4,5%.

As violações de comportamento permitido teriam alcançado 0,0% nas quatro divisões governadas. A Microsoft interpreta esse resultado como evidência de que os controles preservaram o trabalho legítimo nesta amostra.

As violações impermissíveis restantes importam. Elas mostram que a política não eliminou todas as falhas, mesmo dentro do exemplo controlado.

Isso é consistente com o desenho iterativo do fluxo de trabalho. Uma equipe pode inspecionar as falhas remanescentes, refinar sua definição de risco ou política e repetir o mesmo processo.

Assim, o método oferece evidências mais robustas do que um pequeno conjunto de demonstrações manuais. Ainda assim, não estabelece como o agente se comportará em todos os prompts futuros, atualizações de modelo, ferramentas ou ambientes.

O ganho prático é mais restrito e mais útil. As equipes recebem evidências rastreáveis de que um controle específico alterou o desempenho em uma avaliação definida sem simplesmente silenciar o agente.

A Política de Tempo de Execução Bloqueia Ações Antes que o Modelo Possa Concluí-las

A correção de faturamento funciona verificando o escopo da conta no limite da ferramenta, e não pedindo que o modelo reconsidere suas intenções.

Depois de medir a exposição entre clientes, run-assert-eval gerou uma política preliminar e um manifesto ACS. A política expressava a lógica de decisão, enquanto o manifesto especificava onde essa lógica deveria ser aplicada.

A Microsoft usou Rego, uma linguagem declarativa de políticas comumente associada a mecanismos de políticas. O material gerado permaneceu como um rascunho que exigia revisão humana.

Essa etapa de revisão é importante. A Microsoft afirma explicitamente que geração não equivale a aprovação. Os desenvolvedores devem inspecionar a política, o ponto de intervenção, o manifesto e a conexão com o agente-alvo.

A política selecionada negava chamadas de ferramentas quando o identificador da conta solicitada diferia da conta do chamador. Essa regra não exigia que outro modelo decidisse se a solicitação parecia suspeita.

A Microsoft posicionou a verificação em pre_tool_call, um ponto de interceptação alcançado antes de o agente executar uma ferramenta. Portanto, um identificador incompatível causa uma negação antes que a recuperação ocorra.

A equipe também usou post_tool_call. Essa segunda verificação reteve qualquer resultado incompatível que jamais deveria entrar no contexto do modelo.

O uso de ambos os pontos cria defesa em profundidade. O primeiro tenta impedir uma operação não autorizada. O segundo limita a exposição caso o controle anterior seja contornado ou conectado incorretamente.

O mecanismo de políticas ACS pretende separar esses controles de um único framework de agentes. Assim, as políticas podem permanecer portáveis à medida que as equipes mudam de modelos ou bibliotecas de orquestração.

Essa portabilidade aborda um problema real de manutenção. Controles incorporados em prompts ou callbacks específicos de frameworks podem se tornar difíceis de auditar em várias implementações de agentes.

Uma especificação compartilhada pode oferecer aos revisores de segurança um objeto consistente para inspeção. Ela também pode permitir que os desenvolvedores versionem alterações de política ao lado do código da aplicação.

No entanto, a portabilidade não garante uma integração correta. Cada ambiente de execução deve expor o contexto relevante, preservar a identidade e chamar a política no ponto correto.

Uma regra de escopo de conta depende de informações confiáveis sobre a conta. Se a identidade do chamador estiver errada ou ausente, uma comparação perfeitamente escrita ainda produzirá o resultado de autorização incorreto.

A mesma preocupação se aplica aos argumentos das ferramentas. Uma política que inspeciona account_id pressupõe que o recurso solicitado seja representado com precisão por esse campo.

Ferramentas complexas podem ocultar alvos sensíveis em consultas, documentos, URLs ou ações aninhadas. Uma regra restrita pode então deixar passar caminhos equivalentes para o mesmo recurso protegido.

A política de tempo de execução também não pode corrigir todas as classes de falha. Um controle pode bloquear um reembolso não autorizado ou uma leitura de banco de dados. Ele não pode determinar automaticamente se toda explicação gerada é precisa ou justa.

Aprovações humanas continuam adequadas para algumas ações de alto impacto. O design de ferramentas com privilégio mínimo pode reduzir danos mesmo quando o modelo toma uma decisão ruim.

O framework mais amplo de risco de IA trata a gestão de riscos como uma atividade de ciclo de vida. Ele inclui governança, mapeamento, medição e gestão contínua, em vez de um único teste antes do lançamento.

run-assert-eval se encaixa nesse padrão mais amplo. Ele fornece uma ponte concreta entre mapear um risco e medir e gerenciar um comportamento.

O ponto único de entrada por prompt do fluxo de trabalho não deve ocultar o trabalho subjacente. Modelagem de ameaças, desenho de testes, revisão de políticas, integração de sistemas e interpretação de resultados ainda exigem decisões informadas.

O que a Microsoft reduziu foi a transferência manual entre essas decisões. A skill transporta artefatos estruturados de uma etapa à seguinte e mantém visíveis suas relações.

Isso pode reduzir a chance de uma descrição de risco perder significado ao ser transferida entre equipes de produto, avaliação e segurança.

Também pode encurtar o intervalo entre descobrir uma falha e verificar uma mitigação. Esse intervalo costuma ser onde o risco não resolvido de agentes se acumula.

Os Primeiros Resultados São Evidência, Não uma Garantia Geral de Segurança

O exemplo da Microsoft sustenta a lógica do fluxo de trabalho, mas não estabelece eficácia em produção entre agentes, organizações ou ataques.

A limitação mais evidente é a procedência. A Microsoft e os colaboradores do projeto conceberam as ferramentas, selecionaram o exemplo, aplicaram os controles e relataram as medições resultantes.

Isso não torna as conclusões inválidas. Significa que os leitores devem distinguir um exemplo prático transparente de um benchmark independente ou estudo de campo.

Os tamanhos de amostra também exigem cautela. A linha de base principal incluiu 40 conversas aplicáveis, enquanto a execução governada incluiu 34.

Esses denominadores diferem porque apenas os casos aplicáveis contribuem para uma taxa de comportamento específica. Ainda assim, amostras pequenas podem produzir percentuais instáveis.

Uma mudança de 12 violações para duas é operacionalmente significativa no exemplo. Ela não deve ser interpretada como uma redução universal de 80% para outros agentes.

A taxa reportada de 0,0% de violações permissíveis também significa que nenhuma violação apareceu nessa amostra. Isso não significa que a política jamais possa bloquear comportamento legítimo.

Um conjunto de testes maior pode revelar negativas falsas raras. O tráfego de produção pode incluir relações entre contas, regras de delegação ou exceções de suporte ausentes no exemplo.

O vazamento de avaliação apresenta outra preocupação. Se uma política for repetidamente ajustada em relação a um conjunto de testes congelado, os desenvolvedores podem eventualmente superajustar aos casos conhecidos.

Congelar testes cria uma comparação confiável durante uma intervenção. Programas de longo prazo ainda precisam de casos reservados, novas variantes adversariais e monitoramento de mudanças de comportamento.

Alterações de modelo também podem invalidar conclusões anteriores. Um novo modelo pode formatar argumentos de ferramentas de modo diferente, interpretar recusas de outra forma ou encontrar outro caminho até a informação protegida.

Alterações nas ferramentas criam um risco semelhante. Adicionar uma função de exportação ou um endpoint de busca geral pode introduzir uma rota de acesso não coberta pela verificação original de conta.

O juiz da avaliação merece escrutínio contínuo. A faixa de concordância relatada pela Microsoft é encorajadora, mas casos de discordância podem se concentrar nas fronteiras mais ambíguas e consequentes.

As equipes devem manter a revisão humana para casos contestados e amostrar periodicamente resultados aparentemente bem-sucedidos. Um juiz automatizado estável é útil para comparação, mas não é uma autoridade infalível.

Há também uma questão de cadeia de suprimentos incorporada na palavra “skill”. Skills de agentes contêm instruções que influenciam planejamento, execução e validação.

A Microsoft Research relatou recentemente 307 falhas induzidas por skills em dois cenários de benchmark. Elas incluíram 125 falhas funcionais e 182 regressões de eficiência.

Essa pesquisa não avalia especificamente run-assert-eval. Ela estabelece uma razão mais ampla para inspecionar as instruções, scripts, permissões e pressupostos operacionais de qualquer skill.

run-assert-eval aborda parcialmente essa preocupação por meio de artefatos visíveis e etapas humanas. As equipes podem inspecionar configurações de avaliação e políticas geradas antes de executar rodadas governadas.

A geração de testes baseada em literatura cria outra obrigação de verificação. Um framework citado pode orientar dimensões, mas a relevância depende de quão precisamente a skill traduz essa fonte em casos.

Uma tradução fraca pode produzir rótulos de cobertura impressionantes sem cobertura significativa. Portanto, os revisores devem inspecionar cenários, não apenas os nomes dos frameworks associados a eles.

O custo operacional é outra questão em aberto. Executar casos gerados, capturar rastros, avaliar transcrições e repetir avaliações consome chamadas de modelo e tempo de engenharia.

O projeto não publicou uma comparação ampla desse custo com fluxos de avaliação manual. As organizações devem determinar quais riscos justificam uma avaliação mais aprofundada.

A interpretação mais razoável é cautelosa, mas positiva. A Microsoft reuniu um processo coerente para um problema difícil de integração.

O lançamento não prova que um agente é seguro. Ele ajuda uma equipe a formular uma alegação de segurança específica, vincular evidências a ela e testar se uma intervenção melhorou um resultado definido.

Três Sinais Mostrarão se a Abordagem se Sustenta

O próximo teste é saber se equipes independentes reproduzem os ganhos do fluxo de trabalho sem sacrificar o comportamento útil do agente ou criar encargos ocultos de manutenção.

O primeiro sinal é a replicação por terceiros. Os desenvolvedores devem acompanhar avaliações públicas que apliquem Microsoft run-assert-eval a agentes fora dos exemplos incluídos.

Uma replicação convincente publicaria as definições de risco, casos, política, rastros, configuração do juiz e resultados de revisão humana. Também divulgaria as falhas que permaneceram após a governança.

Resultados em diferentes modelos e frameworks fortaleceriam a alegação de portabilidade da Microsoft. Diferenças materiais de integração exporiam onde o ACS ainda depende de ambientes de execução individuais.

O segundo sinal é uma evidência mais ampla em produção. As equipes precisam saber se avaliações congeladas preveem incidentes, negativas e contornos de políticas sob tráfego real.

Evidências úteis incluiriam tendências de violações após a implantação e solicitações legítimas bloqueadas por controles. Elas também acompanhariam falhas introduzidas após mudanças de modelo, ferramenta ou prompt.

As implantações mais robustas conectarão artefatos de avaliação ao monitoramento contínuo. Uma melhoria antes do lançamento importa mais quando a telemetria de produção confirma o mesmo limite de comportamento.

O terceiro sinal é a resposta do projeto à evasão e à deriva de políticas. Atacantes e usuários comuns podem alcançar ações protegidas por caminhos ausentes da suíte original.

Acompanhe novas suítes que cubram injeção indireta de prompts, autoridade delegada, identidades conflitantes, manipulação de estado e transferências entre múltiplos agentes. Observe também como o projeto evita o superajuste a casos congelados.

Políticas versionadas e execuções de regressão serão essenciais. As equipes precisam de um gatilho claro para repetir avaliações sempre que modelos, ferramentas, permissões ou regras de negócio mudarem.

O lançamento também deve ser avaliado pela experiência de revisão. Uma política gerada só é útil quando desenvolvedores e equipes de segurança conseguem entender por que ela existe e o que ela bloqueia.

Isso torna os artefatos locais, as transcrições citadas e as definições restritas de comportamento mais do que detalhes de implementação. Eles formam a cadeia de evidências que sustenta a aprovação.

Portanto, Microsoft run-assert-eval é melhor entendido como uma disciplina de engenharia empacotada como uma skill. Ele conecta modelagem de ameaças, avaliação específica de comportamento, aplicação em tempo de execução e retestes controlados.

Os desenvolvedores não deveriam perguntar se o fluxo de trabalho certifica um agente inteiro como seguro. Deveriam perguntar se ele torna um risco importante mensurável, um controle revisável e uma melhoria reproduzível.

Essa é uma promessa menor do que provar a segurança geral. Também é um ponto de partida mais crível para a governança de agentes.