David Mytton, CEO de Arcjet – Serie de entrevistas

David Mytton, fundador y CEO de Arcjet, lidera la startup de seguridad enfocada en desarrolladores que ayuda a los equipos a integrar protecciones robustas como la detección de bots, el límite de velocidad, la validación de correo electrónico, la mitigación de ataques y la redacción de datos directamente en el código de la aplicación, después de haber asumido el cargo en junio de 2023. También cofundó Console, un boletín y podcast de devtools muy seguido, ha desempeñado roles asesores como Experto en Residencia en Seedcamp, y anteriormente dirigió la ingeniería de productos en StackPath después de que su empresa de monitoreo de la nube fue adquirida, mientras mantiene un fuerte interés en la informática sostenible y escribe activamente sobre temas de tecnología.

Arcjet se basa en una filosofía de “seguridad como código” que permite a los desarrolladores proteger las aplicaciones con integraciones de SDK simples, colocando la lógica de seguridad junto a la lógica de negocio para decisiones de baja latencia y conscientes del contexto, y eliminando la necesidad de infraestructura separada; la plataforma admite protecciones como el bloqueo de bots, los límites de velocidad y el filtrado de datos sensibles, y sigue evolucionando con características como un modelo de seguridad de inteligencia artificial local y una mayor compatibilidad con marcos, reflejando su misión de hacer que la seguridad en el código sea la opción predeterminada para las aplicaciones modernas. (fly.io)

Fundaste Server Density en un momento en que ejecutar infraestructura a gran escala era mucho menos estandarizado de lo que es hoy, y finalmente creciste y vendiste la empresa. Al mirar hacia atrás, ¿cuáles fueron las lecciones más importantes que aprendiste sobre la construcción para desarrolladores y la operación de sistemas de producción, y cómo te influyó esa experiencia en la forma en que piensas sobre el software hoy en día?

La mayoría de las herramientas para desarrolladores ganan la demostración y pierden la producción. Hacer que un desarrollador instale algo nuevo es difícil, por lo que “iniciar rápido” tiene que ser sin fricciones – pero eso es lo mínimo. El verdadero modo de falla es lo que sucede después de “funciona”: el producto se vuelve tan limitado que los equipos serios se frustran rápidamente y lo sacan.

Es por eso que la seguridad de la aplicación en código de Arcjet está diseñada para dos realidades: necesitas una solución inmediata para el spam de registro, el fraude de cuentas, los ataques de bots, el abuso de API, etc., y también necesitas una salida de emergencia hacia controles avanzados – cuotas por usuario, reglas basadas en riesgos y decisiones conscientes del contexto – sin tener que reescribir todo.

El producto no es la interfaz de usuario. El producto es el comportamiento en tiempo de ejecución, los casos de borde, los ejemplos y la documentación de referencia que los desarrolladores pueden confiar.

Al salir de esa experiencia, ¿qué te llevó a iniciar Arcjet, y por qué sentiste que el próximo gran cambio en la seguridad de la aplicación necesitaba ocurrir dentro del código en sí, en lugar de en la capa de red o infraestructura?

La seguridad perimetral es optimizar lo incorrecto. Los desarrolladores construyen y envían en código, no en paneles – y los agentes de codificación de inteligencia artificial no “navegarán” por una consola de seguridad para proteger una aplicación.

Si tu protección no se puede expresar como código, revisar en una solicitud de extracción, probar en CI y desplegar junto con la aplicación, no es “seguridad enfocada en el desarrollador”.

Arcjet existe porque la seguridad pertenece a la capa de la aplicación: controlada por versiones, probada, observable y cerca de la lógica de negocio donde realmente vive la intención.

Arcjet incorpora la detección de amenazas con inteligencia artificial directamente en los controladores de solicitudes de la aplicación. Desde una perspectiva técnica, ¿qué ventajas proporciona este enfoque local y en código en comparación con las herramientas de seguridad tradicionales basadas en perímetro?

Dentro de un controlador de solicitudes tienes identidad, estado de sesión, historial de compras, edad de la cuenta, flags de características y verdad de la base de datos. Puedes tomar una decisión como: “Esto parece extraño, pero es un cliente leal – aumenta la verificación en lugar de bloquear”. Un proxy de red no puede hacer eso porque no tiene idea de qué es un “cliente”.

El objetivo no es el bloqueo máximo. El objetivo es minimizar los falsos positivos con seguridad consciente del contexto, porque el error de seguridad más costoso es bloquear una compra legítima o bloquear a un usuario real.

La inteligencia artificial ha cambiado dramáticamente la economía del abuso, desde el scraping de bots y el spam de registro hasta la explotación automatizada de API. ¿Qué tipos de ataques estás viendo con más frecuencia en producción hoy en día, y cómo están evolucionando a medida que los atacantes adoptan sistemas de inteligencia artificial más avanzados?

Los beneficios de productividad de la inteligencia artificial también están ayudando a los atacantes. El gran cambio es el volumen y la velocidad de iteración: más relleno de credenciales, más spam de registro automatizado, más scraping de bots, más exploración de API y una “arma” más rápida de vulnerabilidades frescas.

También estamos viendo a los atacantes ejecutar bucles de retroalimentación más ajustados: prueban las defensas, adaptan los prompts y las cargas, rotan la infraestructura y siguen hasta que logran entrar. Actualmente, todo se trata de velocidad en lugar de sofisticación.

