Damos à inteligência artificial uma tarefa simples: tentar quebrar a Didit

Na Didit, o red teaming de inteligência artificial significa usar agentes de inteligência artificial para desafiar os nossos fluxos de verificação de identidade num ambiente de staging. Estudamos as tentativas e os seus resultados para encontrar pontos fracos, ajudar a detetar bots a realizar a verificação e compreender onde os utilizadores reais têm dificuldades.

Reproduzir animação de zoomPausar animação

Damos aos agentes acesso ao nosso código fonte e pedimos que encontrem uma forma de contornar as verificações em staging. Eles tentam documentos forjados, feeds de câmara injetados e jornadas automatizadas através de fluxos de trabalho reais. Observamos o que acontece, investigamos os resultados e usamos o que aprendemos para melhorar o sistema.

Também usamos este trabalho para ajudar a detetar bots a realizar a verificação e a compreender o comportamento do utilizador. Ver como a automação se move através de um fluxo ajuda a formular melhores perguntas sobre fraude e sobre a experiência da pessoa do outro lado do ecrã.

Principais conclusões

Testar toda a jornada. Documentos forjados, feeds de câmara artificiais e ações automatizadas desafiam diferentes partes de um fluxo de verificação.

Investigar o que aconteceu. Um agente que afirma ter contornado o sistema precisa de ser verificado com base em provas reproduzíveis.

Aprender com o comportamento. O tempo e as novas tentativas podem adicionar contexto sobre a automação, ao mesmo tempo que revelam onde os utilizadores legítimos precisam de ajuda.

Tornar as descobertas úteis. O trabalho continua através da investigação, correções e verificações do efeito nas pessoas reais.

A responsabilidade por trás do ecrã

A TechCrunch noticiou uma suspeita de violação num fornecedor de verificação.

Para nós, a responsabilidade começa com o que as pessoas confiam a uma empresa de verificação. Uma digitalização de passaporte contém o seu nome, fotografia e outras informações de identificação. Uma selfie é um registo do seu rosto. Pode redefinir uma palavra passe depois de esta ser divulgada. Não pode redefinir o seu rosto.

Essa responsabilidade vai além de decidir se um documento parece genuíno ou se uma pessoa está presente. Inclui os serviços que processam o pedido, as permissões relativas aos dados e as pessoas que operam o sistema. Uma verificação forte no início de uma jornada não pode compensar uma fraqueza noutro local.

É por isso que queremos desafiar as nossas suposições enquanto ainda temos a oportunidade de agir sobre o que encontramos.

O que realmente pedimos aos agentes para fazer

Um teste normal começa com um resultado esperado. Um teste adversarial começa com um objetivo que o sistema deve impedir.

Para a verificação de identidade, isso pode significar aceitar um documento forjado ou tentar fazer com que um rosto gravado passe por uma pessoa presente. Pode significar investigar como o sistema responde quando um cliente automatizado se move através de um fluxo de forma inesperada.

O agente pode inspecionar o código, interagir com o fluxo de trabalho e ajustar a sua próxima tentativa com base na resposta. Isso oferece uma forma útil de explorar suposições que um conjunto fixo de casos de teste pode não detetar.

Na filmagem que acompanha, os agentes carregam documentos de amostra, fornecem feeds de câmara artificiais e realizam os passos de verificação em staging. A câmara recua de um ecrã até mostrar uma parede dessas gravações para que possa ver a gama de atividades.

Para informações sobre meios manipulados, consulte o nosso guia para ataques e deteção de deepfakes.

A parede é uma visualização do trabalho. Cada resultado ainda precisa de ser verificado com base nas provas subjacentes. Um agente dizer que encontrou um desvio não o torna um.

Por dentro de um teste em staging

Um agente age, observa e adapta a abordagem.

1. Tentativa2. Resposta3. Ajuste

Agente de IA

Testes da Didit

Documento de teste falso

→

Passo do documento

Vídeo artificial de câmara

→

Passo da câmara

Ações automatizadas

→

Percurso de verificação

←A resposta do fluxo regressa ao agente.

O agente pode analisar o código fonte e escolher uma entrada para testar em staging. Estes caminhos mostram pontos de acesso, não controlos contornados.

A resposta informa o agente sobre o que aconteceu. A alegação de que um controlo foi contornado continua a exigir verificação independente.

O agente analisa a resposta e ajusta a próxima tentativa. Esse retorno permite explorar para além de um caso de teste fixo.

Uma possível fraqueza inicia uma investigação.

Reproduzir→Corrigir se necessário→Voltar a testar

Verifique também o efeito nos utilizadores legítimos.

A nossa abordagem inclui modelos de ponta e modelos abertos com menos restrições nas tarefas que tentarão. Queremos uma cobertura útil do comportamento adversarial, incluindo tentativas que um modelo poderia, de outra forma, recusar explorar. A vontade do modelo de tentar um ataque não diz nada sobre se esse ataque foi bem sucedido. Essa é uma questão de engenharia que temos de verificar.

Como o trabalho nos ajuda a compreender os bots

Um documento e uma selfie contam parte da história. A forma como uma verificação acontece pode adicionar contexto.

Usamos estes exercícios para ajudar a detetar bots a realizar a verificação e para aprender mais sobre o comportamento de botting. Executar a automação nós próprios produz exemplos que podemos estudar, comparar e desafiar à medida que a automação muda.

Podemos examinar onde uma tentativa automatizada faz uma pausa, o que repete após um erro e se segue a mesma sequência sempre. Também podemos considerar se esse comportamento se encaixa no dispositivo e no contexto da sessão. Estas comparações ajudam a tornar uma investigação mais específica.

