Proof-of-Control da Advanced AI Society abre uma nova frente na segurança de agentes

A Advanced AI Society lançou o Proof-of-Control para revisão pública em 17 de setembro, apesar de persistirem questões sobre a versão, o escopo e a maturidade do rascunho. O padrão proposto pede que agentes de IA produzam evidências invioláveis que mostrem que cada ação controlada permaneceu dentro de seus limites autorizados. Ele também desloca a segurança dos agentes da confiança nos logs privados de um fornecedor.

Essa mudança importa porque os agentes estão indo além da geração de texto. Eles podem acionar ferramentas, acessar registros, alterar software, comunicar-se com serviços externos e iniciar transações. Uma auditoria trimestral não consegue observar cada decisão no momento em que ocorre, enquanto um log controlado pelo operador do agente pode oferecer garantia independente limitada.

A Advanced AI Society afirma que mais de 80 líderes de segurança ajudaram a moldar sua abordagem. O grupo está inserindo o trabalho na Linux Foundation Decentralized Trust, o que oferece ao projeto um espaço neutro para governança técnica. No entanto, uma governança neutra não torna um rascunho completo, nem evidências criptográficas garantem que uma organização tenha escolhido os controles corretos.

O Congresso está abordando o mesmo problema por outro caminho. Uma proposta bipartidária da Câmara direcionaria o NIST a desenvolver práticas de segurança para agentes que abranjam verificação contínua, avaliação de segurança, inventários e registros resistentes a adulteração. O choque entre padrões abertos voluntários e requisitos respaldados pelo governo cria a verdadeira história.

O Proof-of-Control da Advanced AI Society é mais do que um anúncio de associação

A mudança importante é o lançamento de uma proposta inspecionável de verificação de agentes, não a manchete sobre a associação que a acompanha.

A Advanced AI Society descreveu seu anúncio de setembro como uma entrada na Linux Foundation e na LF Decentralized Trust. Porém, registros da Linux Foundation mostram que a organização se tornou membro associado da LF Decentralized Trust em 21 de abril de 2026. Portanto, o anúncio mais recente combina um desenvolvimento anterior de associação com a apresentação pública do Proof-of-Control e de seu laboratório associado.

Essa distinção importa. A associação coloca uma organização em uma rede colaborativa, mas não valida cada afirmação ou projeto técnico que ela publica. A ação consequente é levar um padrão de verificação proposto para um ambiente de fundação, onde colaboradores externos podem inspecioná-lo, contestá-lo e ampliá-lo.

O registro de associação de abril identifica a Advanced AI Society como um dos dois novos membros associados. O aviso de lançamento de setembro apresenta o Proof-of-Control como um laboratório da LF Decentralized Trust e convida a comentários públicos.

O Proof-of-Control foi concebido em torno de uma pergunta direta: uma parte independente consegue verificar se um agente de IA permaneceu dentro de seus controles atribuídos? Um controle pode impedir que um agente mova dinheiro sem aprovação, restringir quais registros de clientes ele pode acessar ou limitar as ferramentas disponíveis durante uma tarefa.

A proposta se concentra no limite da ação, o ponto em que um agente tenta acionar uma ferramenta ou criar um efeito externo. Sua arquitetura coloca um gateway de interceptação separado nesse limite. O gateway avalia a ação proposta, bloqueia ações fora da política declarada e emite evidências sobre a decisão.

Esse desenho é mais específico do que promessas convencionais sobre IA responsável. Ele descreve onde a aplicação ocorre, que evidências devem ser produzidas e como outra parte poderia verificá-las. A Advanced AI Society também identifica seis domínios de verificação: procedência, privacidade, portabilidade, autorização, identidade e segurança.

A ideia central do framework é que o log de execução de um agente continua sendo uma alegação quando o mesmo operador controla tanto a execução quanto o registro. Um sistema comprometido poderia omitir uma ação, reescrever um registro ou contornar a geração de logs. Portanto, um mecanismo de verificação útil precisa expor alterações e identificar as premissas das quais suas evidências dependem.

