Somos un equipo pequeño de ingeniería y análisis de fraude que trabaja sobre un problema muy concreto: los videos sintéticos que entran por el API de un KYC sin pasar nunca por una cámara. Nacimos revisando incidentes reales en plataformas financieras y de análisis de identidad, donde el atacante controla el stream antes de que llegue al servicio. No vendemos vigilancia genérica ni promesas de detección perfecta. Construimos barreras que hacen inviable el ataque a escala y dejamos registro de cada decisión para que un analista pueda revisarla después.
El proyecto arrancó cuando un equipo de verificación remota detectó sesiones aprobadas con video que no venía de ningún sensor. Reconstruimos el recorrido de esa petición, identificamos dónde se sustituía el stream y convertimos ese hallazgo en la primera capa de análisis del servidor.
Las defensas centradas solo en el cliente se saltan con relativa facilidad. Por eso trabajamos con señales que el servicio puede observar por su cuenta: coherencia temporal entre fotogramas, artefactos de compresión, respuesta a estímulos en tiempo real y metadatos del contenedor.
Ninguna señal aislada bloquea una sesión. Combinamos autenticación fuerte, límites de tasa por identidad y dispositivo, validación de procedencia y análisis de contenido. La ponderación se ajusta con falsos positivos reales: iluminación pobre, redes lentas, dispositivos viejos.
Trabajamos con quienes responden por el onboarding y por el cumplimiento: analistas de fraude, responsables de KYC, ingeniería de plataforma. El objetivo compartido es sostener la fricción justa para el usuario legítimo sin abrir la puerta al atacante automatizado.
No prometemos detección total. Documentamos qué mira cada capa, qué se le escapa y qué métricas conviene vigilar para saber si la barrera sigue funcionando. Preferimos una limitación declarada a una promesa que se cae en la primera auditoría.
InjecGuard nació dentro de un equipo que llevaba años revisando intentos de fraude en procesos de identificación remota. Cuando empezamos a ver videos generados entrando por el endpoint y no por la cámara, no había un manual. Lo escribimos nosotros, con lo que aprendimos de cada sesión bloqueada.
Define la arquitectura de análisis en servidor y el orden en que se encadenan las capas de detección. Antes de InjecGuard trabajó en validación de identidad para entidades financieras, donde aprendió que la mayoría de los ataques no rompen el sistema: entran por donde nadie mira.
Coordina el laboratorio donde se reproducen videos sintéticos para probar la barrera antes de que lo haga un atacante. Su trabajo se centra en artefactos de compresión, coherencia temporal y metadatos del contenedor. Publica hallazgos internos cada vez que aparece una técnica nueva.
Mantiene la integración con los API de KYC de nuestros clientes sin añadir fricción al usuario legítimo. Se ocupa de los límites de tasa por identidad y dispositivo, y de que la latencia del análisis no arruine una verificación normal en una red lenta.
Traduce las señales técnicas en decisiones defendibles ante un auditor o un regulador. Documenta cada bloqueo con su justificación, y revisa que la ponderación de señales no genere falsos positivos contra usuarios con mala iluminación o dispositivos antiguos.
Acompaña a los equipos de fraude durante la puesta en marcha y en las primeras semanas de operación. Recoge los casos raros que llegan desde producción y los devuelve al laboratorio como escenarios de prueba concretos.
El equipo es pequeño y trabaja junto. Si quieres saber cómo encaja esta barrera en tu plataforma, escríbenos y te contamos sin rodeos qué cubre y qué no.
Hablar con el equipoLo que nos mueve no es una función del producto, sino una sospecha incómoda: que la verificación de identidad dejó de ser un problema de cámara y pasó a ser un problema de procedencia del stream.
Durante años, los equipos de fraude construyeron sus defensas alrededor de una idea simple: si hay una cámara, hay una persona. Ese supuesto sostiene buena parte de las comprobaciones de liveness, los retos por movimiento y las validaciones en el dispositivo. Cuando un atacante inyecta un video generado directamente en la llamada al API, la cámara desaparece de la ecuación y con ella toda la cadena de confianza que se apoyaba en el sensor. InjecGuard nace para cubrir ese hueco concreto, no para reemplazar lo que ya funciona.
Nuestro trabajo empieza donde termina el cliente. Miramos la petición que llega al backend: coherencia temporal entre fotogramas, artefactos de compresión, respuesta a estímulos en tiempo real, metadatos del contenedor y consistencia del ruido. Ninguna de esas señales decide sola. Se ponderan, se cruzan con el contexto de la sesión y se comparan contra patrones conocidos de generación sintética. El objetivo no es la detección perfecta, sino encarecer el ataque hasta que deje de ser rentable a escala.
Una barrera aislada se rodea. Por eso trabajamos con equipos de fraude que ya tienen autenticación fuerte, límites de tasa por identidad y dispositivo, y validación de sesión. Nuestra capa se suma a esa arquitectura y aporta lo que falta: análisis de procedencia del stream en el servidor. Nos importa tanto el rigor frente al atacante como la experiencia del usuario legítimo con mala iluminación o red lenta. Si la barrera expulsa a quien no debe, no sirve.
Quienes sostienen InjecGuard pasaron años viendo cómo las plataformas financieras reaccionaban tarde a vectores que ya estaban documentados. Conocemos el recorrido de una petición de verificación, los puntos donde el stream puede sustituirse y las métricas que delatan que algo cambió en el origen. Esa experiencia práctica, más que una tesis teórica, es lo que define cómo construimos cada capa de análisis y cómo la integramos sin romper el flujo existente.
Cuando la barrera funciona, el equipo de fraude deja de perseguir sesiones individuales y empieza a vigilar tendencias: qué proporción de intentos cae, qué falsos positivos aparecen con qué condiciones de red, dónde conviene ajustar el umbral. Ese cambio de mirada es el resultado real que perseguimos. No prometemos eliminar el vector, pero sí hacerlo visible, medible y caro para quien lo intenta.
El equipo venía de auditorías de fraude en plataformas financieras del sur de Argentina. En 2022, durante una revisión de un flujo de verificación remota, apareció un caso donde el stream no coincidía con ningún sensor del dispositivo. No era un bug del cliente: era una inyección directa en el endpoint. Ese expediente quedó archivado como anomalía y, meses después, se convirtió en la primera hipótesis de trabajo.
Antes de escribir una línea de producto, se reprodujo el vector en un entorno controlado. Se generaron videoclips sintéticos y se enviaron al API saltando la capa del navegador. Los controles de liveness basados en el dispositivo los aceptaron sin fricción. Ese resultado fijó el enfoque: la defensa tenía que vivir del lado del servidor, donde el atacante no controla el entorno.
La primera versión combinaba tres capas: validación de procedencia del stream, análisis temporal de coherencia entre fotogramas y señales de compresión que delatan un pipeline generativo. Se descartaron dos ideas por costo operativo: el análisis forense completo por sesión y la verificación por hardware del cliente. Ambas eran correctas en teoría y demasiado caras en producción.
El primer despliegue fue en una plataforma de análisis crediticio con KYC expuesto. Durante las primeras semanas aparecieron falsos positivos con iluminación pobre y redes móviles lentas. Ajustar los umbrales sin abrir la puerta al ataque llevó más tiempo que construir el modelo. Esa etapa definió la forma actual del producto: menos detección espectacular, más consistencia en la decisión.
InjecGuard trabaja con equipos de fraude y de identidad que necesitan bloquear la inyección directa sin frenar a usuarios legítimos. El equipo sigue siendo pequeño y sigue auditando casos reales cada semana. Lo que cambió es la posición: ya no se discute si el vector existe, sino cómo se encadena la defensa para hacerlo inviable a escala.
Para contexto técnico del vector, ver el análisis publicado en Inyección directa en API de KYC. Para conocer cómo se aplica en plataformas concretas, la página de casos de uso reúne los escenarios donde el equipo intervino.