Pentest GPT, qué es, qué hace bien y dónde sigue fallando el Pentesting de IA

La frase pentest gpt ahora significa dos cosas diferentes a la vez, y esa división es lo primero que los ingenieros de seguridad tienen que hacer bien. En un sentido, apunta a PentestGPTel proyecto de investigación publicado por USENIX Security 2024 y mantenido en GitHub. En un sentido más amplio, se ha convertido en la abreviatura de toda una clase de sistemas que combinan grandes modelos de lenguaje, salida de escáner, llamada a herramientas, lógica de ejecución, seguimiento de estado y generación de informes en algo que se parece a un probador de penetración asistido por IA. Esta distinción es importante porque el artículo original fue un hito en la investigación, mientras que el término de mercado más amplio ahora cubre todo, desde envoltorios ligeros ChatGPT hasta plataformas completas de pentesting agéntico. (arXiv)

Ese uso más amplio del término no es una mera deriva de marketing. Refleja un cambio real en la tecnología subyacente. La invocación de herramientas es ahora un patrón de diseño estándar para los sistemas LLM modernos, y la actual guía de agentes de OpenAI trata la inyección de comandos, la fuga de datos y la invocación de herramientas de riesgo como problemas de ingeniería de primera clase y no como casos extremos. Al mismo tiempo, la investigación de terceros ha demostrado que los agentes de IA ya pueden automatizar una cantidad sorprendente de trabajo ofensivo en entornos de alcance limitado, aunque siguen siendo inferiores a los humanos cualificados cuando se requiere priorización, pivotes estratégicos y un juicio operativo más amplio. (Desarrolladores de OpenAI)

Así que la verdadera cuestión ya no es si los modelos de tipo GPT pueden contribuir a las pruebas de penetración. Está claro que sí. La pregunta más difícil es qué parte del ciclo de vida del pentesting pueden hacer bien, dónde siguen fallando, y qué debería exigir un equipo de ingeniería responsable de cualquier producto o flujo de trabajo comercializado como "Pentest GPT". Aquí es donde el documento original de PentestGPT sigue siendo útil, porque explica tanto las promesas como los límites con una claridad inusual. Los autores construyeron un punto de referencia en torno a objetivos de pruebas de penetración del mundo real, observaron que los LLM generales eran a menudo competentes en tareas locales como el uso de herramientas y la interpretación de resultados, y luego mostraron que seguían luchando para preservar una comprensión integrada de todo el escenario de ataque a lo largo del tiempo. Su respuesta fue un diseño modular destinado a reducir la pérdida de contexto. En su evaluación, PentestGPT mejoró la finalización de tareas en un 228,6 por ciento con respecto a GPT-3.5 en los objetivos de referencia. (arXiv)

Ese resultado es una de las razones por las que el proyecto resonó con tanta fuerza. El documento no afirmaba que la IA ya hubiera resuelto la seguridad ofensiva. Afirmaba algo más creíble y, en retrospectiva, más importante: Los LLM ya eran lo suficientemente potentes como para ayudar con el pegamento de razonamiento entre las herramientas tradicionales, pero lo suficientemente débiles como para que la arquitectura y el diseño del flujo de trabajo determinaran si el sistema seguía siendo útil o se convertía en ruido. Los autores también enmarcaron las pruebas de penetración en el conocido ciclo de vida de cinco fases de reconocimiento, exploración, evaluación de vulnerabilidades, explotación e informe posterior a la explotación, que sigue siendo una forma útil de juzgar los modernos sistemas de pentesting de IA. Un modelo que parece bueno en una demostración pero que no puede mantener el estado a lo largo de esas fases no está resolviendo el pentesting. Está automatizando fragmentos aislados. (arXiv)

Qué es realmente pentest gpt

Una buena definición es la siguiente: Pentest GPT es un sistema de pruebas de penetración asistido por IA que utiliza un modelo de lenguaje como capa de razonamiento y orquestación entre los datos del objetivo, las herramientas de seguridad, los entornos de ejecución, la captura de pruebas y la generación de informes. Eso es muy distinto de pedirle a un chatbot general que sugiera cargas útiles o explique un CVE. Los explicadores de alto rango de la industria sobre la frase convergen mayoritariamente en este punto. Describen "Pentest GPT" no como un hacker mágico de una sola pregunta, sino como un sistema que se conecta a herramientas como escáneres y frameworks, interpreta sus resultados, propone los siguientes pasos e intenta hacer un seguimiento de lo que ya se ha intentado (...).Aikido)

