Por qué los agentes de programación con IA siguen generando fallas de control de acceso

Los agentes de programación con IA generan lógica de autorización que compila, supera la revisión y aplica la política equivocada. El control de acceso roto ocupa el primer lugar en la lista OWASP Top 10:2025, donde el 100 % de las aplicaciones analizadas presentó alguna forma de esta vulnerabilidad, con 1,839,701 casos registrados, la cifra más alta de todas las categorías de la lista.

Una parte de esta categoría también es la que el análisis basado en patrones nunca estuvo diseñado para detectar. Cuando un agente omite una verificación de propiedad, la regla que incumplió pertenece a la aplicación, no a una base de datos de firmas. Por eso no hay ningún patrón malicioso conocido con el que compararlo.

¿Qué es el control de acceso roto?

El control de acceso roto es la falla al aplicar lo que un usuario autenticado tiene permitido hacer o ver. El usuario demuestra quién es y, después, la aplicación le entrega datos o acciones que pertenecen a otra persona. Dos casos específicos representan la mayoría de los que encuentran los equipos.

1. BOLA: autorización rota a nivel de objeto

BOLA es la falla al verificar que quien hace la solicitud tenga derecho al objeto específico que solicitó. Ocupa el primer lugar en la lista OWASP API Security Top 10, por lo que encabeza las dos listas de OWASP aplicables a las aplicaciones modernas.

2. IDOR: referencia directa a objetos insegura

IDOR es la misma falla vista desde la perspectiva del atacante. La aplicación expone un identificador interno, como el ID de un registro, y al reemplazarlo por otro valor se devuelven datos que pertenecen a otra cuenta. Por lo general, un mismo error es tanto BOLA como IDOR.

OWASP colocó esta categoría en el primer lugar de su lista en 2021, y se ha mantenido ahí hasta la edición de 2025. Son fallas simples. Conservan esa posición porque son fáciles de introducir, difíciles de detectar automáticamente y muy valiosas para quien las encuentra.

¿Por qué los agentes de programación con IA se equivocan tanto con la autorización?

El desarrollo de software se volvió agéntico, pero la seguridad no. La seguridad de las aplicaciones se creó en torno a un análisis que compara el código con patrones maliciosos conocidos y entrega los resultados a personas que conocen las reglas del producto. Cuando un agente escribe el endpoint, nadie en el proceso sigue esas reglas de forma predeterminada, y la falla resultante no tiene un patrón con el cual compararla. Para cerrar esa brecha se necesita más que otra regla.

Porque el requisito de autorización nunca se especificó, y el agente no se equivoca al realizar la tarea que le dieron. Imagina que un desarrollador le pide a un agente de programación que agregue un endpoint que devuelva una factura por ID. El agente crea una ruta que verifica que quien hace la solicitud haya iniciado sesión, busca la factura con el identificador de la URL, devuelve un 404 cuando no encuentra coincidencias y envía el registro al cliente.

Todas esas decisiones son correctas para la tarea tal como se planteó. El endpoint autentica, gestiona el caso en que no se encuentra el registro y se entiende fácilmente al revisarlo. También permite que cualquier usuario autenticado lea cualquier factura del sistema con solo cambiar un valor en la URL.

La corrección consiste en agregar una condición a la búsqueda: buscar la factura por su identificador y por la organización a la que pertenece quien hace la solicitud. No cambia nada más del endpoint.

Por qué no es posible conocer la solución solo a partir del código

Saber que la segunda versión es correcta requiere tres datos que no aparecen en ninguna parte del código generado:

• Las facturas pertenecen a organizaciones.

• El acceso de un usuario se limita a las organizaciones de las que es miembro.

• En este producto, nunca se permiten lecturas entre organizaciones.

En otro producto, el tercer dato podría ser falso, ya que algunas plataformas permiten, por diseño, que auditores, revendedores o cuentas principales accedan a datos de otros inquilinos. La regla es una propiedad del producto, no del lenguaje ni del framework. Está en el modelo de datos, en una decisión tomada hace dos años y en la mente de los ingenieros que la tomaron.

Qué debería revisar el equipo

Por lo general, un desarrollador del equipo detecta esto por una razón: conoce el producto. Un agente que trabaja a partir de la instrucción y del archivo que tiene alrededor no puede acceder a lo que hace necesaria esa verificación.

Hay dos detalles que vale la pena tener en cuenta durante la revisión. El primero es el código de respuesta. Incorporar la condición de propiedad en la búsqueda hace que una solicitud de una factura de otra organización devuelva el mismo 404 que una solicitud de una factura inexistente. Ese es el comportamiento que buscas, porque un 403 confirmaría que el registro existe y permitiría que un atacante enumerara identificadores válidos. El segundo detalle es qué datos se devuelven. Devolver el registro almacenado sin modificarlo envía todos sus campos, por lo que el mismo controlador suele tener un problema de exposición de datos además del de autorización.

¿Las herramientas SAST pueden detectar el control de acceso roto?

En las clases de vulnerabilidades que tienen un patrón, la detección está prácticamente resuelta. La autorización es la excepción y aparece justo donde el código generado por IA es más débil. El análisis estático rastrea patrones que se pueden describir, pero la autorización a nivel de objeto no tiene un patrón de ese tipo.

Tomemos una inyección como contraste: una vulnerabilidad de inyección tiene un patrón que se puede describir: una entrada no confiable llega a un punto de destino peligroso sin pasar por la sanitización. Ese patrón se convierte en una regla, y un motor sigue los datos desde el origen hasta el destino y reporta todas las rutas que coinciden.

Qué aspectos del control de acceso roto sí cubre el análisis estático

