Tres vulnerabilidades con la puntuación máxima de 10/10 en ServiceNow exponen el «efecto de amplificación» de los agentes de IA con acceso amplio — el argumento estructural que AppH extrae de su propia puerta de aprobación humana
El 28 de agosto de 2026, Forkast.News detalló tres vulnerabilidades calificadas con CVSS 10.0 — la puntuación máxima — en la capa de orquestación de agentes de IA de la plataforma ServiceNow: un fallo de inyección de código en un sistema que guarda el contexto de sesión, las credenciales y la configuración de herramientas que los agentes usan para actuar en nombre de los usuarios. AppH no comparte ni la arquitectura ni la superficie de ataque de ServiceNow — pero el artículo nombra con precisión el riesgo que la puerta de aprobación humana de AppH existe para bloquear: un agente con acceso amplio que puede leer, escribir y ejecutar sin que intervenga un humano.
El 28 de agosto de 2026, Forkast.News publicó un análisis que detalla tres vulnerabilidades calificadas con CVSS 10.0 — la puntuación máxima en la escala de gravedad de fallos de software — descubiertas en la capa de orquestación de agentes de IA de la plataforma ServiceNow. Las fallas permiten inyección de código en un sistema que aloja el contexto de sesión, las credenciales y la configuración de herramientas que los agentes de IA usan para actuar en nombre de los usuarios de la empresa. El artículo nombra explícitamente lo que llama «efecto de amplificación de agentes» (agent amplification effect): agentes con acceso amplio —leer y escribir registros, disparar workflows, escalar tickets, ejecutar scripts— convierten un fallo ordinario de inyección de código en un incidente de mucho mayor alcance, porque el agente comprometido hereda todos los privilegios que se le dieron.
AppH no es ServiceNow y no comparte ni su arquitectura ni su superficie de ataque — presentar este incidente como una comparación directa entre ambas plataformas sería impreciso, y no es lo que este artículo afirma. El punto real y legítimo que se puede extraer es estructural, no competitivo: la arquitectura de AppH —un agente delimitado por cuenta y, sobre todo, aprobación humana obligatoria antes de cualquier acción con consecuencia real (enviar un mensaje, cobrar a un cliente, cancelar una reserva)— ya limita precisamente lo que el artículo llama el efecto de amplificación, porque incluso un agente comprometido o que falle no puede ejecutar una acción de negocio real sin pasar por esa puerta de validación humana. No es un eslogan de marketing, es una decisión de arquitectura verificable en cada módulo. Y esto va más allá de AppH: cualquier usuario de una plataforma de orquestación de agentes —AppH incluida— debería verificar periódicamente que ningún endpoint interno combine lectura, escritura y ejecución sin puerta de validación, exactamente el patrón de riesgo que este artículo documenta.
A favor de AppH
- El incidente de ServiceNow le da un nombre preciso y un ejemplo fechado, con la puntuación máxima de gravedad, a un riesgo que AppH describe internamente desde siempre sin haber tenido nunca un caso tan claro que citar: un agente con acceso amplio y sin puerta de validación convierte cualquier fallo, incluso menor, en un incidente a gran escala. Es un argumento concreto para presentar a un cliente que se pregunte por qué AppH exige un clic humano antes de cada acción con consecuencia real en vez de presumir de automatización total.
- La arquitectura de AppH —aprobación humana obligatoria antes de cualquier acción de negocio— responde directamente al patrón de riesgo que nombra el artículo (lectura + escritura + ejecución sin control), sin que ninguna regulación ni ningún incidente haya tenido que imponerlo después: es una garantía estructural integrada desde el diseño, no un parche añadido tras una brecha.
En contra / el límite honesto
- Una puntuación CVSS de 10 sobre 10 mide la gravedad y la facilidad de explotación de un fallo, no la probabilidad de que ocurra realmente en un proveedor concreto, AppH incluida. Presentar este incidente como prueba de que AppH ha sido auditada contra esta clase precisa de vulnerabilidad sería impreciso: es un argumento de gobernanza y arquitectura, no el resultado de una auditoría de seguridad realizada sobre AppH.
- ServiceNow y AppH no operan a la misma escala ni sobre la misma superficie técnica — una plataforma empresarial con miles de integraciones de terceros expone mecánicamente más puntos de entrada que un producto vertical para pymes. Afirmar que ambas plataformas corren exactamente el mismo riesgo ignoraría esa diferencia real de escala.
Lo que llama la atención de este incidente no es la cifra 10 sobre 10 en sí misma —las escalas de gravedad existen precisamente para señalar que un puñado de fallos merece la atención inmediata de todos, no solo de los clientes de ServiceNow—. Lo que llama la atención es que la falla toca exactamente la capa que cualquier plataforma de agentes de IA, AppH incluida, debe tomarse en serio como prioridad: la que decide qué puede hacer un agente y con qué credenciales. Acompañar a un dirigente de pyme en este tema no es decirle que AppH es invulnerable —ninguna plataforma puede afirmarlo honestamente—, es explicarle por qué la pregunta correcta nunca es «¿su IA puede hacerlo todo rápido?» sino «¿qué impide que un agente comprometido o que se equivoque ejecute una acción real sin que un humano la haya visto antes?». En AppH, la respuesta sigue siendo la misma desde el primer módulo: nada se envía, nada se cobra, nada se cancela sin que un humano de la empresa haga clic primero — y recomendamos a cualquiera que evalúe una plataforma de agentes de IA, la nuestra incluida, que compruebe de forma concreta que esa puerta existe antes de confiarle datos reales.
Verificado por un humano de AppH