De ahí que el término se extienda más allá del proyecto original. Una vez que se acepta que el modelo no es el producto por sí mismo, la frase se expande de forma natural para incluir el resto de la pila: el terminal o el tiempo de ejecución, los adaptadores de herramientas, el navegador o los conectores API, la política de ejecución, el almacén de estados, el normalizador de hallazgos y el generador de informes. La documentación actual de OpenAI sobre llamadas a funciones y agentes encaja directamente en esta arquitectura. Los modelos pueden conectarse a funciones externas, delimitadas por esquemas y envueltas en flujos de trabajo de agentes con salvaguardas explícitas para acciones de alto riesgo. No se trata de una plataforma de pentesting en sí misma, pero es exactamente el sustrato que hace posibles los sistemas modernos de estilo pentest-gpt. (Desarrolladores de OpenAI)

La forma más útil de pensar en esta categoría no es "¿Puede el modelo hackear?", sino "¿Puede el sistema pasar con seguridad de la observación al hallazgo verificado?". En la práctica, eso significa que un Pentest GPT creíble debe hacer al menos seis cosas bien. Debe ingerir el contexto del objetivo sin colapsar por el ruido. Debe seleccionar las herramientas y las acciones en función de la fase del compromiso. Debe conservar un registro auditable de acciones y resultados. Debe separar las hipótesis de los resultados verificados. Debe saber cuándo hacer una pausa para la aprobación o la revisión humana. Y debe traducir la actividad bruta en pruebas que otro ingeniero pueda reproducir. Estos requisitos no son sutilezas opcionales. Son la línea divisoria entre una curiosidad de investigación y un sistema útil desde el punto de vista operativo. (arXiv)

Donde Pentest GPT ya es útil

Los casos de uso actuales más potentes no son misteriosos. Los sistemas de IA ya son buenos comprimiendo los resultados de escáneres ruidosos, convirtiendo artefactos dispersos en una narrativa de ataque plausible, redactando comandos o scripts de seguimiento, traduciendo registros sin procesar en hallazgos estructurados y acelerando el ciclo de informes. El trabajo original de PentestGPT observó que los LLM eran a menudo competentes en subtareas como la interpretación de los resultados de las herramientas y la propuesta de acciones posteriores. Una evaluación más reciente de Wiz descubrió que los agentes de IA resolvían 9 de cada 10 retos de seguridad ofensiva cuando los objetivos eran específicos y tenían un alcance claro, que es exactamente el tipo de entorno en el que el razonamiento local y la iteración repetida son más valiosos. (arXiv)

Esto coincide con lo que los probadores experimentados realmente necesitan ayuda. Las partes que más tiempo consumen en muchos casos no son los momentos de explotación. Son las horas dedicadas a reconciliar pistas contradictorias, revisar registros, reescribir comandos de shell frágiles, volver a probar la misma ruta tras un pequeño cambio de contexto y convertir una sospecha a medio formar en una declaración técnica concisa con pruebas. Los LLM son muy adecuados para esa capa de traducción. Pueden resumir los resultados, preservar la coherencia de los nombres, proponer hipótesis alternativas y generar una primera pasada coherente de un informe mientras el operador humano se centra en el juicio sobre el objetivo y las decisiones sobre los límites. Se trata de un aumento, no de una sustitución, y hoy en día sigue siendo el camino más realista hacia el valor. (Aikido)

Otro lugar en el que Pentest GPT ayuda es en la sutura de la ruta de ataque. Los escáneres tradicionales son buenos sacando a la luz los síntomas. Son mucho menos buenos narrando la ruta desde "respuesta extraña aquí" hasta "impacto explotable en el negocio allí". Un modelo con acceso a notas sobre el objetivo, comandos anteriores y resultados de herramientas a menudo puede articular esa ruta más rápido que un humano escribiendo desde cero. Eso no significa que el camino sea siempre correcto. Significa que el modelo puede llevarle más rápidamente a la lista de cadenas plausibles. En flujos de trabajo sólidos, esa velocidad es valiosa porque el evaluador humano puede dedicar más tiempo a validar las cadenas interesantes y menos a reconstruir el contexto. (arXiv)

Donde Pentest GPT todavía se rompe