O projeto propõe vários níveis de garantia. Os níveis inferiores dependem de declarações do operador ou do acesso de um auditor. Os níveis superiores buscam registros verificáveis de forma independente ou barreiras de execução que impeçam uma ação controlada sem a evidência correspondente.

Isso cria uma distinção significativa entre observar uma ação e restringi-la. Um registro inviolável pode ajudar investigadores a estabelecer o que foi registrado após um incidente. Uma barreira de execução corretamente implementada pode impedir uma ação coberta quando suas condições de autorização falham.

O Proof-of-Control não afirma determinar se o modelo subjacente é seguro, preciso ou alinhado. Tampouco decide se uma empresa concedeu autoridade excessiva a um agente. Ele busca estabelecer se os controles declarados regeram as ações incluídas em um escopo definido.

Esse objetivo mais restrito é uma força porque oferece aos implementadores algo testável. Também é a origem da maior limitação do projeto. Evidências de que um agente seguiu uma política fraca apenas comprovam conformidade com essa política fraca.

O Congresso está transformando a verificação de agentes em uma questão de compras

A segurança de agentes está deixando de ser uma preferência técnica para se tornar uma condição para fazer negócios com compradores regulados e o governo federal.

A proposta Stop Rogue AI Act direcionaria o National Institute of Standards and Technology a publicar padrões, diretrizes e melhores práticas para a implantação segura de agentes. Segundo detalhes reportados sobre o projeto, o trabalho abrangeria inventários contínuos de agentes, avaliações de segurança, logs resistentes a adulteração e verificação das ações dos agentes.

A proposta vem dos representantes Josh Gottheimer, democrata de Nova Jersey, e Mike Lawler, republicano de Nova York. A maioria das organizações usaria voluntariamente as práticas resultantes do NIST. Empreiteiras federais que competem por novos contratos enfrentariam pressão maior para cumpri-las.

Esse mecanismo importa mais do que uma ampla declaração regulatória. Requisitos de compras podem influenciar mercados de tecnologia sem impor uma arquitetura obrigatória a todas as organizações privadas. Fornecedores frequentemente adotam controles voltados ao governo em todos os seus produtos porque manter sistemas de segurança separados aumenta custos e complexidade.

O NIST já trabalhava nessa área antes do surgimento da proposta da Câmara. Em fevereiro, a agência anunciou uma iniciativa de padrões para agentes que abrange interoperabilidade, identidade, autorização e segurança. Também solicitou contribuições de organizações que implantam sistemas, desenvolvedores, pesquisadores e provedores de infraestrutura.

A sobreposição com o Proof-of-Control é clara. Ambos os esforços se concentram em identidade persistente, autoridade definida, ações observáveis e evidências que sobrevivem fora da própria narrativa do agente. Ambos também reconhecem que os agentes interagem com sistemas existentes por meio de ferramentas, credenciais e interfaces de serviços.

Seus papéis continuam distintos. O NIST desenvolve orientações por meio de um processo federal de padronização e pode influenciar expectativas de compras. A Advanced AI Society está propondo um padrão orientado à implementação por meio de uma comunidade aberta e quer que ferramentas de verificação independente se desenvolvam ao seu redor.

A proposta da Câmara cria pressão sobre três grupos. Fornecedores de agentes precisam explicar como seus sistemas identificam cada agente e restringem suas permissões. Organizações empresariais que implantam esses sistemas precisam manter inventários e determinar quais sistemas podem executar ações consequentes. Provedores de segurança precisam gerar evidências que avaliadores externos possam examinar.

Empreiteiras federais enfrentam o potencial mecanismo de pressão mais claro. Um fornecedor pode tratar a verificação aberta como opcional ao vender para mercados comerciais comuns. Essa posição se torna mais difícil de sustentar quando um grande comprador exige inventários legíveis por máquina, registros contínuos e controles testáveis de forma independente.

