Da inteligência à autoridade

A inteligência artificial está indo além de responder a perguntas e gerar conteúdo. Cada vez mais, os sistemas de IA conseguem interpretar instruções, formular planos, selecionar ferramentas e executar tarefas sem orientação humana contínua.

Essa distinção é importante.

Um sistema de IA que recomenda uma ação é diferente de outro autorizado a executá-la. A diferença não está necessariamente na inteligência ou na sofisticação. Está na autoridade.

Os sistemas autônomos não se limitam a modelos de linguagem grandes de ponta. Incluem sistemas especializados de aprendizado de máquina, robótica, veículos autônomos, agentes de software e combinações de tecnologias que tomam decisões ou realizam ações de forma independente, dentro de condições operacionais definidas.

Seus benefícios potenciais são substanciais. Eles podem apoiar a descoberta científica, as operações industriais, a área da saúde, o desenvolvimento de software e a cibersegurança. Também podem gerar resultados não intencionais, expor informações confidenciais ou iniciar ações que vão além do que seus operadores pretendiam.

Em Desafios de segurança no projeto de sistemas autônomos, Mohammad Hamad e Sebastian Steinhorst examinam desafios de segurança relacionados à resposta autônoma a incidentes, à avaliação de riscos, ao controle de acesso, à confiabilidade dos dados e às interações entre sistemas autônomos. A pesquisa deles, que em grande parte trata de sistemas ciberfísicos, mostra que os desafios de proteger ações independentes de máquinas vão além dos agentes de LLM atuais.

As consequências mais amplas da autonomia merecem ser examinadas com seriedade, incluindo o potencial de danos físicos. No entanto, as evidências devem ser interpretadas com cautela. Incidentes envolvendo veículos automatizados, por exemplo, não podem ser automaticamente atribuídos aos mesmos mecanismos que afetam agentes autônomos de cibersegurança. Importam o grau de autonomia, as condições operacionais, o envolvimento humano e as evidências causais.

Da mesma forma, evidências de que a IA autônoma pode causar danos não demonstram que a governança esteja necessariamente ficando para trás. Tampouco devemos presumir que os sistemas autônomos sejam inerentemente difíceis de proteger.

A questão central não é se a IA consegue realizar trabalhos complexos, mas se as estruturas arquitetônicas, de segurança e organizacionais que regem os sistemas autônomos conseguem estabelecer limites apropriados para a autoridade delegada e fornecer evidências verificáveis de que esses limites estão sendo respeitados.

A cibersegurança oferece uma perspectiva particularmente útil sobre essa questão, pois os profissionais de segurança vêm há décadas questionando pressupostos sobre confiança, permissões, acesso e comportamento dos sistemas.

O jogo de gato e rato na velocidade das máquinas

Há muito tempo, a cibersegurança é descrita como um jogo de gato e rato.

Os invasores descobrem vulnerabilidades, os defensores implementam salvaguardas e ambos se adaptam. O ciclo continua à medida que as tecnologias, as táticas e os ambientes operacionais mudam.

A IA autônoma não muda necessariamente as regras fundamentais desse jogo. Ela pode mudar quem — ou o que — está jogando, a velocidade de atuação e a quantidade de trabalho que pode avançar sem intervenção humana contínua.

Um sistema autônomo de segurança ofensiva pode identificar serviços expostos, investigar vulnerabilidades, desenvolver possíveis caminhos de ataque e testar se eles são exploráveis. Um sistema defensivo pode usar recursos semelhantes para investigar ameaças, identificar vulnerabilidades e validar medidas corretivas.

Esse potencial de uso dual é fundamental para compreender as implicações de segurança da IA autônoma.

O Project Glasswing, da Anthropic, é um exemplo de descoberta de vulnerabilidades assistida por IA. Em sua atualização de pesquisa de maio de 2026, a Anthropic relatou resultados expressivos na descoberta de vulnerabilidades e, ao mesmo tempo, ressaltou os desafios operacionais de verificação, divulgação e aplicação de correções.

