David Mytton, CEO da Arcjet – Série de Entrevistas

David Mytton, fundador e CEO da Arcjet, lidera a startup de segurança focada em desenvolvedores que ajuda equipes a incorporar proteções robustas como detecção de bots, limitação de taxa, validação de e-mail, mitigação de ataques e redação de dados diretamente no código da aplicação, após assumir o cargo em junho de 2023. Ele também co-fundou Console, um newsletter e podcast de ferramentas de desenvolvimento bem seguido, atuou em papéis de consultoria, como Especialista em Residência na Seedcamp, e anteriormente dirigiu a engenharia de produtos na StackPath após sua empresa de monitoramento de nuvem ser adquirida, mantendo um forte interesse em computação sustentável e escrevendo ativamente sobre tópicos de tecnologia.

Arcjet é construída em torno de uma filosofia de “segurança como código” que permite que os desenvolvedores protejam as aplicações com integrações de SDK simples, colocando a lógica de segurança ao lado da lógica de negócios para decisões de baixa latência e conscientes do contexto, eliminando a necessidade de infraestrutura separada; a plataforma suporta proteções como bloqueio de bots, limites de taxa e filtragem de dados sensíveis e continua a evoluir com recursos como um modelo de segurança de IA local e suporte de estrutura expandido, refletindo sua missão de tornar a segurança em código o padrão para aplicativos modernos. (fly.io)

Você fundou a Server Density em um momento em que executar infraestrutura em escala era muito menos padronizado do que é hoje, e eventualmente cresceu e vendeu a empresa. Olhando para trás, quais foram as lições mais importantes que você aprendeu sobre construir para desenvolvedores e operar sistemas de produção, e como essa experiência moldou a forma como você pensa sobre software hoje?

A maioria das ferramentas de desenvolvedor vence a demonstração e perde a produção. Fazer com que um desenvolvedor instale algo novo é difícil, então “início rápido” tem que ser sem atrito – mas isso é apenas o básico. O modo real de falha é o que acontece após “funciona”: o produto se torna restrito, então equipes sérias rapidamente se frustram e o removem.

É por isso que a segurança de aplicativos em código da Arcjet é projetada para duas realidades: você precisa de uma solução imediata para spam de inscrição, fraude de conta, ataques de bots, abuso de API, etc., e você também precisa de uma saída para controles avançados – cotas por usuário, regras baseadas em risco e decisões conscientes do contexto – sem reescrever tudo.

O produto não é a interface do usuário. O produto é o comportamento em tempo de execução, os casos de bordo, os exemplos e a documentação de referência que os desenvolvedores podem confiar.

Saindo dessa experiência, o que o levou a iniciar a Arcjet, e por que você sentiu que o próximo grande avanço na segurança de aplicativos precisava acontecer dentro do código em si, e não na camada de rede ou infraestrutura?

A segurança de perímetro é otimizar a coisa errada. Desenvolvedores constroem e enviam em código, não em painéis – e agentes de codificação de IA não “clicarão” em uma consola de segurança para proteger um aplicativo.

Se sua proteção não pode ser expressa como código, revisada em uma solicitação de pull, testada em CI e implantada junto com a aplicação, não é “segurança para desenvolvedores”.

A Arcjet existe porque a segurança pertence à camada de aplicativo: controlada por versão, testável, observável e próxima da lógica de negócios onde a intenção realmente vive.

A Arcjet incorpora detecção de ameaças alimentada por IA diretamente nos manipuladores de solicitação de aplicativos. Do ponto de vista técnico, quais vantagens essa abordagem local e em código fornece em comparação com as ferramentas de segurança baseadas em perímetro tradicionais?

Dentro de um manipulador de solicitação, você tem identidade, estado de sessão, histórico de compra, idade da conta, flags de recurso, estado do banco de dados. Você pode tomar uma decisão como: “Isso parece estranho, mas é um cliente leal – aumente a verificação em vez de bloquear.” Um proxy de rede não pode fazer isso porque não tem ideia do que é um “cliente”.

O objetivo não é bloqueio máximo. O objetivo é minimizar falsos positivos com segurança consciente do contexto, porque o erro de segurança mais caro é bloquear um checkout legítimo ou travar um usuário real.

A IA mudou dramaticamente a economia do abuso, desde raspagem de bots e inscrições de spam até exploração automatizada de API. Quais tipos de ataques você está vendo com mais frequência em produção hoje, e como eles estão evoluindo à medida que os atacantes adotam sistemas de IA mais avançados?

Os ganhos de produtividade da IA também estão ajudando os atacantes! A grande mudança é o volume e a velocidade de iteração: mais stuffing de credenciais, mais spam de inscrição automatizado, mais raspagem de bots, mais sondagem de API e “armazenamento” mais rápido de vulnerabilidades frescas.

Também estamos vendo os atacantes executarem loops de feedback mais apertados: eles testam defesas, adaptam prompts e payloads, rotacionam infraestrutura e continuam até entrarem. Atualmente, é tudo sobre velocidade e não sobre sofisticação.