Seguradoras e auditores criam outra fonte de pressão. Uma seguradora que avalia um agente capaz de iniciar pagamentos precisa de mais do que um documento de política. Ela precisa de evidências que mostrem qual identidade agiu, que autoridade existia, qual controle avaliou a solicitação e se o registro resultante permaneceu intacto.

A mesma questão aparece na saúde. Um agente pode recuperar prontuários médicos, resumir um caso ou preparar uma ordem. Um hospital precisa distinguir entre confirmar a integridade do registro e confirmar que a decisão clínica foi apropriada. O Proof-of-Control trata do primeiro aspecto, enquanto a governança e a revisão profissional ainda determinam o segundo.

Os desenvolvedores sentirão a mudança nos pontos de integração. A segurança não pode mais terminar na proteção de um endpoint de modelo. As equipes precisam considerar credenciais, permissões de ferramentas, cadeias de delegação, acesso a dados e efeitos colaterais em cada serviço que um agente pode alcançar.

É por isso que a segurança de agentes está se tornando uma questão de compras, e não uma comparação de funcionalidades. Os compradores precisam de evidências que continuem significativas entre fornecedores. Painéis proprietários ajudam operadores a gerenciar seus próprios sistemas, mas não criam automaticamente uma linguagem compartilhada de garantia para auditores, seguradoras, reguladores e clientes.

A verificação aberta desafia logs controlados por fornecedores

A principal disputa é entre evidências portáteis de terceiros e registros de segurança que permanecem sob controle do fornecedor avaliado.

Logs empresariais tradicionais não são inúteis. Eles apoiam resposta a incidentes, monitoramento, depuração e conformidade. O problema é que o valor de um log depende de quem o gerou, se ele capturou todos os caminhos relevantes e se alguém poderia alterá-lo depois.

Agentes de IA tornam essas questões mais difíceis. Suas ações podem depender de contexto em mudança, dados recuperados, saída do modelo, respostas de ferramentas e permissões delegadas. Um sistema pode registrar a chamada final de ferramenta sem preservar contexto suficiente para estabelecer por que a chamada foi autorizada.

O Proof-of-Control propõe evidências geradas durante a execução, não reconstruídas após um incidente. Ele também busca registros portáteis que diferentes partes possam interpretar sem obter acesso privilegiado a todo o ambiente do operador.

A visão geral do padrão publicada pelo projeto descreve as evidências como binárias, contemporâneas, invioláveis e transparentes quanto às premissas residuais de confiança. Binário significa que a ação controlada permaneceu dentro do limite declarado ou não permaneceu. Isso não significa que o resultado mais amplo estava correto.

Considere um agente de compras autorizado a fazer pedidos abaixo de um limite definido pela empresa. A camada de verificação poderia registrar a identidade do agente, a autoridade delegada, o valor avaliado e o resultado da política. Ela também poderia rejeitar um pedido que excedesse esse limite.

No entanto, as evidências não estabeleceriam que a compra era necessária, que o fornecedor era confiável ou que o preço representava um bom valor. Esses são julgamentos empresariais separados. A verificação mostra se um controle explícito foi mantido, não se a organização projetou um controle sensato.

Essa separação é essencial porque a linguagem de segurança frequentemente reúne várias alegações diferentes. Um fornecedor pode descrever um agente como seguro porque ele possui permissões, logs de auditoria e opções de aprovação humana. Esses recursos não comprovam que não exista uma rota de contorno ou que toda ação consequente passe pelo ponto de controle.

O gateway de interceptação de ações proposto pelo Proof-of-Control tenta resolver esse problema. Ele fica fora do processo do agente e intermedeia chamadas de ferramentas controladas. Para que a arquitetura funcione, o agente não pode ter nenhuma credencial alternativa ou rota de rede que contorne o gateway.

