Agent Control Standard: como provar controles em runtime sem chamar preview de garantia

Um agente pode receber uma política perfeita no prompt e ainda executar uma ação indevida. Entre a intenção escrita e o efeito no mundo existem ferramentas, identidades, argumentos, estado, memória e integrações. É nesse caminho que controles precisam ser observáveis e aplicáveis.

O Agent Control Standard (ACS), apresentado pelo OWASP GenAI Security Project como preview público v0.1, propõe uma linguagem comum para instrumentar, rastrear, inspecionar e controlar agentes em runtime. O projeto é relevante porque desloca governança do documento para o ponto de execução. Ele ainda não é prova de eficácia, adoção ou conformidade.

Estado: Evidence Brief técnico aprovado para publicação. A análise foi fechada em 02/09/2026 e descreve o estágio público observado nessa data. Componentes, contagens e roadmap podem mudar.

O problema que o ACS tenta resolver

Aplicações agênticas diferem de uma chamada simples a modelo porque escolhem caminhos, usam ferramentas e podem produzir efeitos fora da interface de conversa. Um controle útil precisa responder, no mínimo:

• qual agente tentou agir;
• com qual identidade, escopo e objetivo;
• que ferramenta e argumentos foram solicitados;
• qual política foi avaliada;
• se a ação foi permitida, negada ou modificada;
• que resultado material ocorreu;
• qual humano ou sistema tinha autoridade para interromper e recuperar.

Registrar apenas prompt e resposta não cobre essa cadeia. Tampouco basta pedir ao próprio modelo que declare se agiu corretamente.

O que a versão pública propõe

A página oficial do OWASP GenAI Security Project e o repositório do padrão descrevem quatro blocos principais:

1. hooks de runtime para observar decisões e chamadas de ferramentas;
2. um contexto de política que acompanha a execução;
3. decisões de enforcement como allow, deny e modify;
4. registros portáveis de telemetria e composição do agente.

O projeto aproxima seus eventos de convenções como OpenTelemetry e OCSF e propõe um Agent Bill of Materials, ou AgBOM, para declarar componentes relevantes da aplicação. Na documentação consultada, a integração com OpenTelemetry aparece como ativa, o AgBOM como trabalho em andamento e integrações MCP/A2A como planejadas.

Essa distinção de estado é importante. “Previsto no roadmap” não significa “implementado”; “implementado no projeto” não significa “validado no seu ambiente”; “evento registrado” não significa “controle eficaz”.

Arquitetura mínima de integração

Uma implementação responsável pode tratar o ACS como adaptador entre o runtime do agente e a camada de política:

intenção de produto
        |
        v
agente -> hook de ação -> policy decision point -> ferramenta
              |                 |                    |
              +------ trace + receipt <--------------+
                               |
                         revisão / incidente

O hook coleta contexto antes da execução. O ponto de decisão avalia regras fora do modelo. A ferramenta recebe apenas a ação autorizada. O receipt registra decisão, versões e resultado sem expor segredos ou dados pessoais desnecessários.

O controle precisa falhar de modo seguro. Se a política estiver indisponível, ações de alto impacto não devem herdar permissão implícita. O comportamento de fallback deve ser decidido por classe de risco, documentado e testado.

O contrato que deve existir antes do código

Para cada ferramenta, registre:

O AgBOM pode ajudar a responder “o que compõe este agente?”, mas não substitui SBOM, inventário de dados, IAM, threat model ou evidência de deployment. O artefato precisa apontar para versões realmente executadas.

Testes mínimos para um piloto

Um piloto não deve começar por cobertura total. Deve demonstrar que a fronteira de autoridade funciona nos cenários mais relevantes:

1. uma ação permitida chega à ferramenta com escopo reduzido;
2. uma ação proibida é negada antes de produzir efeito;
3. uma ação modificada não permite recuperar os argumentos originais;
4. ausência ou timeout do motor de política bloqueia a classe crítica;
5. troca de identidade ou contexto invalida a decisão anterior;
6. replay não duplica uma ação irreversível;
7. logs preservam correlação sem armazenar credenciais ou conteúdo desnecessário;
8. um operador consegue reconstruir decisão, execução e resultado;
9. revogação interrompe novas ações e conduz o estado para recuperação;
10. atualização de agente, ferramenta ou política dispara regressão.

O perfil exato depende do produto e precisa de threat modeling. Fontes anteriores sobre sandbox, AISVS e cadeia de entrega ajudam a estruturar o problema, mas não certificam uma implantação nem definem um controle universal. [R2-C3]

O que ainda não pode ser afirmado

Na data de corte, o ACS era um preview v0.1 em implementação ativa. Não localizamos benchmark independente de redução de incidentes, base pública de adoção em produção, comparação controlada com outras abordagens ou certificação associada ao padrão.

O AI Security Standards Crosswalk do mesmo ecossistema também exige cautela. Páginas públicas consultadas exibiam contagens diferentes de entradas, frameworks e mapeamentos; o próprio projeto informa que mapeamentos permanecem sem revisão até a assinatura de um revisor identificado. Portanto, o crosswalk pode apoiar navegação e hipótese de cobertura, mas não deve ser usado como selo de conformidade.

As publicações do NIST sobre identidade para agentes e sua síntese de respostas sobre segurança de sistemas agênticos corroboram o problema geral: agentes precisam de identidade, autorização e auditabilidade fortes. Elas não validam uma implementação específica do ACS.

Critério de adoção

Adote o padrão primeiro como contrato de interoperabilidade e experimento controlado, não como alegação de segurança. Uma decisão de produção deve exigir:

• compatibilidade real com os runtimes e ferramentas usados;
• latência e disponibilidade medidas no caminho crítico;
• políticas externas ao modelo e versionadas;
• evidência de negação, revogação e recuperação;
• minimização e proteção da telemetria;
• operação testada quando o componente de controle falha;
• revisão de mudanças do padrão antes de atualizar a integração.

O sinal mais importante não é quantos eventos foram gerados. É se a organização consegue impedir um efeito proibido, explicar uma decisão e recuperar o sistema quando o fluxo foge do esperado.

Fontes e contexto editorial

1. OWASP GenAI Security Project — Agent Control Standard. Página do projeto; fonte primária e interessada na adoção da proposta.
2. Agent Control Standard — documentação. Documentação oficial da versão pública consultada em 02/09/2026.
3. Agent Control Standard — repositório. Código e roadmap públicos; atividade de repositório não prova eficácia operacional.
4. OWASP AI Security Standards Crosswalk. Mapeamento comunitário em evolução; contagens públicas divergiam e itens sem assinatura permaneciam não revisados no corte.
5. NIST — Why Agentic AI Needs a Strong Identity Foundation. Apoia a necessidade de identidade forte, não uma implementação do ACS.
6. NIST — Summary and Analysis of Responses on Security Considerations for AI Agent Systems. Síntese de contribuições recebidas; não é benchmark do ACS.

Nota editorial e de responsabilidade

Este texto combina fatos atribuídos às fontes com análise e recomendações técnicas do autor. O ACS é apresentado como preview público v0.1, não como garantia de segurança, certificação ou evidência de conformidade. Pontos de vista pessoais e profissionais não devem ser confundidos com fatos comprovados; quando há dados ou estados de implementação, a fonte, o corte e as limitações são indicados. O conteúdo é informativo e não substitui threat modeling, teste, revisão jurídica, avaliação de privacidade ou auditoria independente. Tech Human e Trustyu atuam comercialmente em temas relacionados. Pesquisa, estrutura e redação tiveram assistência de IA; a versão publicável recebeu revisão factual, revisão autoral e aprovação editorial em 02/09/2026, sem revisão humana independente.

Corte da pesquisa: 02/09/2026. Estado editorial: publicação especial antecipada por decisão explícita para 02/09/2026 às 09h25 BRT.