Los límites están ahora mejor documentados que la exageración. El propio documento PentestGPT concluyó que a los LLM les costaba mantener una visión global del contexto del escenario de la prueba, razón por la cual el sistema se diseñó en torno a múltiples módulos que interactuaban entre sí, en lugar de en torno a un único indicador gigante. La evaluación 2026 de Wiz llegó a una conclusión similar desde un ángulo diferente: Los agentes de IA se desenvolvían bien en tareas específicas, pero se degradaban notablemente en escenarios más amplios y realistas en los que tenían que priorizar objetivos, elegir estrategias en condiciones de incertidumbre y abandonar líneas de ataque fallidas. Los humanos pivotaban. Los agentes de IA a menudo repetían variaciones del mismo enfoque. (arXiv)

Ese modo de fallo es fácil de subestimar porque no siempre parece un fallo en la transcripción. El modelo sigue siendo fluido. Los comandos siguen pareciendo plausibles. El borrador del informe sigue sonando confiado. Pero el sistema puede estar dando vueltas en un callejón sin salida mientras conserva el tono de progreso. En las pruebas de penetración, eso es peligroso. Un falso positivo es molesto. Una falsa sensación de cobertura es peor. Los ingenieros que evalúan los productos GPT de Pentest deberían ser inusualmente escépticos con cualquier flujo de trabajo que no pueda mostrar transiciones de estado explícitas, justificaciones de acciones y umbrales de evidencia para escalar de "interesante" a "verificado." (arXiv)

También hay una segunda clase de fallos que no tienen nada que ver con la estrategia ofensiva y sí con la seguridad de los agentes. El NIST describe secuestro de agentes como una forma de inyección indirecta de avisos en la que se insertan instrucciones maliciosas en los datos que ingiere un agente de IA, provocando que realice acciones dañinas no intencionadas. La propia guía de OpenAI es igualmente contundente: las inyecciones de instrucciones son comunes y peligrosas, y pueden resultar en la exfiltración de datos privados o acciones desalineadas a través de llamadas a herramientas. Esto importa enormemente para los sistemas GPT de Pentest, porque en el momento en que el modelo puede leer contenido no fiable y también operar herramientas, la inyección de prompt deja de ser un extraño truco del modelo de lenguaje y se convierte en un problema de la superficie de ejecución. (NIST)

Este cambio es la principal razón por la que la categoría ha madurado. Las primeras discusiones sobre pentest gpt se centraban en si el modelo podía razonar a través de un desafío web o generar comandos útiles. Las discusiones actuales tienen que incluir si el tiempo de ejecución puede sobrevivir a la entrada maliciosa, si la invocación de la herramienta tiene alcance, si los registros son resistentes a la manipulación, si las acciones de escritura están limitadas, y si el sistema puede distinguir la observación de la autorización. Una vez que la IA toca archivos reales, shells, API y sesiones de navegador, el problema ya no es "¿Puede ser útil el modelo?". Es "¿Puede el flujo de trabajo seguir siendo digno de confianza en condiciones adversas?". (Desarrolladores de OpenAI)

La diferencia de arquitectura entre un chatbot y un sistema pentest real

Aquí es donde gran parte del mercado todavía se enturbia. Un chatbot puede explicar una clase de vulnerabilidad y generar un comando. Un verdadero sistema de pentest necesita capas adicionales que sean visibles para el operador y auditables después del hecho. Necesita esquemas o adaptadores de herramientas, límites de permisos explícitos, estado duradero, hallazgos estructurados, ganchos de aprobación para acciones arriesgadas y un rastro de artefactos reproducible. Las actuales directrices para agentes de OpenAI reflejan exactamente este enfoque por capas, incluyendo salvaguardas para herramientas de alto riesgo basadas en la reversibilidad, el nivel de permiso y el potencial impacto financiero u operativo. (Desarrolladores de OpenAI)

Una arquitectura GPT Pentest práctica suele tener este aspecto:

1. Nivel de planificación - interpreta el ámbito y el contexto de destino y, a continuación, descompone el trabajo en tareas.
2. Capa de ejecución - invoca escáneres, clientes HTTP, navegadores, scripts u otras herramientas.
3. Capa estatal - registra lo que se intentó, lo que cambió y lo que sigue siendo incierto.
4. Capa de validación - comprueba si las pruebas cumplen un umbral antes de promover una conclusión.
5. Capa de control - aplica aprobaciones, límites de tarifa, límites de acceso y registros de auditoría.
6. Capa de información - convierte las pruebas en conclusiones reproducibles y orientaciones para su corrección.

Si un proveedor o una herramienta interna no pueden explicar estas capas con claridad, probablemente el sistema esté más cerca de un asistente inteligente que de un flujo de trabajo de pentesting serio. Esto no significa que sea inútil. Sólo significa que no debes evaluarlo como si ya fuera un probador autónomo de confianza. (Desarrolladores de OpenAI)

