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, límites de velocidad, validación de correo electrónico, mitigación de ataques y 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 co-fundó Console, un boletín y podcast de devtools muy seguidos, ha servido en 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 la escritura activa sobre temas de tecnología.

Arcjet se basa en una filosofía de “seguridad como código” que permite a los desarrolladores asegurar 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, límites de velocidad y 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 de trabajo, reflejando su misión de hacer que la seguridad en el código sea la opción predeterminada para las aplicaciones modernas. (fly.io)

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

La mayoría de las herramientas de desarrollador ganan la demostración y pierden la producción. Obtener que un desarrollador instale algo nuevo es difícil, por lo que “iniciar rápido” tiene que ser sin fricción – 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 quitan.

Es por eso que la seguridad de la aplicación en código de Arcjet está diseñada para dos realidades: necesita una solución inmediata para el spam de registro, el fraude de cuenta, los ataques de bots, el abuso de API, etc., y también necesita una salida de emergencia a 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é lo llevó a iniciar Arcjet, y por qué sintió 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 la cosa equivocada. Los desarrolladores construyen y envían en código, no en paneles – y los agentes de codificación de inteligencia artificial no “hacen clic alrededor” de una consola de seguridad para proteger una aplicación.

Si su protección no se puede expresar como código, revisar en una solicitud de extracción, probar en CI y implementar junto con la aplicación, no es “seguridad primero para desarrolladores”.

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

Arcjet integra 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, indicadores 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 la seguridad consciente del contexto porque el error de seguridad más costoso es bloquear una verificación 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 ve más comúnmente 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 llenado de credenciales, más spam de registro automatizado, más scraping de bots, más sondeo de API y “armamento” más rápido de vulnerabilidades frescas.

También estamos viendo que los atacantes ejecutan bucles de retroalimentación más ajustados: prueban las defensas, adaptan los prompts y las cargas útiles, rotan la infraestructura y siguen adelante hasta que entran. 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 va a ser cada vez más importante.

Una de las mayores tensiones en la seguridad es proteger las aplicaciones sin ralentizar 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 impiden 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 explotación de la capa gratuita. El comercio electrónico paga por el fraude, las devoluciones, el abuso de inventario y la toma de cuenta. Y ambos son hipersensibles a los falsos positivos porque bloquear a los usuarios reales es literalmente una 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 cuenta y puntos finales de API. Es por eso que los controles perimetrales genéricos y “resolverlo con un CAPTCHA” cada vez son más insuficientes.

Crear software de seguridad conlleva compensaciones muy diferentes que la observabilidad o el monitoreo. ¿Qué lo sorprendió más sobre el desarrollo de un producto de seguridad en comparación con su experiencia anterior con herramientas de infraestructura?

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

Crear 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 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 de 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 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.

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

Las herramientas perimetrales no desaparecerán – pero serán 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 ese cambio 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 finales 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 confiable 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 realmente el software moderno (y el desarrollo asistido por inteligencia artificial).

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