Essa condição de não contorno é difícil de assegurar. Ambientes de software modernos contêm contas de serviço, credenciais em cache, processos em segundo plano, plug-ins e rotas diretas de rede. Um verificador precisa testar o sistema ao redor, não apenas inspecionar a saída do gateway.

A proposta também introduz trade-offs de privacidade. As evidências de verificação precisam informar o suficiente para sustentar uma conclusão significativa sem expor prompts, registros pessoais, pesos de modelos ou dados comerciais proprietários. Alegações criptográficas podem reduzir a divulgação, mas sua utilidade depende da qualidade da medição e da implementação subjacentes.

A portabilidade traz outro desafio. Dois fornecedores podem usar linguagens de política, sistemas de identidade, ambientes de execução e formatos de log diferentes. Um esquema de evidências compartilhado pode normalizar parte dessa variação. Ele não consegue eliminar todas as diferenças na forma como os controles originais foram definidos ou aplicados.

A governança aberta oferece uma resposta crível a essa fragmentação. Especificações públicas, vetores de teste, código de referência e modelos de ameaça documentados fornecem aos compradores e pesquisadores material que podem inspecionar. Um programa de garantia controlado por fornecedor pode divulgar menos informações e mudar sem acordo externo.

A Linux Foundation fornece infraestrutura institucional para esse trabalho. Ela pode apoiar a governança comunitária, regras de propriedade intelectual, processos de contribuição e administração de longo prazo. Ela não certifica que o projeto tenha resolvido a contenção de agentes ou a adoção empresarial.

Esse limite deve permanecer visível. A hospedagem por uma fundação é evidência de que um projeto dispõe de um espaço para colaboração. Não é evidência de que toda implantação esteja em conformidade, de que toda prova seja completa ou de que os clientes aceitarão os registros resultantes.

O Rascunho Já Mostra Por Que a Revisão Independente Importa

As inconsistências iniciais do Proof-of-Control revelam a diferença entre lançar um padrão e estabelecê-lo.

O anúncio de setembro da Advanced AI Society chama o lançamento de “rascunho de trabalho v1.0” e diz que os comentários públicos permanecem abertos até 30 de outubro de 2026. Sua página mais detalhada sobre o padrão identifica o documento como “Working Draft v0.1” e lista 7 de outubro como prazo para comentários.

A descrição do evento da Linux Foundation também o chama de Proof-of-Control v0.1. Essas diferenças podem refletir publicação não sincronizada, uma mudança no plano de lançamento ou rótulos distintos para artefatos relacionados. Seja qual for o motivo, a ambiguidade sobre versão e prazo é relevante para colaboradores que decidem o que revisar.

Um padrão depende de identificadores estáveis. Os implementadores precisam saber quais requisitos normativos se aplicam, se um vetor de teste corresponde ao texto atual e quando ocorreu uma mudança incompatível. Auditores não podem avaliar a conformidade com base em um rótulo móvel.

Isso não invalida o objetivo do projeto. Demonstra por que repositórios neutros, tags de lançamento, registros de mudanças e rastreamento público de issues são importantes. Um padrão aberto precisa tornar sua própria proveniência verificável antes de pedir aos fornecedores de agentes que façam o mesmo.

A sessão informativa pública planejada está marcada para 23 de setembro. Ela reúne líderes da Linux Foundation, representantes da Advanced AI Society, investidores em segurança, provedores de identidade, seguradoras e a Agentic AI Foundation.

Esse evento pode esclarecer a governança, mas a discussão pública por si só não resolverá a incerteza técnica. Os colaboradores precisam de uma especificação normativa, um modelo de ameaça explícito, testes de conformidade e implementações reproduzíveis. Também precisam de um processo para decidir quais mecanismos satisfazem cada requisito.

O projeto afirma que seu repositório inclui uma implementação de referência, definições de alegações legíveis por máquina, cenários de ataque e vetores de teste assinados. Ele descreve a implementação como referência, e não como produto de produção. Esse aviso é importante porque o código inicial pode demonstrar viabilidade sem atender aos requisitos de segurança operacional.