Todavía hay demasiadas personas que no siguen las mejores prácticas, como usar un administrador de contraseñas, implementar autenticación de dos factores con credenciales resistentes a phishing como passkeys o claves de hardware, y mantener las dependencias actualizadas. Con el aumento del volumen de ataques, eso se volverá cada vez más importante.

Una de las mayores tensiones en la seguridad es proteger las aplicaciones sin frenar el desarrollo. ¿Cómo han podido los equipos que utilizan Arcjet integrar la seguridad en sus flujos de trabajo mientras mantienen ciclos de lanzamiento rápidos?

Arcjet se ejecuta en cualquier entorno, incluido el entorno de codificación en una laptop. Eso significa que los desarrolladores pueden probarlo sin siquiera implementarlo en producción. Esta es una ventaja significativa porque pueden validarla y demostrar la integración sin necesidad de permisos especiales y sin riesgo de afectar la producción. Esto resuelve el problema clásico de que los equipos de seguridad obligan a los desarrolladores a adoptar herramientas que obstaculizan su capacidad para hacer su trabajo.

Arcjet ha ganado una aceptación temprana con productos nativos de inteligencia artificial y plataformas de comercio electrónico. ¿Qué hace que estos entornos sean especialmente vulnerables a los ataques automatizados modernos, y por qué las defensas heredadas tienden a ser insuficientes?

Estas dos categorías comparten una similitud donde cada solicitud abusiva tiene un costo directo.

Los productos de inteligencia artificial pagan por tokens y inferencia – los atacantes convierten su margen en su patio de recreo a través del scraping, la automatización y la agricultura de nivel gratuito. El comercio electrónico paga por fraude, devoluciones, abuso de inventario y recuperación de cuentas. Y ambos son hipersensibles a los falsos positivos porque bloquear a los usuarios reales es literalmente pérdida de ingresos.

Las defensas heredadas protegen principalmente la banda ancha y la infraestructura. Los atacantes modernos apuntan a la lógica de negocio: flujos de registro, flujos de pago, lógica de promociones, recuperación de cuentas y puntos de conexión de API. Es por eso que los controles perimetrales genéricos y “resolverlo con un CAPTCHA” cada vez son más insuficientes.

Desarrollar software de seguridad conlleva compensaciones muy diferentes a las de la observabilidad o el monitoreo. ¿Qué te sorprendió más sobre el desarrollo de un producto de seguridad en comparación con tu experiencia anterior con herramientas de infraestructura?

Con la observabilidad, los clientes confían en que estés disponible. Con la seguridad, los clientes confían en que seas seguro y no te conviertas en su última explotación de la cadena de suministro.

Desarrollar un producto de seguridad significa ejecutar una empresa de seguridad. Usamos marcos como SOC 2, minimizamos nuestras dependencias de terceros y tratamos las laptops de los desarrolladores y el acceso a las herramientas como activos de producción. Esto significa mucha supervisión y reacciones rápidas a problemas potenciales.

A medida que las aplicaciones dependen cada vez más de los agentes de inteligencia artificial que actúan en nombre de los usuarios, ¿cómo deberían los desarrolladores replantear ideas como la identidad, la intención y la confianza en la capa de la aplicación?

A medida que los agentes de inteligencia artificial actúan en nombre de los usuarios, la identidad deja de ser un estado de inicio de sesión binario y se convierte en un problema de delegación: quién actúa, en nombre de quién, con qué permisos, durante cuánto tiempo y con qué restricciones.

Los desarrolladores deberían cambiar a la verificación continua: tratar cada solicitud como si necesitara una decisión de confianza fresca basada en el contexto – historial del usuario, señales de dispositivo, comportamiento de sesión y riesgo de acción. La “intención” se infiere del comportamiento con el tiempo, no se afirma en los encabezados.

Esto significa construir momentos de escalada (verificación, límites de velocidad, fricción) alrededor de acciones de alto riesgo como el restablecimiento de la contraseña, el pago y la creación de tokens – y hacer que esos controles vivan en el código, donde la aplicación puede distinguir a un cliente leal de un bot con una cookie robada.

Al mirar hacia adelante, ¿cómo ves la evolución del papel de la seguridad en código y consciente del contexto a medida que el tráfico generado por la inteligencia artificial sigue creciendo en los próximos años?

Las herramientas perimetrales no desaparecerán – pero se convertirán en el filtro grueso para cosas que se ocupan mejor en la red, como los ataques de denegación de servicio. Las decisiones precisas ocurrirán dentro de la aplicación, utilizando contexto real.

Si la seguridad integrada se convierte en el modelo predeterminado para las aplicaciones modernas, ¿qué significa eso para la forma en que los desarrolladores prueban, implementan y razonan sobre la seguridad en los sistemas de producción?

Si la seguridad integrada se convierte en estándar, los equipos probarán el abuso de la misma manera que prueban la corrección: pruebas de seguridad de unidad, simulaciones de ataques reproducibles y verificaciones de CI para puntos de conexión de riesgo.

El mayor cambio es que los agentes de codificación de inteligencia artificial implementarán la seguridad como código, no como configuración de panel. Los agentes solo pueden proponer, revisar y validar protecciones de manera fiable cuando los controles viven en el repositorio: políticas, reglas, pruebas e instrumentación. Si la “capa de seguridad” es una interfaz de usuario web, el agente no puede probar los cambios para enviarlos de manera segura.

Esa es la verdadera razón por la que “la seguridad en el código” gana – se adapta a cómo se construye y desarrolla el software moderno (y el desarrollo asistido por inteligencia artificial moderna).

Gracias por la gran entrevista, los lectores que deseen aprender más pueden visitar Arcjet.