Ainda há muito poucas pessoas seguindo as melhores práticas, como usar um gerenciador de senhas, implantar autenticação de dois fatores com credenciais resistentes a phishing, como passkeys ou chaves de hardware, e manter as dependências atualizadas. Com o aumento do volume de ataques, isso se tornará cada vez mais importante.

Uma das maiores tensões na segurança é proteger aplicações sem retardar o desenvolvimento. Como as equipes que usam a Arcjet conseguiram integrar a segurança em seus fluxos de trabalho enquanto mantêm ciclos de lançamento rápidos?

A Arcjet funciona em qualquer ambiente, incluindo no ambiente de codificação em um laptop. Isso significa que os desenvolvedores podem testá-la sem sequer implantar em produção. Essa é uma vantagem significativa, pois você pode validar e demonstrar a integração sem precisar de permissões especiais e sem risco de afetar a produção. Isso resolve o problema clássico de equipes de segurança forçando os desenvolvedores a adotar ferramentas que prejudicam sua capacidade de fazer o trabalho.

A Arcjet ganhou tração inicial com produtos nativos de IA e plataformas de comércio eletrônico. O que torna esses ambientes especialmente vulneráveis a ataques automatizados modernos, e por que as defesas legadas tendem a falhar?

Essas duas categorias compartilham uma semelhança onde cada solicitação abusiva tem um custo direto.

Produtos de IA pagam por tokens e inferência – os atacantes transformam sua margem em seu playground via raspagem, automação e agricultura de camada gratuita. O comércio eletrônico paga por fraude, chargebacks, abuso de estoque e takeover de conta. E ambos são hipersensíveis a falsos positivos, pois bloquear usuários reais é perda de receita literal.

As defesas legadas protegem principalmente a largura de banda e a infraestrutura. Os atacantes modernos visam a lógica de negócios: fluxos de inscrição, fluxos de checkout, lógica de promoção, recuperação de conta e pontos de extremidade de API. É por isso que controles de perímetro genéricos e “resolva com um CAPTCHA” cada vez mais falham.

Construir software de segurança vem com trocas muito diferentes do que observabilidade ou monitoramento. O que mais o surpreendeu sobre o desenvolvimento de um produto de segurança em comparação com sua experiência anterior com ferramentas de infraestrutura?

Com observabilidade, os clientes confiam que você esteja disponível. Com segurança, os clientes confiam que você esteja seguro e que não se torne a nova exploração da cadeia de suprimentos deles.

Construir um produto de segurança significa executar uma empresa de segurança. Nós usamos estruturas como SOC 2, minimizamos nossas dependências de terceiros e tratamos laptops de desenvolvedores e acesso a ferramentas como ativos de produção. Isso significa muita monitoração e reações rápidas a problemas potenciais.

À medida que as aplicações cada vez mais dependem de agentes de IA agindo em nome dos usuários, como os desenvolvedores devem repensar ideias como identidade, intenção e confiança na camada de aplicativo?

À medida que os agentes de IA agem em nome dos usuários, a identidade deixa de ser um estado de login binário e se torna um problema de delegação: quem está agindo, em nome de quem, com quais permissões, por quanto tempo e com quais restrições.

Os desenvolvedores devem mudar para verificação contínua: tratar cada solicitação como necessitando de uma decisão de confiança fresca com base no contexto – histórico do usuário, sinais do dispositivo, comportamento da sessão e risco da ação. “Intenção” é inferida do comportamento ao longo do tempo, não reivindicada em cabeçalhos.

Isso significa construir momentos de aumento (verificação, limites de taxa, atrito) em torno de ações de alto risco, como redefinição de senha, checkout e criação de token – e fazer com que esses controles vivam em código, onde o aplicativo pode distinguir um cliente leal de um bot com um cookie roubado.

Olhando para a frente, como você vê o papel da segurança em código e consciente do contexto evoluindo nos próximos anos, à medida que o tráfego gerado por IA continua a crescer?

As ferramentas de perímetro não desaparecerão – mas elas serão o filtro grosso para coisas melhor lidadas na rede, como ataques de DDoS. As decisões precisas acontecerão dentro do aplicativo, usando contexto real.

Se a segurança incorporada se tornar o modelo padrão para aplicações modernas, o que essa mudança significa para como os desenvolvedores testam, implantam e raciocinam sobre a segurança em sistemas de produção?

Se a segurança incorporada se tornar padrão, as equipes testarão o abuso da mesma forma que testam a correção: testes de unidade de segurança, simulações de ataques reproduzíveis e verificações de CI para pontos de extremidade de risco.

A maior mudança é que os agentes de codificação de IA implementarão a segurança como código, não como configuração de painel. Os agentes só podem propor, revisar e validar proteções de forma confiável quando os controles vivem no repositório: políticas, regras, testes e instrumentação. Se a “camada de segurança” for uma interface da web, o agente não pode testar as alterações para enviar com segurança.

Essa é a razão real pela qual a “segurança em código” vence – ela se encaixa na forma como o software moderno (e o desenvolvimento assistido por IA moderno) é realmente construído.

Obrigado pela grande entrevista, leitores que desejam aprender mais devem visitar Arcjet.