Detecção de envenenamento de vetores: como detectar corrupção na recuperação antes que os agentes ajam

Um armazenamento de vetores envenenado não é apenas uma má qualidade de pesquisa. É uma corrupção persistente da memória. Uma vez que os trechos maliciosos dominam a recuperação, um agente pode começar a tomar decisões erradas muito depois de o evento de ingestão original ser esquecido.

Por que isso é importante

A maioria das equipes ainda fala sobre injeção de prompt como se cada ataque começasse e terminasse dentro de uma interação de modelo. Isso é muito estreito. Se embeddings maliciosos chegarem à camada de recuperação, o sistema poderá continuar servindo o contexto controlado pelo invasor continuamente. O raio de impacto é maior porque o estado comprometido se torna durável.

É por isso que o envenenamento por armazenamento de vetores pertence à mesma família de ameaças que o envenenamento de memória. A camada de recuperação é a memória, apenas em formato vetorial, em vez de Markdown ou JSON.

O detector mais rápido que ainda é honesto

A versão barata também é o ponto de partida certo. Observe dois sinais explicáveis antes de um lote ser promovido para a memória de produção: desvio do centroide e anomalias de centralidade (hubness).

Essas duas verificações detectam os casos problemáticos mais comuns sem fingir que você precisa de um retreinamento do modelo ou de uma plataforma de anomalia gigante no primeiro dia.

O que o desvio do centroide detecta

Se um namespace deve conter material restrito e confiável, um lote malicioso ou fora de contexto não deve mover muito o centro dessa nuvem de embeddings. Grandes mudanças geralmente significam uma de três coisas: trechos controlados pelo invasor foram inseridos em massa, lixo aleatório foi incorporado ou o namespace absorveu silenciosamente uma fonte que não pertence a ele.

Esse sinal fica mais forte quando você compara o tamanho do deslocamento com o raio normal do corpus confiável, em vez de usar um limite de distância bruto. A questão não é a elegância matemática. A questão é perguntar se esse lote parece pertencer à sala.

O que a centralidade anômala detecta

Hubness é a versão de recuperação de um sequestro de atenção. Se um pequeno número de trechos aparecer repentinamente como vizinhos de todo o resto, algo está errado. Às vezes é duplicação. Às vezes, é conteúdo malicioso parafraseado e projetado para parecer amplamente relevante. De qualquer forma, isso significa que o armazenamento está sendo inclinado para que o mesmo material controlado pelo invasor continue sendo recuperado.

Esse é exatamente o modo de falha com que os defensores devem se preocupar, porque o modelo pode parecer normal enquanto a camada de seleção de contexto já está comprometida.

A regra operacional que mais importa

Não deixe que lotes suspeitos definam sua própria linha de base. Mantenha linhas de base contínuas confiáveis por namespace, redefina-as nas alterações do modelo de incorporação e atualize-as somente a partir de lotes aprovados ou consistentemente de baixo risco. Caso contrário, o armazenamento aprende lentamente que envenenar é normal.

Como é um bom resultado

Um caminho de ingestão sensato mede sinais de anomalia antes da confirmação, mantém a trilha de auditoria apenas com acréscimos e fornece aos operadores um caminho de substituição limpo quando eles executam preenchimentos ou migrações de modelo intencionalmente. As verificações estáticas podem verificar a existência dessas defesas, mas a medição do tempo de execução deve acontecer próxima ao caminho de gravação dos vetores.

A parte importante é permanecer explicável. As equipes de segurança precisam saber por que um lote foi bloqueado, e não apenas porque uma caixa preta não gostou dele.

Principal conclusão do KENSAI

A verdadeira lição é chata no bom sentido. Se sua camada de recuperação puder ser alterada silenciosamente, então a memória do seu agente poderá ser alterada silenciosamente. Comece com cálculos simples, registros robustos e controles de quarentena. A modelagem sofisticada pode esperar.