Essa distinção é importante. Descobrir uma vulnerabilidade não é o mesmo que confirmar sua explorabilidade, corrigi-la ou demonstrar que o sistema afetado está seguro.

Mais descobertas podem ampliar a visibilidade e, ao mesmo tempo, aumentar as demandas sobre as pessoas e os processos responsáveis por solucioná-las.

O resultado de segurança depende do que acontece em seguida.

Se invasores e defensores conseguirem automatizar parte de seu trabalho, a questão relevante não será simplesmente qual lado tem o modelo mais capaz. Será se os defensores conseguem transformar a descoberta em correções eficazes e verificar os resultados de forma independente.

Os testes de invasão tradicionais não se tornam obsoletos porque a IA consegue executar tarefas ofensivas. Seu escopo precisa se ampliar para incluir sistemas que interpretam instruções, acionam ferramentas, combinam permissões e perseguem objetivos ao longo de várias etapas.

O objetivo continua conhecido: encontrar vulnerabilidades, determinar sua relevância, corrigi-las e comprovar que as salvaguardas funcionam.

Junções arquitetônicas: onde os limites de segurança se encontram

Um dos riscos mais sutis dos sistemas autônomos surge quando componentes autorizados individualmente interagem de maneiras que produzem resultados não intencionais.

Chamo esses pontos de interação de interfaces arquiteturais.

Considere um exemplo convencional. Uma organização restringe o acesso a um arquivo usando permissões NTFS. Um serviço separado de compartilhamento na nuvem permite que um usuário autorizado compartilhe essas informações externamente.

Cada sistema pode funcionar de acordo com suas próprias regras. Ainda assim, a interação entre eles pode levar ao compartilhamento de informações de uma forma que viola os limites de segurança definidos pela organização.

Este é um exemplo de políticas potencialmente conflitantes, não uma afirmação de que algum produto de compartilhamento de arquivos seja vulnerável.

O problema pode não ser uma falha em cada controle individualmente. Pode ser uma falha na aplicação da política de segurança pretendida ao longo de todo o fluxo de trabalho.

A IA autônoma pode se deparar com condições semelhantes ao conectar modelos, aplicativos, identidades, ferramentas, repositórios e serviços externos.

Um agente pode ter permissão para ler um documento, criar um repositório e enviar arquivos. Isso não significa necessariamente que tenha autoridade para combinar essas operações de uma maneira que exponha informações confidenciais.

A pesquisa oferece uma razão prática para examinar essas interações.

No AgentDojo, pesquisadores avaliaram ataques de injeção de prompt contra agentes de IA que usam ferramentas, abrangendo 97 tarefas realistas e 629 casos de teste de segurança. Os resultados demonstraram que instruções maliciosas introduzidas por meio de resultados não confiáveis de ferramentas podiam comprometer algumas propriedades de segurança, embora nem os ataques nem os agentes tivessem sucesso de forma uniforme.

A pesquisa não determina com que frequência esses ataques são bem-sucedidos em ambientes de produção. Ela mostra por que avaliar apenas as respostas do modelo é insuficiente para compreender o comportamento de um sistema conectado a ferramentas.

Um risco relacionado às vezes é descrito como lavagem de permissões: uma ação parece legítima porque passa por uma ferramenta ou um intermediário autorizado, embora o comportamento combinado viole os limites de autoridade pretendidos.

À medida que vários agentes colaboram, essas relações exigem regras explícitas que definam a participação, a troca de informações e as ações permitidas.

Também é preciso atribuir responsabilidades em toda a arquitetura.

Os provedores de modelos, os operadores de plataformas, os desenvolvedores de agentes e as organizações que os implantam podem controlar diferentes partes do sistema. Um modelo útil de responsabilidade compartilhada identifica quem controla cada limite, quem pode autorizar exceções, quem monitora a execução e quem responde quando algo dá errado.

A autonomia não elimina a responsabilidade. Ela torna ainda mais importante saber onde essa responsabilidade está.

Rigor ofensivo: testando o que acreditamos saber

Isso nos leva a um conceito que chamo de Rigor Ofensivo.