Las CVE que importan en torno a pentest gpt

No existe un único "PentestGPT CVE" que explique este campo. La lección más importante proviene del ecosistema circundante. Tan pronto como los sistemas de pentesting de IA se convierten en agénticos, empiezan a heredar los riesgos de los frameworks, capas de orquestación, interfaces web, características de conexión directa y lógica de integración de herramientas a su alrededor. El reciente flujo de CVE en LLM y herramientas de agentes lo deja muy claro. (NVD)

Estos CVEs son importantes no porque todos pertenezcan a productos explícitamente comercializados como herramientas pentest. Importan porque revelan la superficie de ataque real de cualquier pila GPT Pentest moderna. El riesgo no se limita al comportamiento del modelo. Incluye el analizador sintáctico, la interfaz de usuario web, la sesión del navegador, el mecanismo de conexión directa, el puente de herramientas y la forma en que las credenciales se transmiten a través del sistema. La cuestión de seguridad nunca es sólo "¿Cómo de inteligente es el modelo?". Es "¿En qué pueden influir las entradas hostiles, a qué herramientas puede acceder el agente y qué pruebas se necesitan antes de que el sistema actúe?". (Desarrolladores de OpenAI)

Un incidente del mundo real de 2026 refuerza el mismo punto aunque no sea un CVE. Cline reveló que una parte no autorizada utilizó un token npm comprometido para publicar cline@2.3.0y la autopsia rastreó la causa raíz a través de un flujo de trabajo de triaje de incidencias impulsado por IA que expuso el acceso shell en GitHub Actions, permitiendo una cadena de envenenamiento de prompt-injection-to-cache. En última instancia, el paquete publicado no contenía ningún código malicioso, pero el incidente no deja de ser una valiosa lección sobre cómo los flujos de trabajo agénticos pueden amplificar errores conocidos de la cadena de suministro. (Cline)

Cómo debería ser un flujo de trabajo Pentest GPT fiable

El primer principio de diseño es sencillo: las pruebas deben primar sobre la elocuencia. Un modelo lingüístico siempre puede producir una explicación plausible. No se puede permitir que promueva un hallazgo a menos que el flujo de trabajo haya capturado suficientes artefactos para apoyar la reproducibilidad. En la práctica, eso significa normalizar cada problema candidato en un objeto estructurado con alcance, ruta de ataque, fuente de pruebas, activo afectado, nivel de confianza y notas de corrección. La prosa libre es útil para los informes, pero no debe ser la fuente de la verdad. (Desarrolladores de OpenAI)

{
  "finding_id": "F-2026-0142",
  "title": "Referencia de objeto directo potencialmente insegura",
  "status": "needs_validation",
  "asset": "api.ejemplo.com",
  "evidence": [
    "GET /v1/facturas/3812 devolvió el objeto de otro usuario",
    "Acceso exitoso con sesión de bajo privilegio",
    "La respuesta contenía un account_id incorrecto".
  ],
  "confianza": "media",
  "requires_human_review": true,
  "recommended_next_step": "Replay with fresh session and negative control"
}

El segundo principio es la clasificación de las acciones. La guía actual de OpenAI recomienda clasificar las herramientas por características de riesgo como el acceso de sólo lectura frente al de escritura, la reversibilidad, los permisos y el impacto financiero. Esto es directamente aplicable a los sistemas de pentesting. La enumeración contra un objetivo permitido puede ser de bajo riesgo. La reproducción de credenciales, las solicitudes de cambio de estado o cualquier cosa que escriba en la infraestructura debería ser de riesgo medio o alto con puertas de aprobación explícitas. Un Pentest GPT que trata todas las herramientas como equivalentes no es lo suficientemente maduro para un uso serio. (OpenAI)

herramientas:
  http_get:
    riesgo: bajo
    auto_execute: true
  http_post_readonly_probe:
    riesgo: medio
    auto_execute: false
    approval_required: analista
  shell_exec:
    riesgo: alto
    auto_execute: false
    approval_required: líder
  browser_login:
    riesgo: alto
    auto_execute: false
    approval_required: plomo