Um gateway de referência pode mostrar como avaliar uma política e criar evidências assinadas. Um gateway de produção também precisa resistir a roubo de credenciais, condições de corrida, tentativas de repetição, telemetria incompleta, comprometimento de chaves, falhas de infraestrutura e operadores hostis.

A completude cria outro problema difícil. Registros à prova de adulteração podem mostrar que as entradas registradas não foram alteradas. Eles não podem, por si só, comprovar que toda ação relevante entrou no registro. Um agente com uma rota não monitorada pode agir fora do registro enquanto a cadeia visível de evidências permanece internamente consistente.

A camada mais forte proposta pela Advanced AI Society trata disso por meio do controle da execução. Sob esse modelo, uma ação coberta não pode ocorrer a menos que passe pelo controle e produza evidências. A questão restante é se toda ação consequente está realmente coberta.

Os efeitos externos também complicam o cenário. Um gateway pode verificar que um agente enviou uma solicitação de pagamento autorizada. Ele não pode comprovar automaticamente que um banco liquidou o pagamento exatamente como esperado. A garantia precisa conectar as evidências do lado do agente aos comprovantes de sistemas externos.

Cadeias de identidade introduzem riscos semelhantes. Um agente pode delegar trabalho a outro, que então chama um serviço de terceiros. Cada transferência pode alterar autoridade, contexto ou exposição de dados. Um padrão crível deve preservar a atribuição sem presumir que um único token de identidade explique toda a cadeia.

A qualidade do controle continua sendo a maior limitação conceitual. O Proof-of-Control evita explicitamente julgar se uma regra escolhida foi sensata. Essa separação torna a conformidade técnica administrável, mas as organizações podem comercializar a conformidade como evidência mais ampla de segurança.

Os compradores devem resistir a esse atalho. Um agente verificado pode seguir fielmente uma política insegura. Também pode produzir ações autorizadas com base em raciocínio incorreto do modelo. A verificação em tempo de execução complementa testes, supervisão humana, análise de riscos e resposta a incidentes. Ela não os substitui.

A alegação mais responsável do projeto é, portanto, a mais restrita. Ele busca melhorar as evidências sobre se controles declarados governaram ações cobertas. Alegações sobre segurança completa de agentes, conformidade regulatória ou eliminação de responsabilidade excederiam o que essas evidências estabelecem.

O Padrão Precisa Provar Que Funciona em Pilhas Reais de Agentes

A adoção dependerá de o Proof-of-Control conseguir operar entre modelos hospedados, sistemas locais e fluxos de trabalho com vários fornecedores sem criar outra camada isolada de conformidade.

As pilhas empresariais de agentes raramente vêm de um único fornecedor. Uma empresa pode usar um modelo hospedado, uma estrutura interna de orquestração, um provedor terceirizado de identidade, bancos de dados em nuvem e ferramentas especializadas de diversos fornecedores. Cada camada expõe controles e telemetria diferentes.

O Proof-of-Control afirma que seu modelo de limite de ação pode funcionar em configurações abertas e fechadas. O provedor do modelo não necessariamente precisa revelar seus pesos ou dados de treinamento. Em vez disso, a camada de verificação observa ações controladas quando o sistema de orquestração invoca capacidades externas.

Essa abordagem favorece organizações que controlam seu próprio ciclo de agentes. Elas podem inserir um gateway, restringir credenciais e direcionar chamadas de ferramentas por um limite definido. Um serviço de agentes gerenciado é mais difícil porque o fornecedor controla o ambiente de orquestração e decide quais evidências expor.

Essa diferença transforma a arquitetura em um critério de compra. Clientes que avaliam um agente gerenciado precisam perguntar se ele emite evidências verificáveis de forma independente, se as evidências cobrem todas as chamadas relevantes de ferramentas e se um operador pode contornar o caminho declarado.