El control de acceso roto es la categoría más grande de OWASP Top 10, y no todos sus casos se resisten al análisis. A01:2025 abarca 40 CWE, y varios tienen exactamente el tipo de patrón rastreable que el análisis estático maneja bien, como el recorrido de rutas, las redirecciones abiertas y la falsificación de solicitudes del lado del servidor. Los motores semánticos modernos van más allá de comparar firmas: modelan el flujo de datos y la intención del código, y pueden señalar que falta un decorador de autorización o un middleware en una ruta cuando el código base sigue una convención coherente.

Dónde están los límites de la cobertura

La parte que se resiste al análisis es más acotada: la autorización a nivel de objeto, clasificada como CWE-639 (omisión de autorización mediante una clave controlada por el usuario), CWE-862 (falta de autorización) y CWE-863 (autorización incorrecta). En estos casos, no se llama a nada peligroso, ningún valor no confiable llega a un lugar indebido y cada línea sigue las convenciones habituales. El defecto es la ausencia de una comparación que solo exigen las reglas propias de la aplicación.

Para señalar esta falla, un motor tendría que saber qué campos representan la propiedad en este esquema, qué usuarios tienen permiso y dónde está el límite entre inquilinos. No se trata de la calidad de la regla. Es información que no existe en el archivo que se analiza.

Los motores deterministas y el razonamiento se complementan; no compiten entre sí. Los motores siempre devuelven el mismo resultado para las clases que cubren, lo que permite que un equipo los use como condición para aprobar una canalización. La autorización a nivel de objeto está fuera del alcance de lo que una regla puede describir, así que hace falta otro instrumento para abordarla.

¿Cómo encontrar fallas que no tienen un patrón?

Puedes encontrar fallas que no tienen un patrón si razonas a partir de un modelo de la aplicación en lugar de analizar solo el archivo que tienes enfrente.

Para encontrar el error de la factura se necesitan cuatro datos: qué llama a este endpoint, a qué pertenece el objeto que se consulta, qué usuarios tienen derecho a acceder a él y dónde está el límite de confianza entre inquilinos. Esos datos se pueden recuperar del código base, el esquema y lo que se ejecuta en producción, pero hay que reunirlos en un modelo que pueda leer un análisis. Snyk llama a este modelo reunido el grafo de contexto de la aplicación: arquitectura, flujos de datos, clasificaciones de datos, límites de confianza y realidad de producción, creado una vez y actualizado a medida que cambia el código. Una vez que existe, la falta de una verificación de propiedad se vuelve visible porque el análisis puede comparar lo que exige el endpoint con las reglas propias de la aplicación.

Se necesitan tres condiciones para que el resultado sea confiable.

1. El razonamiento debe basarse en ese modelo. Sin él, el razonamiento de frontera produce hallazgos plausibles sobre un código base que ha imaginado en parte, y consume tokens al analizar a ciegas.

2. Los hallazgos deben confirmarse con algo que no los haya generado. No se puede confiar en que un agente que encuentra una vulnerabilidad valide su propia solución, y un sistema que califica su propio resultado arrastra todo lo que su análisis pasó por alto.

3. La solución debe demostrarse, no solo proponerse. La corrección de una línea debe validarse según las reglas de la aplicación y demostrarse que sigue siendo válida a medida que cambia el código. Un hallazgo que nunca se convierte en una solución integrada deja el endpoint tan expuesto como antes.

Razonar sobre la aplicación reunida, con motores deterministas trabajando en paralelo, es la dirección que Snyk está tomando con Evo Agentic AppSec, presentado por primera vez en agosto. Las pruebas en tiempo de ejecución confirman entonces qué puede alcanzar un atacante, que es donde Evo Continuous Offensive Security encaja actualmente.

¿Qué debería hacer tu equipo ahora?

Cinco pasos que no requieren nuevas herramientas para empezar.

1. Haz un inventario de los endpoints que aceptan un identificador de objeto en la solicitud. Toda ruta que reciba un ID, nombre de archivo o clave de una URL o un cuerpo es candidata. Por lo general, esta lista es más corta de lo que esperan los equipos y más larga de lo que quisieran.

2. Documenta las reglas de propiedad. Para cada tipo de recurso, registra a quién o a qué pertenece y quién puede leerlo o modificarlo. Las fallas de autorización superan las revisiones porque esta información nunca se ha documentado en un lugar que un revisor o analista pueda consultar.

3. Incluye la autorización como un punto explícito de revisión en los pull request escritos por agentes. No una instrucción general de revisar con cuidado, sino una pregunta específica: ¿este endpoint verifica que quien hace la solicitud tenga derecho a acceder al objeto y qué campo usa para hacerlo?

4. Agrega una prueba entre inquilinos para cada tipo de recurso. Las recomendaciones de prevención de OWASP son claras: los desarrolladores y el personal de control de calidad deben incluir pruebas funcionales de control de acceso en sus pruebas unitarias y de integración. Una prueba por recurso que verifique que una sesión válida de un inquilino recibe un 404 al solicitar el objeto de otro inquilino convierte la regla que documentaste en el paso dos en una regla que se sigue aplicando.

5. Agrega análisis profundo de todo el código base con regularidad. El punto de control ahora se divide en tres: en tiempo real dentro del ciclo de trabajo del agente, análisis deterministas rápidos en cada cambio de CI y análisis contextual profundo de todo el código base. Las fallas de autorización a nivel de objeto aparecen en el tercero.

¿Cuáles de tus endpoints fallarían hoy esa prueba entre inquilinos? Empieza con el inventario del primer paso. Para ver cómo Snyk está abordando la seguridad de las aplicaciones agénticas, lee Un primer vistazo a Evo Agentic AppSec.