Rigor Ofensivo é uma abordagem disciplinada de testes adversariais, investigação crítica e validação baseada em evidências que põe em xeque as premissas de segurança. Ela avalia o comportamento dos sistemas em condições realistas, em vez de se apoiar exclusivamente em projetos arquiteturais, controles documentados ou proteções presumidas.

As práticas subjacentes já estão consolidadas. Há muito tempo, testes de invasão, modelagem de ameaças, exercícios de equipe vermelha e validação de segurança desafiam as premissas defensivas.

O Rigor Ofensivo articula essas práticas em torno de uma pergunta central:

Que evidências demonstram que o limite de segurança pretendido se mantém?

Uma organização pode ter políticas que restringem informações confidenciais, um modelo configurado para recusar solicitações proibidas e um agente operando com permissões limitadas.

Essas são salvaguardas relevantes. No entanto, sua existência, por si só, não comprova que o sistema como um todo se comporte de forma segura em condições adversariais.

Um modelo pode recusar uma instrução maliciosa, enquanto uma ferramenta autorizada ainda permite uma ação não intencional. Uma política pode parecer correta, mas as interações entre sistemas podem criar um caminho inesperado para contorná-la.

Às vezes, chamo isso de «ilusão das barreiras de proteção»: confundir a presença de barreiras com evidências de que o sistema não pode ultrapassar o limite que elas deveriam impor.

As barreiras de proteção são úteis. Ainda assim, é preciso demonstrar sua eficácia.

Considere um agente autônomo autorizado a investigar uma suspeita de comprometimento. Ele pode recuperar registros, examinar a atividade dos usuários e recomendar medidas de contenção.

Durante um teste de segurança autorizado, um testador adversarial introduz instruções enganosas nas informações que o agente deve consumir.

O teste não deve se limitar a determinar se o agente seguiu essas instruções.

Ele deve examinar se o agente tentou realizar uma ação não autorizada, se controles independentes impediram sua execução, se a tentativa foi registrada e se o sistema se recuperou adequadamente.

O Rigor Ofensivo conecta cinco atividades:

1. Estabelecer a premissa: identificar a propriedade de segurança que se espera que a arquitetura garanta.
2. Pôr a premissa à prova: testar caminhos de ataque realistas, entradas manipuladas e combinações de recursos legítimos.
3. Coletar evidências: determinar o que o sistema tentou fazer, o que foi executado e quais controles entraram em operação.
4. Corrigir a vulnerabilidade: corrigir o modelo, o fluxo de trabalho, as permissões, a arquitetura ou o processo operacional responsável pela falha.
5. Verificar a correção: testar novamente o caminho de ataque pertinente e confirmar que a propriedade de segurança pretendida está sendo garantida.

Essa é a diferença entre testar a resposta de um modelo e testar a segurança do sistema completo.

Também é necessário examinar o que acontece depois que um invasor consegue se estabelecer inicialmente. Ele pode tentar coletar credenciais, elevar privilégios, manter a persistência ou movimentar-se lateralmente, abusando de recursos já disponíveis no ambiente.

O fato de uma ferramenta ser legítima não torna legítimo todo uso que se faça dela.

O objetivo do Rigor Ofensivo não é presumir que sistemas autônomos sejam inseguros. É determinar, por meio de testes, onde os limites de segurança desses sistemas se mantêm.

Autonomia condicional: separar inteligência de autoridade

Uma resposta arquitetural é distinguir o que um sistema de IA pode fazer daquilo que está autorizado a fazer.

Chamo essa abordagem de autonomia condicional.

A autonomia condicional reconhece que o grau adequado de independência depende da tarefa, do ambiente operacional, das possíveis consequências, da incerteza e das evidências disponíveis para justificar uma ação.

Um agente que resume informações públicas não precisa necessariamente do mesmo nível de supervisão que outro autorizado a desativar contas, modificar regras de firewall ou alterar a infraestrutura de produção.

Este último pode exigir regras de engajamento explícitas, permissões aplicadas de forma independente, autorização mais rigorosa e aprovação humana para ações de impacto significativo.

Esses limites não devem ser ampliados simplesmente porque um agente decide que um acesso mais amplo ajudaria a atingir seu objetivo.