Uma equipe financeira oferece um teste concreto. Suponha que um agente prepare faturas, atualize registros contábeis e inicie transferências bancárias. O sistema de verificação precisa distinguir entre ler um livro-razão, propor um pagamento, obter aprovação e enviar a instrução final.

Cada ação precisa de uma identidade, fonte de autoridade, política aplicável, referência temporal e resultado. O sistema deve preservar essa cadeia entre ferramentas sem vazar dados de conta em um registro público de verificação. Também precisa lidar com uma aprovação revogada ou uma mudança de política durante a execução.

Um agente de engenharia de software cria um teste diferente. Ele pode inspecionar código privado, modificar arquivos, executar testes e solicitar implantação. O Proof-of-Control poderia verificar qual repositório o agente acessou e se a implantação exigiu uma aprovação nomeada.

O padrão ainda precisaria considerar efeitos indiretos. Código que passa por um controle de autorização pode posteriormente expor dados ou alterar o comportamento de produção. As evidências de execução mostram como o agente atravessou um limite, enquanto a revisão de software e os testes de segurança avaliam o artefato que ele produziu.

A área da saúde testa a privacidade e a autoridade profissional. Um agente pode recuperar o prontuário de um paciente sob delegação de um clínico e enviar um rascunho de solicitação para aprovação. As evidências devem comprovar que o acesso permaneceu dentro da autorização sem revelar as informações médicas subjacentes.

Esses cenários exigem mais do que um log genérico assinado. Eles precisam de semântica comum para identidades, permissões, avaliação de políticas, retenção de evidências e comportamento em caso de falha. Um registro que um verificador interpreta de forma diferente de outro não cria interoperabilidade.

Os testes de conformidade, portanto, decidirão a credibilidade do projeto. Equipes independentes devem conseguir executar o mesmo conjunto de testes em implementações separadas e obter resultados consistentes. Testes negativos devem mostrar como os sistemas falham quando registros são alterados, ações contornam o gateway ou uma autorização expira.

O desempenho também será importante. Os agentes frequentemente fazem várias chamadas de ferramentas durante uma tarefa. A geração contínua de evidências acrescenta trabalho de assinatura, armazenamento, verificação e avaliação de políticas. As empresas precisarão de dados de latência e operação de implantações representativas.

Os materiais públicos do Proof-of-Control enfatizam a verificação em velocidade de máquina porque a revisão humana não consegue acompanhar a execução de agentes. Essa premissa é razoável, mas a automação também pode repetir uma regra falha em velocidade de máquina. Portanto, mudanças de controle devem ser governadas com o mesmo cuidado que mudanças de código.

A responsabilidade operacional é outra questão em aberto. Equipes de segurança podem definir políticas básicas, equipes de aplicação podem integrar gateways, equipes de identidade podem gerenciar delegação e equipes de conformidade podem reter evidências. Um padrão que pressupõe um único proprietário unificado terá dificuldades dentro de grandes organizações.

O projeto ainda pode ter sucesso sem se tornar o único padrão de segurança para agentes. Seu modelo de evidências pode informar orientações do NIST, APIs de fornecedores, questionários de seguros ou modelos de aquisição. Conceitos compartilhados podem influenciar o mercado mesmo quando as implementações variam.

O risco maior é a adoção cerimonial. Fornecedores podem alegar alinhamento enquanto cobrem apenas ações selecionadas ou usam a linguagem de verificação aberta sem oferecer testes independentes. Níveis claros de conformidade e requisitos verificáveis por máquina podem reduzir esse comportamento.

Três Sinais Decidirão se a Verificação Aberta se Tornará Infraestrutura

Os próximos três testes são coerência da especificação, implementação independente e adoção regulatória.

O primeiro sinal é se a Advanced AI Society resolve os conflitos entre as versões do rascunho e os prazos para comentários. Uma tag pública de lançamento deve conectar o texto normativo, os esquemas, os vetores de teste, a implementação de referência e o histórico de mudanças.