Estas são questões a investigar, não regras que estabelecem fraude por si só. Um utilizador rápido pode simplesmente saber o que fazer. Uma pessoa que tenta várias vezes pode ter pouca luz ou uma ligação pouco fiável. Alguém que usa tecnologia assistiva pode interagir de forma diferente do padrão que um designer esperava.

A deteção útil de bots tem de ter em conta essa variação. O tempo, a repetição e o contexto do dispositivo precisam de ser considerados juntamente com as provas de verificação. Tratar uma ação incomum como prova de abuso pioraria a experiência para pessoas reais.

O mesmo trabalho mostra onde as pessoas têm dificuldades

Estudar o comportamento também nos ajuda a fazer melhores perguntas sobre o produto. Uma nova tentativa pode indicar um ataque, mas também pode indicar uma instrução difícil de entender. Um passo de câmara abandonado pode significar que o utilizador não conseguiu conceder permissão. Uma captura falhada pode refletir brilho, um documento danificado ou um dispositivo que precisa de uma abordagem diferente.

Os testes automatizados permitem explorar como o fluxo responde a estas situações. Compreender o que as pessoas reais experimentam requer também observar o comportamento do utilizador. Um não pode substituir o outro.

Juntos, eles ajudam a separar um controlo que está a fazer um trabalho útil da fricção que merece investigação. O objetivo é dificultar o abuso, ao mesmo tempo que ajudamos os utilizadores legítimos a concluir a verificação com instruções claras e um caminho sensato para recuperar quando algo corre mal.

Uma descoberta tem de mudar algo

O valor de um exercício é o que acontece após a tentativa.

Uma fraqueza suspeita precisa de um caso reproduzível. Um engenheiro precisa de compreender qual o controlo envolvido e se as provas apoiam a afirmação. Se for necessária uma correção, a tentativa original precisa de ser executada novamente contra a alteração.

Também precisamos de verificar o que essa alteração faz aos utilizadores legítimos. Um controlo que rejeita mais ataques ao rejeitar mais pessoas criou outro problema a resolver.

Essa é a disciplina que queremos que este trabalho apoie: tentar, observar, investigar, melhorar e testar novamente. A animação mostra as tentativas. O trabalho por trás delas é o que importa.

Também podemos ser hackeados

Qualquer pessoa pode ser hackeada, incluindo nós. Os testes contínuos não eliminam essa possibilidade. Oferecem mais oportunidades para descobrir uma fraqueza e fazer algo a respeito.

Construímos infraestruturas de verificação de identidade e prevenção de fraude porque acreditamos que as pessoas devem ser capazes de provar quem são online com confiança. A nossa visão de humanizar a internet na era da inteligência artificial depende de conquistar essa confiança na prática.

Isso significa compreender como os atacantes se comportam, prestar atenção onde os utilizadores reais têm dificuldades e ser honesto sobre o que as nossas provas nos podem dizer.

Um apelo aos líderes técnicos da nossa indústria

O risco cibernético é sistémico na verificação de identidade. Dependemos de serviços conectados, integrações e pessoas, e a confiança em jogo vai além de qualquer fornecedor. Uma falha numa empresa pode prejudicar indivíduos e enfraquecer a confiança em toda a indústria.

Se é um diretor de tecnologia, um líder de engenharia ou um líder de segurança nesta indústria, incentivamos que leve essa responsabilidade muito a sério. Defina responsáveis claros para o trabalho de segurança e atribua tempo e orçamento. Desafie o fluxo de verificação, os sistemas que lidam com dados de identidade, o acesso que as pessoas têm e a resposta que a sua equipa daria a um incidente. Reavalie essas suposições à medida que a tecnologia e os ataques mudam.

A reportagem da semana passada deve ser um alerta para nos prepararmos. Devemos usar essa reportagem para fortalecer as nossas próprias defesas, partilhar lições defensivas úteis de forma responsável e agir sobre fraquezas verificadas. Esperar até que a nossa própria empresa seja afetada torna esse trabalho demasiado tardio.

Essa responsabilidade também é nossa. Também podemos ser hackeados, e precisamos de continuar a merecer a confiança que as pessoas depositam em nós.

A nossa indústria precisa de avançar. As pessoas confiam a sua identidade a nós. Temos o dever de fazer esse trabalho.

Perguntas frequentes

O que envolve o red teaming de inteligência artificial na Didit?

Damos aos agentes de inteligência artificial acesso ao nosso código fonte e a um ambiente de staging, e depois pedimos que desafiem as verificações. Os exemplos neste artigo incluem documentos de amostra forjados, feeds de câmara artificiais e jornadas automatizadas. Os engenheiros ainda precisam de verificar o resultado de cada fraqueza suspeita.

Como é que isto ajuda a detetar bots a realizar a verificação?

Executar a automação nós próprios cria exemplos de comportamento de bot para estudar. Ajuda a examinar sequências, novas tentativas e contexto juntamente com as provas de verificação. Um único sinal comportamental não estabelece que um utilizador é um bot ou que ocorreu fraude.

A animação prova que a Didit impede todos os ataques?

Não. A animação é uma composição de gravações de staging com ecrãs repetidos. Mostra o processo de teste, não uma referência de deteção ou uma promessa de que todos os ataques falharão.

Este trabalho pode melhorar a experiência para utilizadores reais?

Sim, pode ajudar a investigar onde o fluxo de verificação se torna difícil. Ainda precisamos de considerar o comportamento real do utilizador juntamente com os testes automatizados, para que possamos distinguir controlos de segurança úteis de problemas como instruções pouco claras ou acesso difícil à câmara.

Se está a construir uma jornada de verificação, explore Verificação de Utilizador da Didit e leia a documentação de vivacidade. Também pode ver os preços ou começar gratuitamente.