El tercer principio es la disciplina de estado. El proyecto PentestGPT original se inclinó por la modularidad porque la pérdida de contexto no es un defecto cosmético del pentesting. Es la razón por la que los agentes se repiten, pierden cadenas y exageran conclusiones. En los sistemas operativos, el estado debe ser explícito y consultable. El agente debe saber qué activos se han tocado, qué hipótesis se han rechazado, qué credenciales se han utilizado, qué solicitudes han cambiado de estado y qué conclusiones siguen sin verificarse. Si ese estado no puede sobrevivir a un reinicio o ser inspeccionado independientemente de la transcripción del modelo, el sistema irá a la deriva bajo presión. (arXiv)

El cuarto principio es la exposición controlada a datos no fiables. La descripción que hace el NIST del secuestro de agentes es útil en este caso porque apunta al defecto de diseño que hay detrás del síntoma: el sistema no mantiene las instrucciones de confianza separadas de forma significativa de los datos que no son de confianza. En los sistemas de estilo pentest-gpt, eso significa que los banners de escáner, HTML, contenido de emisión, cuerpos de correo electrónico, registros, documentos recuperados y texto renderizado por el navegador deben ser tratados como no fiables. Una vez que se permite que un modelo interprete esas entradas y llame inmediatamente a herramientas con privilegios significativos, la inyección puntual se convierte en un error del flujo de trabajo, no simplemente en una peculiaridad del modelo. (NIST)

def promover_encontrar(candidato):
    required = ["pasos_reproducción", "control_negativo", "declaración_impacto", "artefactos_brutos"]
    missing = [k for k in required if k not in candidate or not candidate[k]]
    si falta
        return {"estado": "needs_more_evidence", "missing": missing}
    if candidate.get("escribe_estado_objetivo", False):
        return {"estado": "human_review_required"}
    return {"estado": "verified"}

El quinto principio es la revisión humana exactamente en los lugares donde el juicio humano es más fuerte: alcance, límites de privilegios, interpretación del impacto empresarial y la decisión final de clasificar un resultado como verificado. El trabajo de Wiz en 2026 es un recordatorio útil de que los humanos siguen superando a los agentes de IA cuando la tarea requiere pivotes estratégicos en lugar de iteración local. No se trata de una debilidad de los sistemas basados exclusivamente en IA que vaya a desaparecer de la noche a la mañana. Es una característica estructural del panorama actual de herramientas. Los buenos equipos deberían construir en torno a ella en lugar de pretender que la autonomía ya la ha resuelto. (wiz.io)

Por qué sigue siendo importante la participación humana

La expresión "humano en el bucle" se utiliza demasiado, pero en esta categoría sigue siendo acertada. Las pruebas recientes más sólidas no dicen que los agentes de IA sean débiles. Dicen que son desiguales. Pueden automatizar un trabajo ofensivo sustancial en condiciones limitadas, pero siguen necesitando un marco humano para enfrentamientos realistas. Esta distinción es fácil de perder en las demostraciones de productos, en las que el modelo recibe un objetivo claro, un enunciado del problema limitado y un entorno de evaluación indulgente. Los pentests reales no son así. Incluyen un alcance incompleto, una propiedad ambigua, activos ruidosos, objetivos inestables, una lógica de negocio blanda y la necesidad de decidir cuándo... no para continuar. (wiz.io)

Por eso, el mejor uso a corto plazo de Pentest GPT no es "sustituir al comprobador". Es "comprimir el ciclo entre la señal y la prueba". Un buen sistema ayuda al probador humano a llegar más rápido a la bifurcación correcta del árbol, a probar esa bifurcación de forma más sistemática y a documentar el resultado de forma más limpia. Es especialmente eficaz cuando el cuello de botella es la traducción o la coordinación y no la intuición. Es más débil cuando el cuello de botella es el juicio estratégico o el establecimiento de prioridades en condiciones de incertidumbre. Estos límites no deben interpretarse como una decepción. Deben interpretarse como un punto en el que el trabajo de ingeniería aún tiene posibilidades. (arXiv)

En ese sentido, la evolución comercial más interesante de "pentest gpt" no es la capa de chatbot. Es el avance hacia flujos de trabajo basados en pruebas. El posicionamiento público de Penligent apunta claramente a esa brecha. Su página de inicio describe el producto como una herramienta de pruebas de penetración impulsada por IA diseñada para trabajar a partir de instrucciones en lenguaje natural y generar resultados verificados e informes limpios, y su propia redacción distingue entre el proyecto PentestGPT original y la categoría más amplia de productos de pentesting basados en LLM. Esa es la distinción correcta que hay que hacer. El mercado no necesita más sistemas que sólo escriban comandos. Necesita sistemas que cierren el bucle del razonamiento a la evidencia reproducible. (Penligente)

