{"id":782,"date":"2026-03-27T06:00:00","date_gmt":"2026-03-27T05:00:00","guid":{"rendered":"https:\/\/rosmarops.com\/?p=782"},"modified":"2026-10-25T10:18:11","modified_gmt":"2026-10-25T09:18:11","slug":"prompt-injection-y-agentes-el-problema-no-es-el-prompt-es-la-identidad","status":"publish","type":"post","link":"https:\/\/rosmarops.com\/es\/blog\/prompt-injection-y-agentes-el-problema-no-es-el-prompt-es-la-identidad\/","title":{"rendered":"Prompt injection y agentes: el problema no es el prompt, es la identidad"},"content":{"rendered":"\n

En agosto de 2025, investigadores de Persistent Security documentaron una vulnerabilidad en GitHub Copilot que permit\u00eda comprometer por completo la m\u00e1quina de un desarrollador. El mecanismo era deceptivamente sencillo: instrucciones maliciosas incrustadas en un archivo README \u2014texto que el agente procesaba como parte normal de su tarea\u2014 lograban que Copilot modificara su propio archivo de configuraci\u00f3n, habilitara el modo de autoaprobaci\u00f3n y ejecutara comandos arbitrarios sin intervenci\u00f3n del usuario. Sin alerta. Sin fricci\u00f3n visible. La vulnerabilidad, catalogada como CVE-2025-53773<\/a> con una puntuaci\u00f3n CVSS de 7.8, fue parcheada en agosto. Pero el patr\u00f3n que expone no desaparece con el parche.<\/p>\n\n\n\n

Cada semana se documenta una variante nueva. La respuesta convencional sigue siendo la misma: filtrar inputs, sanitizar prompts, entrenar modelos m\u00e1s resistentes. No funciona. No puede funcionar del todo. El NCSC brit\u00e1nico lo formul\u00f3 con precisi\u00f3n en diciembre de 2025: dado que los LLM no distinguen entre instrucciones y datos \u2014solo predicen el siguiente token m\u00e1s probable\u2014 \u00abes muy posible que los ataques de prompt injection nunca lleguen a mitigarse del todo como pueden mitigarse los de SQL injection\u00bb<\/a>. Los modelos son, en ese sentido, inherentemente confundibles<\/em>.<\/p>\n\n\n\n

Pero hay algo m\u00e1s fundamental que la industria sigue eludiendo: el prompt injection no es principalmente un fallo del modelo. Es un fallo del modelo de control de acceso.<\/p>\n\n\n\n

Cuando el agente hereda confianza que no se ha ganado<\/h2>\n\n\n\n

En la seguridad tradicional, nadie concede acceso root permanente a un script sin nombre ni lo autentica con las mismas credenciales que un administrador de sistemas. Con los agentes IA, eso ocurre a diario y casi sin conciencia de que ocurre.<\/p>\n\n\n\n

La mayor\u00eda de implementaciones actuales funcionan con cuentas de servicio compartidas, tokens de larga duraci\u00f3n o credenciales con alcance amplio que la infraestructura ya conf\u00eda. El agente no tiene identidad propia: hereda la de otro. Y al heredarla, hereda tambi\u00e9n todos sus permisos. Cuando un prompt injection consigue manipular la decisi\u00f3n del agente, esa decisi\u00f3n se ejecuta con credenciales v\u00e1lidas. Es una instrucci\u00f3n maliciosa empaquetada en una solicitud leg\u00edtima. El SIEM no alerta. El WAF no bloquea. Todo parece dentro de lo normal, porque t\u00e9cnicamente lo est\u00e1.<\/p>\n\n\n\n

Darle al agente su propia identidad cambia el modelo completo. En lugar de heredar acceso general, el agente se autentica como una entidad espec\u00edfica con controles expl\u00edcitamente definidos para su rol y su contexto. Como explica el Cloud Security Alliance en su an\u00e1lisis sobre gesti\u00f3n<\/a> <\/a>de identidad en sistemas ag\u00e9nticos<\/a>, esto permite vincular cada token de autenticaci\u00f3n a tareas concretas, con metadatos sobre el sistema que solicita, el prop\u00f3sito y las operaciones permitidas \u2014lo que simplifica el an\u00e1lisis forense y crea trazabilidad directa entre permisos y prop\u00f3sito de negocio.<\/p>\n\n\n\n

El problema de los tokens de larga duraci\u00f3n tiene una cara adicional que suele ignorarse: a diferencia de las cuentas humanas, los agentes rara vez disparan anomal\u00edas de comportamiento, porque sus patrones de actividad son inherentemente variables. Un agente que de repente accede a un repositorio que no deber\u00eda tocar puede pasar inadvertido si lo hace a velocidad de m\u00e1quina y dentro de una cadena de herramientas que ya era compleja. La detecci\u00f3n comportamental dise\u00f1ada para humanos no tiene suficiente se\u00f1al para actuar.<\/p>\n\n\n\n

La pregunta correcta no es qu\u00e9, sino cu\u00e1ndo<\/h2>\n\n\n\n

El cambio de paradigma que la industria necesita no es defensivo en el sentido convencional \u2014no se trata de bloquear el input malicioso, que es t\u00e9cnicamente inviable en sistemas de lenguaje natural. Se trata de invalidar su impacto en el punto donde realmente importa: cuando el agente solicita acceso.<\/p>\n\n\n\n

1Password lo articula bien en su an\u00e1lisis sobre controles de ejecuci\u00f3n<\/a>: el prompt injection no elude los controles de acceso, trabaja dentro<\/em> de ellos. El agente tiene permiso. El sistema funciona como fue dise\u00f1ado. El resultado es igualmente incorrecto. Cuando un agente invoca una herramienta, se autentica ante un servicio o intenta realizar una operaci\u00f3n, ese momento necesita ser evaluado. La decisi\u00f3n de acceso no puede tomarse una vez al inicio de la sesi\u00f3n y asumirse v\u00e1lida para todo lo que venga despu\u00e9s.<\/p>\n\n\n\n

Silverfort plantea la distinci\u00f3n con claridad<\/a>: el privilegio m\u00ednimo est\u00e1tico asume comportamiento predecible, y los agentes rompen esa asunci\u00f3n. Razonan. Encadenan herramientas. Derivan de su prop\u00f3sito original. El privilegio m\u00ednimo tiene que validarse en tiempo de ejecuci\u00f3n, no solo fijarse en el aprovisionamiento. Si un agente intenta acceder a un recurso fuera de su alcance declarado, se bloquea. Aqu\u00ed es donde la identidad ag\u00e9ntica \u2014credenciales ef\u00edmeras, permisos de m\u00ednimo privilegio escalonados por contexto, autorizaci\u00f3n din\u00e1mica evaluada contra pol\u00edticas expl\u00edcitas\u2014 cobra sentido pr\u00e1ctico. Incluso si el prompt manipulado logra que el agente \u00abintente\u00bb algo, el sistema de control de acceso puede rechazarlo si est\u00e1 fuera del alcance autorizado. El ataque falla no porque el modelo lo detecte, sino porque la infraestructura no lo ejecuta.<\/p>\n\n\n\n

Lo que el regulador ve y lo que a\u00fan no ve<\/h2>\n\n\n\n

En enero de 2026, el NIST public\u00f3 a trav\u00e9s de su Centro para Est\u00e1ndares e Innovaci\u00f3n en IA (CAISI) una solicitud de informaci\u00f3n sobre seguridad en sistemas ag\u00e9nticos<\/a>, buscando perspectivas de la industria, la academia y la comunidad de seguridad sobre el despliegue seguro de estos sistemas. El documento reconoce que los agentes son susceptibles a ataques como el prompt injection indirecto y que sus vulnerabilidades pueden tener implicaciones para infraestructuras cr\u00edticas.<\/p>\n\n\n\n

Lo importante, sin embargo, es lo que el documento todav\u00eda no da: no propone taxonom\u00edas de riesgo para entornos donde el per\u00edmetro es sem\u00e1ntico, no articula est\u00e1ndares de identidad ag\u00e9ntica, no define arquitecturas de confianza cero adaptadas a sistemas que toman decisiones en lenguaje natural. La respuesta regulatoria est\u00e1, en el mejor de los casos, en fase de escucha activa. Mientras tanto, los agentes ya est\u00e1n despleg\u00e1ndose a escala empresarial con las mismas bases de confianza que se dise\u00f1aron para usuarios humanos.<\/p>\n\n\n\n

Esta brecha no es solo un problema t\u00e9cnico. Es un problema de ritmo: la velocidad de adopci\u00f3n supera la capacidad de los marcos de gobernanza para adaptarse. Y las organizaciones que despliegan agentes sin repensar el control de acceso no est\u00e1n cometiendo un error de implementaci\u00f3n puntual; est\u00e1n construyendo superficie de ataque sobre un modelo de identidad que nunca fue pensado para sistemas aut\u00f3nomos.<\/p>\n\n\n\n

Lo que habr\u00eda que reconstruir<\/h2>\n\n\n\n

El prompt injection<\/a> seguir\u00e1 siendo t\u00e9cnicamente posible mientras los modelos de lenguaje funcionen como funcionan. El NCSC tiene raz\u00f3n en eso. Pero la pregunta relevante no es si el ataque puede ejecutarse, sino si puede producir efectos en sistemas reales. Y eso depende casi por completo de c\u00f3mo se gestione la identidad y la autorizaci\u00f3n del agente.<\/p>\n\n\n\n

Identidad \u00fanica por agente, no credenciales compartidas. Autorizaci\u00f3n evaluada en tiempo de ejecuci\u00f3n, no asumida desde el aprovisionamiento. Credenciales ef\u00edmeras que expiran con la tarea. Trazabilidad de cada acci\u00f3n hasta el dato que influy\u00f3 en ella y la pol\u00edtica que deber\u00eda haberla contenido. No es una lista de buenas pr\u00e1cticas de seguridad gen\u00e9ricas: es la condici\u00f3n necesaria para que la defensa tenga alguna posibilidad de funcionar en entornos donde la superficie de ataque es el lenguaje natural.<\/p>\n\n\n\n

El prompt injection manipulado que no puede producir acci\u00f3n sobre infraestructura real es, en t\u00e9rminos pr\u00e1cticos, ruido. Llegar ah\u00ed requiere repensar el control de acceso desde cero para sistemas no humanos, no entrenar mejores modelos ni a\u00f1adir capas de sanitizaci\u00f3n al input.<\/p>\n","protected":false},"excerpt":{"rendered":"

En agosto de 2025, investigadores de Persistent Security documentaron una vulnerabilidad en GitHub Copilot que permit\u00eda comprometer por completo la m\u00e1quina de un desarrollador. El mecanismo era deceptivamente sencillo: instrucciones maliciosas incrustadas en un archivo README \u2014texto que el agente procesaba como parte normal de su tarea\u2014 lograban que Copilot modificara su propio archivo de … Leer m\u00e1s<\/a><\/p>\n","protected":false},"author":1,"featured_media":785,"comment_status":"closed","ping_status":"closed","sticky":true,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,59,66,68],"tags":[268,270],"class_list":["post-782","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-agentes-autonomia","category-prompt-injection","category-seguridad-de-agentes-ia","category-seguridad-llm","tag-seguridad-de-asistentes-ia","tag-seguridad-llm"],"_links":{"self":[{"href":"https:\/\/rosmarops.com\/es\/wp-json\/wp\/v2\/posts\/782","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rosmarops.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rosmarops.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rosmarops.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rosmarops.com\/es\/wp-json\/wp\/v2\/comments?post=782"}],"version-history":[{"count":1,"href":"https:\/\/rosmarops.com\/es\/wp-json\/wp\/v2\/posts\/782\/revisions"}],"predecessor-version":[{"id":1030,"href":"https:\/\/rosmarops.com\/es\/wp-json\/wp\/v2\/posts\/782\/revisions\/1030"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rosmarops.com\/es\/wp-json\/wp\/v2\/media\/785"}],"wp:attachment":[{"href":"https:\/\/rosmarops.com\/es\/wp-json\/wp\/v2\/media?parent=782"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rosmarops.com\/es\/wp-json\/wp\/v2\/categories?post=782"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rosmarops.com\/es\/wp-json\/wp\/v2\/tags?post=782"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}