Um agente pode reavaliar como realizar uma tarefa autorizada sem obter autoridade adicional.

O OWASP Top 10 para aplicações de LLM aborda essa questão na categoria LLM06:2025 Agência excessiva. A OWASP identifica funcionalidades, permissões e autonomia excessivas como fontes de risco e recomenda limitar os recursos e aplicar a autorização de forma independente.

A autonomia condicional aplica esses princípios de acordo com o risco operacional.

O acesso a informações deve se limitar ao que a tarefa exige. As permissões das ferramentas devem se restringir às operações aprovadas. Limites de ações, limites de frequência, exigências de aprovação e condições de interrupção podem restringir a execução.

Essas salvaguardas são particularmente importantes em testes ofensivos autônomos.

Um agente de testes pode descobrir legitimamente credenciais ou informações confidenciais ao perseguir um objetivo autorizado. Mas descobrir uma credencial não significa que o modelo precise receber seu valor em texto simples.

Uma estrutura de segurança pode manter as credenciais confidenciais separadas do modelo e intermediar seu uso por meio de autorização aplicada de forma independente. Por exemplo, um intermediário de credenciais poderia fornecer um segredo diretamente a um serviço aprovado, sem expô-lo desnecessariamente ao modelo.

Isso se aplica aos princípios estabelecidos do menor privilégio e da segregação de funções.

Isso também levanta uma questão interessante sobre a arquitetura Traga seu próprio modelo (BYOM) ou Traga seu próprio LLM (BYO-LLM).

Se o modelo subjacente for substituído amanhã, quais garantias de segurança permanecerão intactas?

A autorização de tarefas, o isolamento de credenciais, as restrições de escopo, o registro de atividades e a aplicação de políticas podem estar na estrutura ao redor do modelo, em vez de depender inteiramente do comportamento dele.

Isso não torna a estrutura automaticamente segura nem os modelos intercambiáveis. Modelos diferentes podem interpretar instruções de maneiras distintas, acionar ferramentas de maneiras distintas e apresentar modos de falha diferentes.

Uma avaliação significativa precisa testar tanto os controles que devem permanecer invariáveis quanto os comportamentos que mudam quando o modelo é substituído.

Talvez algumas das propriedades de segurança mais duradouras sejam aquelas que continuam podendo ser aplicadas de forma independente, mesmo com a evolução do componente de inteligência.

Quando a IA age sobre a IA: o desafio da verificação

Considere um fluxo de trabalho hipotético de operações de segurança:

Investigue este incidente, colete as evidências, identifique as identidades afetadas, proponha medidas de contenção, execute as ações aprovadas e verifique o resultado.

Um agente de investigação analisa a telemetria. Outro recomenda medidas de contenção. Um agente de execução autorizado realiza as alterações. Um agente de verificação avalia o resultado.

Isso ilustra uma resposta autônoma a incidentes em ciclo fechado, não uma falha documentada em todo o setor.

Suponha que o primeiro agente identifique incorretamente uma identidade como comprometida. Um segundo agente aceita essa conclusão e desativa a conta. Um terceiro confirma que a conta foi desativada e informa que a operação foi concluída com sucesso.

A operação selecionada foi concluída.

Mas a avaliação inicial estava correta? A ação foi autorizada? A contenção tratou da ameaça real? Ela causou transtornos desnecessários?

A verificação não pode consistir apenas em confirmar que um agente concluiu a ação que selecionou.

Tampouco atribuir a verificação a outro agente de IA torna automaticamente o resultado independente.

Agentes diferentes podem se basear na mesma telemetria imprecisa, em informações comprometidas ou em suposições falhas. A concordância entre eles não comprova, de forma independente, os fatos subjacentes.

Quanto mais graves forem as consequências de uma ação autônoma, maior será a necessidade de uma verificação independente do sistema que tomou a decisão.

Essa independência pode envolver evidências obtidas de fontes distintas, verificações determinísticas de políticas, ambientes de execução restritos, análise humana ou uma combinação de salvaguardas.

