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 boletim e podcast de ferramentas de desenvolvimento bem seguidos, atuou em funções 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 a estruturas expandidas, 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 “isso funciona”: o produto se torna limitado, então equipes sérias rapidamente ficam frustradas 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 cadastro, 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 deslocamento 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 dashboards – e agentes de codificação de IA não “clicarão em torno” de um console 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 o aplicativo, não é “segurança de primeiro nível 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ções 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 tradicionais baseadas em perímetro?

Dentro de um manipulador de solicitação, você tem identidade, estado de sessão, histórico de compra, idade da conta, flags de recurso e verdade 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 é 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.

IA dramaticamente mudou a economia do abuso, desde raspagem de bots e spam de cadastro até exploração automática 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 preenchimento de credenciais, mais spam de cadastro automatizado, mais raspagem de bots, mais sondagem de API e “armazenamento” mais rápido de vulnerabilidades frescas.

Também estamos vendo atacantes executarem loops de feedback mais apertados: eles testam defesas, adaptam prompts e payloads, rotacionam infraestrutura e continuam até entrarem. Atualmente, é tudo sobre velocidade em vez de 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 chaves de passe 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 aplicativos sem retardar o desenvolvimento. Como as equipes que usam a Arcjet conseguiram integrar a segurança em seus fluxos de trabalho, mantendo 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, porque você pode validá-la 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 realizar 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 – atacantes transformam sua margem em seu playground por meio de raspagem, automação e cultivo 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, porque bloquear usuários reais é literalmente perda de receita.

As defesas legadas protegem principalmente largura de banda e infraestrutura. Atacantes modernos visam a lógica de negócios: fluxos de cadastro, 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 compensações muito diferentes do que a 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.

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 muito monitoramento e reações rápidas a problemas potenciais.

À medida que os aplicativos cada vez mais confiam em 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, 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 aplicativos modernos, o que essa mudança significa para como os desenvolvedores testam, implantam e raciocinam sobre segurança em sistemas de produção?

Se a segurança incorporada se tornar padrão, as equipes testarão abuso da mesma forma que testam 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 segurança como código, não como configuração de dashboard. Os agentes só podem propor, revisar e validar proteções quando os controles vivem no repositório: políticas, regras, testes e instrumentação. Se a “camada de segurança” for uma interface de usuário 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.