Lo que hace más defendible esa dirección no es simplemente la autonomía. Es la validación productiva. El reciente material de Penligent sobre el pentesting de IA y el red teaming agéntico enmarca la categoría en torno a la ejecución en tiempo de ejecución, la captura de pruebas y la verificación práctica, más que en torno al entusiasmo genérico por la IA. Tanto si se elige esa plataforma como si no, la lección general es correcta: los futuros ganadores en este espacio no serán las demostraciones de "hackers de IA" más ruidosas. Serán los sistemas que hagan que la verificación, la auditabilidad y la calidad de los informes se sientan como algo nativo en el flujo de trabajo y no como algo añadido después. (Penligente)

La norma práctica que deben utilizar los equipos de seguridad

Cuando un equipo de seguridad evalúa una herramienta GPT de Pentest o decide construir una internamente, la lista de comprobación correcta no es "¿Parece inteligente?". La mejor lista de comprobación es más operativa.

¿Preserva un estado duradero a lo largo de todo el ciclo de vida del compromiso? ¿Protege las acciones arriesgadas? ¿Captura las pruebas en bruto antes de redactar las conclusiones? ¿Resiste o al menos contiene la inyección inmediata de contenido no fiable? ¿Expone la capa de herramientas con suficiente claridad para auditar las decisiones? ¿Separa la hipótesis, la validación y el informe final? ¿Mantiene el control humano cuando se trata de privilegios e impacto en el negocio? Si la respuesta a estas preguntas es débil, entonces el sistema puede seguir siendo útil como asistente, pero todavía no es digno de confianza como motor de flujo de trabajo de pentesting. (Desarrolladores de OpenAI)

La lectura más sólida de los dos últimos años de pruebas no es que Pentest GPT sea una exageración, ni que ya haya sustituido a los profesionales. Se trata de que la categoría es real, el valor es real y los modos de fallo son ahora lo suficientemente concretos como para diseñarlos. El trabajo original de PentestGPT demostró que los LLM podían mejorar significativamente el rendimiento de las subtareas en las pruebas de penetración. Las herramientas de agentes modernas demostraron que los modelos pueden llamar cada vez más a las herramientas y funcionar a una escala útil. Los recientes incidentes y CVEs demostraron que una vez que estos sistemas tocan tiempos de ejecución reales, la arquitectura circundante se convierte en la principal historia de seguridad. Si juntamos todo esto, la conclusión es clara: Pentest GPT ya no es un término novedoso. Ahora es un problema de diseño. (arXiv)

Los equipos que más provecho sacarán de ello no son los que persiguen la demostración más autónoma. Son los que construyen el camino más corto y seguro desde la observación hasta el hallazgo verificado. Eso significa un mejor manejo del estado, límites más estrictos de las herramientas, políticas de validación más fuertes y menos tolerancia a la prosa segura sin artefactos. En 2026, esa es la verdadera línea divisoria entre un Pentest GPT que parece impresionante y uno que realmente puede pertenecer a un flujo de trabajo de seguridad serio. (wiz.io)

Para saber más

PentestGPT, Evaluating and Harnessing Large Language Models for Automated Penetration Testing, USENIX Security 2024. (arXiv)

Repositorio GitHub de PentestGPT, posicionamiento actual del proyecto y contexto de lanzamiento. (GitHub)

OpenAI, Guía de llamadas a funciones. (Desarrolladores de OpenAI)

OpenAI, Seguridad en la construcción de agentes. (Desarrolladores de OpenAI)

OpenAI, Guía práctica para la creación de agentes. (OpenAI)

NIST, Strengthening AI Agent Hijacking Evaluations. (NIST)

Top 10 de OWASP para grandes aplicaciones de modelos lingüísticos. (OWASP)

Wiz, AI Agents vs Humans, Who Wins at Web Hacking in 2026. (wiz.io)

NVD, CVE-2025-68664. (NVD)

NVD, CVE-2025-46059. (NVD)

NVD, CVE-2025-3248. (NVD)

NVD, CVE-2025-34291. (NVD)

NVD, CVE-2025-64496. (NVD)

PentestGPT vs. AI Penligente en Compromisos Reales De LLM Escribe Comandos a Hallazgos Verificados. (Penligente)

The 2026 Ultimate Guide to AI Penetration Testing, La era del Red Teaming Agentic. (Penligente)

Agentes de IA hackeando en 2026, defendiendo la nueva frontera de ejecución. (Penligente)

Asegurar las aplicaciones de los agentes en la era MCP. (Penligente)