Os controles adequados devem ser proporcionais às consequências de um erro.

Ações de baixo impacto e reversíveis podem ser adequadas à verificação automatizada. Ações de alto impacto ou difíceis de reverter podem exigir autorização mais rigorosa, confirmação independente e aprovação humana explícita.

Quatro perguntas ajudam a distinguir as propriedades de segurança relevantes:

• O sistema interpretou corretamente a tarefa pretendida?
• A ação estava dentro dos limites da autoridade delegada?
• A execução permaneceu dentro dos limites permitidos?
• O resultado alcançado cumpriu o objetivo de segurança pretendido?

Essas perguntas estão relacionadas, mas não são intercambiáveis.

Um agente pode executar uma ação autorizada que produza um resultado não pretendido. Também pode alcançar um resultado aparentemente benéfico por meio de uma ação não autorizada.

Nenhuma dessas situações deve ser automaticamente considerada um sucesso em termos de segurança.

À medida que os sistemas autônomos se tornam mais capazes, o desafio não é apenas permitir que concluam fluxos de trabalho complexos. É obter evidências suficientes de que suas ações continuam autorizadas, apropriadas e corretas.

Isso inclui saber quando parar, escalar a situação, reverter uma ação ou aceitar um risco limitado e explicitamente compreendido.

A confiança deve se basear em evidências

As implicações de segurança da IA autônoma não são exclusivamente negativas.

Os sistemas autônomos podem ajudar as equipes de defesa a descobrir vulnerabilidades, investigar ameaças e realizar trabalhos de validação que, de outro modo, exigiriam um esforço humano considerável.

Modelos melhores, controles externos mais robustos e práticas operacionais mais maduras podem reduzir alguns dos riscos associados à autoridade delegada.

Portanto, seria prematuro concluir que a IA autônoma é inerentemente insegura ou que a governança não consegue acompanhar seu desenvolvimento.

Há também um contra-argumento importante à ideia de que a IA autônoma exige princípios de segurança fundamentalmente novos.

Muitos dos problemas subjacentes — privilégios excessivos, entradas não confiáveis, autorização fraca, aplicação inconsistente de políticas e verificação insuficiente — vêm sendo estudados há décadas.

Os controles estabelecidos podem já oferecer soluções viáveis quando implementados e testados corretamente.

A autonomia pode alterar a velocidade, a escala e a complexidade de sua aplicação. Isso não os invalida automaticamente.

As evidências apontam para uma pergunta mais útil: em que condições se pode confiar que os sistemas autônomos exercerão a autoridade delegada, e como demonstramos que essas condições são atendidas?

A resposta não virá apenas da capacidade dos modelos.

Ela exige limites arquitetônicos, responsabilidades claramente atribuídas, autorização aplicada de forma independente, supervisão adequada e evidências de que as salvaguardas funcionam em condições realistas.

Também exige uma visão de segurança e risco consistente, mas em evolução.

Nossos princípios fundamentais de segurança não precisam mudar sempre que surge um novo modelo. Mas nossas suposições sobre como esses princípios se aplicam devem ser continuamente questionadas à medida que evoluem as capacidades, os ambientes operacionais e a autoridade delegada.

Esse é o propósito do Rigor Ofensivo.

Não para provar que os sistemas de IA vão falhar, mas para descobrir onde podem falhar, estabelecer as consequências e validar os controles destinados a prevenir ou conter essas falhas.

Talvez a vantagem mais duradoura não esteja simplesmente em escolher um modelo mais capaz, mas em construir uma arquitetura que permita trocar de modelo sem comprometer os limites de confiança, autoridade e verificação.

O jogo de gato e rato continua. Cada vez mais, ambos os lados podem contar com participantes autônomos.

O que importa é garantir que nossa capacidade de encontrar vulnerabilidades, corrigi-las e comprovar os resultados não se perca na corrida para automatizar todo o resto.

A confiança deve se basear em evidências.

Nota do autor: As opiniões e interpretações expressas neste artigo são minhas e não refletem necessariamente as posições oficiais, as políticas ou os recursos dos produtos do meu empregador.