Essa etapa reforçaria o argumento central do projeto. A proveniência verificável deve começar pelo próprio padrão. Se os artefatos continuarem rotulados de forma inconsistente, as empresas hesitarão em criar controles ou contratos em torno deles.

O segundo sinal é a implementação independente. O código de referência da organização fundadora pode provar que seus autores desenvolveram o que descreveram. Uma equipe separada deve demonstrar que a especificação comunica detalhes suficientes para produzir evidências e resultados de verificação compatíveis.

Relatórios de implementação úteis devem documentar tanto falhas quanto sucessos. Eles devem identificar latência, carga de integração, frameworks de agentes sem suporte, restrições de privacidade e quaisquer rotas de contorno encontradas durante os testes. Alegações sobre uso em produção exigem evidências de ambientes fora do controle direto dos autores.

O terceiro sinal é como o NIST e o Congresso definem os requisitos de verificação de agentes. Se as diretrizes federais exigirem inventários contínuos, registros resistentes a adulteração, identidades atribuíveis e controles testáveis de forma independente, o Proof-of-Control atenderá a uma necessidade reconhecível de compras públicas.

O projeto ganharia ainda mais impulso se contratados federais ou compradores regulados solicitassem evidências portáveis em vez de capturas de tela de fornecedores. Esse requisito recompensaria a interoperabilidade e criaria espaço para vários provedores de verificação.

O cenário oposto enfraqueceria a justificativa para um ecossistema compartilhado. Agências poderiam aceitar logs convencionais e auditorias periódicas, ou o Congresso poderia deixar de avançar a legislação subjacente. As empresas poderiam então tratar a verificação aberta como um experimento de segurança opcional.

O debate mais amplo de Washington sobre IA continua sem definição. Líderes do Congresso discutiram salvaguardas, ao mesmo tempo que enfatizaram uma abordagem regulatória leve e a competição com a China. Essa tensão torna padrões técnicos direcionados mais plausíveis do que uma única lei abrangente sobre IA.

A distinção entre legislação e promulgação deve permanecer clara. A proposta da Câmara sobre segurança de agentes não é uma política federal estabelecida. A iniciativa existente do NIST está ativa, mas suas diretrizes finais e seus efeitos de mercado ainda estão em desenvolvimento.

A Advanced AI Society, portanto, tem uma janela estreita para influenciar o vocabulário emergente. Se conseguir demonstrar controles implementáveis antes que as regras de aquisição se consolidem, suas definições poderão moldar a forma como os compradores descrevem a garantia em tempo de execução.

Desenvolvedores devem observar se frameworks comuns de agentes adicionam suporte nativo para evidências portáveis. Compradores empresariais devem pedir aos fornecedores que identifiquem cada ação controlada e qualquer rota que contorne a aplicação dos controles. Equipes de segurança devem comparar a integridade das evidências com sua completude.

Profissionais do conhecimento também têm interesse nisso. Um agente que atua sobre o e-mail, documentos, calendário ou contas financeiras de uma pessoa pode gerar consequências antes que o usuário as revise. Os usuários precisam de um registro compreensível da autoridade que concederam e do que o agente fez com ela.

A iniciativa Proof-of-Control da Advanced AI Society oferece uma resposta séria a essa necessidade, mas ainda é um rascunho inicial. Seu valor virá da interoperabilidade testada, de um escopo preciso e de evidências que resistam ao escrutínio de partes que não sejam seus criadores.

O próximo passo correto não é presumir que o padrão resolve a segurança dos agentes. Compradores e desenvolvedores devem examinar o rascunho, testar o requisito de ausência de contorno e enviar falhas concretas de implementação durante a revisão pública. A verificação aberta só se torna infraestrutura quando participantes independentes conseguem reproduzir suas alegações e identificar seus limites.