Resumo Técnico: Quem é o Dono deste Agente? Rastreando Agentes de IA até seus Proprietários

1. Definição do Problema: Atribuição de Agentes

O artigo identifica e formaliza a atribuição de agentes como uma lacuna de segurança crítica e emergente. À medida que os agentes de IA são cada vez mais implantados para agir de forma autônoma — enviando mensagens, navegando em sites, chamando APIs e executando scripts —, atualmente não existe nenhum mecanismo técnico confiável para rastrear uma interação prejudicial de agente de volta à conta específica do operador que a implantou.

Essa lacuna de responsabilização existe em todo o espectro do comportamento do agente:

• Dano Involuntário: Operadores benignos podem implantar agentes mal configurados (por exemplo, condições de parada defeituosas, objetivos excessivamente amplos) que causam spam, sobrecarga de serviços ou ações não intencionais.
• Dano Intencional: Operadores maliciosos podem armar agentes para fraude, assédio, intrusão cibernética ou desinformação.

Em ambos os casos, as partes afetadas (vítimas) observam o comportamento prejudicial, e os fornecedores (provedores de LLM) mantêm os registros de sessão, mas nenhuma parte consegue vincular o comportamento externo observado à conta do fornecedor responsável. Os mecanismos de recurso existentes falham porque:

• Identificação baseada em IP é ineficaz, pois os agentes rotacionam endereços e usam proxies.
• Investigação em nível de plataforma identifica apenas contas superficiais descartáveis (por exemplo, personas falsas), e não a conta subjacente do fornecedor.
• Impressão digital comportamental detecta a presença de um agente, mas não consegue identificar qual das milhões de contas de fornecedores é responsável.
• Processo legal requer um fundamento (identificar a sessão e a conta específicas) antes de poder compelir a divulgação, o que atualmente é impossível sem uma ponte técnica.

Os autores postulam que este problema é particularmente viável no cenário de Modelos de Linguagem de Grande Escala (LLM) hospedados por fornecedores. Mesmo adversários sofisticados frequentemente dependem de modelos hospedados por fornecedores (por exemplo, OpenAI, Anthropic ou modelos de código aberto hospedados) para suas capacidades de raciocínio. Embora o operador controle o tempo de execução e os wrappers, as chamadas do modelo passam pelo fornecedor e são registradas contra uma conta.

2. Metodologia: O Protocolo Baseado em Canários

Os autores propõem um protocolo de atribuição baseado em canários que preenche a lacuna entre a observação da vítima e os registros do fornecedor. O protocolo envolve cinco principais: o Agente, o Operador, o Fornecedor, a Vítima e uma Autoridade (por exemplo, aplicação da lei ou uma entidade comercial).

Mecanismo Central

1. Injeção: Uma Autoridade autorizada ($\mathcal{D}$) injeta um canário no fluxo de conteúdo que o Agente ($\mathcal{A}$) provavelmente consumirá.
   • Interação Direta: A Autoridade interage diretamente com o agente (por exemplo, via chat) e injeta o canário.
   • Interação Passiva: A Autoridade coloca canários em locais que o agente deve visitar (por exemplo, páginas da web específicas, arquivos) e os instrumenta com ganchos.
2. Propagação: O agente processa o conteúdo. Se o agente encaminhar esse conteúdo para seu LLM hospedado pelo fornecedor, o canário aparece nos registros de sessão do fornecedor.
3. Busca: A Autoridade inicia uma solicitação de atribuição com o Fornecedor ($\mathcal{V}$), especificando o momento da injeção ($\tau$) e os valores do canário.
4. Recuperação: O Fornecedor busca em uma janela de tempo estreita de registros de sessão ativos pelos canários. Se encontrados, o fornecedor vincula a sessão à conta do Operador responsável ($\mathcal{O}$).

Construções de Canários

O artigo distingue entre dois cenários, exigindo diferentes tipos de canários:

• Cenário Não Adversarial: O operador não está tentando evadir a atribuição.

  • Canários Lexicais: Sequências de tokens simples de correspondência exata (por exemplo, strings aleatórias, UUIDs ou identificadores relevantes para a tarefa, como códigos de projeto). Estes são suficientes porque o agente passa o conteúdo recebido para o modelo de forma literal.

• Cenário Adversarial: O operador implanta um wrapper ($\mathcal{W}$) para filtrar, parafrasear ou reescrever o conteúdo recebido a fim de suprimir marcadores.

  • Canários com Utilidade: Para combater a evasão, os autores introduzem canários que são indistinguíveis do conteúdo legítimo da tarefa. Removê-los degradaria a capacidade do agente de realizar sua tarefa.
  • Canários Lexicais com Utilidade: Identificadores críticos para a tarefa (por exemplo, nomes de arquivos em uma listagem de diretório, IDs específicos em uma consulta de banco de dados) que o agente deve preservar para ter sucesso.
  • Canários Semânticos: Assinaturas definidas pelo significado e não pela forma superficial (por exemplo, estilos de fala, padrões estruturais, sinalização de urgência ou hábitos retóricos específicos). Estes sobrevivem melhor à parafraseação do que strings exatas.
  • Estratégia de Múltiplos Canários: A Autoridade amostra um subconjunto ($K$) de um grande universo de canários ($N$) e os injeta. A detecção requer um limiar ($m$) de correspondências. Isso cria uma assimetria favorável ao defensor: o adversário deve filtrar agressivamente o conteúdo para remover os canários, o que inevitavelmente degrada a utilidade do agente (por exemplo, fazendo-o falhar em um ataque cibernético ou golpe), enquanto o defensor pode levar a probabilidade de atribuição arbitrariamente próxima de 1.

3. Contribuições Principais

1. Formalização do Problema: Este é o primeiro trabalho a identificar e definir "atribuição de agentes" como um problema de segurança distinto e caracterizar a taxonomia completa de cenários (involuntário vs. intencional, vários alvos de ataque).
2. Protocolo Prático: Um protocolo de atribuição mediado por fornecedor que funciona sem pré-registro universal ou exposição contínua de identidade. Ele depende da dependência estrutural dos agentes em relação a modelos hospedados por fornecedores.
3. Construções Robustas de Canários:
   • Desenvolvimento de canários com utilidade (tanto lexicais quanto semânticos) que criam um trade-off para adversários: evadir a atribuição exige degradar o desempenho do agente.
   • Formalização da assimetria onde o defensor pode controlar a probabilidade de atribuição, enquanto o adversário paga um custo de utilidade pela evasão.
4. Avaliação Empírica: Testes abrangentes em três domínios:
   • Agentes de Comunicação: Interações em chat e fóruns.
   • Agentes Web: Ingestão e raspagem de documentos HTML.
   • Agentes Cibernéticos: Agentes autônomos que usam ferramentas em ambientes Capture-The-Flag (CTF).

4. Resultados Experimentais

A avaliação demonstra que o protocolo é confiável, robusto e escalável.

• Desempenho Não Adversarial:

  • Canários lexicais alcançam detecção quase perfeita (TPR $\approx$ 1,0) com falsos positivos próximos de zero (FPR) quando o conteúdo é passado inalterado.
  • Canários semânticos também alcançam altas taxas de detecção (AUC $\approx$ 0,98–0,99) em configurações de chat e fórum.

• Robustez Adversarial:

  • Ataques de Parafraseamento: Quando um wrapper parafraseia o conteúdo, os canários lexicais exatos falham (TPR cai para $\approx$ 0,20). No entanto, canários semânticos permanecem robustos. Em configurações de chat, o TPR permanece acima de 0,97 mesmo sob parafraseamento ao usar um limiar de múltiplos canários ($m$-de-$k$).
  • Agentes Web: Canários lexicais visíveis (incorporados no texto renderizado) sobrevivem ao pré-processamento e parafraseamento em taxas $>60\%$. Canários estruturais (ocultos no DOM) são mais frágeis. Canários semânticos de layout fornecem um canal secundário robusto.
  • Agentes Cibernéticos (CTF): Este é o teste mais forte. Um adversário consciente de canários tentando remover canários das saídas de ferramentas fez com que a taxa de resolução do agente colapsasse de 51% para 9%. Isso confirma o trade-off utilidade-evasão: suprimir evidências de atribuição destrói a missão do agente.
  • Precisão de Atribuição: Em configurações cibernéticas, a atribuição em nível de sessão alcançou TPR $\ge$ 98% com FPR próximo de zero, mesmo sob condições adversárias.

• Escalabilidade:

  • A busca do lado do fornecedor mostrou-se operacionalmente prática. Ao buscar apenas uma janela de tempo limitada de sessões concorrentes e usar correspondência em nível de token (aproveitando logs tokenizados existentes), os custos de busca escalam linearmente com o número de sessões ativas, e não com o tamanho total do log. A busca em nível de token foi encontrada ser $\approx$2x mais rápida que a correspondência em nível de caractere.

5. Significado e Alegações

O artigo alega ser o primeiro trabalho a definir a atribuição de agentes e apresentar uma solução prática. Seu significado reside em:

• Restaurar o Recurso: Fornece uma ponte técnica permitindo que vítimas, plataformas e autoridades identifiquem operadores responsáveis, permitindo intervenção em casos benignos e responsabilização legal em casos maliciosos.
• Viabilidade para Fornecedores: O protocolo aproveita a infraestrutura existente dos fornecedores (logs, serviço de API) e não requer alterações no código de tempo de execução do agente ou na infraestrutura do operador.
• Assimetria na Defesa: Ao vincular canários à utilidade da tarefa, o protocolo força os adversários a um dilema onde evadir a atribuição compromete seus próprios objetivos.

Os autores permanecem modestos sobre as limitações, observando que a avaliação usa famílias de modelos e configurações de wrapper específicas, e que a injeção indireta (previsão de trajetórias de agentes) requer mais testes no mundo real. No entanto, eles afirmam que o método proposto oferece um caminho implantável em direção à responsabilização para agentes de IA cada vez mais autônomos.