Inyección de prompts y la tríada letal: cómo proteger a los agentes de IA.
Inyección de comandos y la tríada letal: por qué los agentes de IA no pueden distinguir entre sus instrucciones y las de un atacante, cómo funcionaron los ataques EchoLeak y GitHub MCP.
Fuentes: Prompt Injection and Agent Security: The Unsolved Problem
En junio de 2025, los investigadores revelaron una falla en Microsoft 365 Copilot y la denominaron EchoLeak. El ataque se desarrollaba de la siguiente manera: alguien le envía un correo electrónico de aspecto normal. Usted no lo abre, no hace clic en nada ni siquiera lo lee. Copilot lo lee de todos modos, ya que examina toda su bandeja de entrada para responder a sus preguntas. Ocultas en ese correo había instrucciones que indicaban a Copilot que recopilara datos sensibles de sus otros documentos y los enviara silenciosamente a un servidor externo a través de una imagen que se carga automáticamente. Sin necesidad de hacer clic alguno, y la víctima no hace nada incorrecto. El agente obedece, pero no a la persona adecuada.
EchoLeak recibió un CVE (CVE-2025-32711), se corrigió el problema y dejó de funcionar, convirtiéndose en el primer caso conocido de inyección de prompts utilizada para robar datos reales en un sistema de IA en producción. No será el último. Al año siguiente, la misma clase de ataque apareció en la integración MCP de GitHub, Duo de GitLab, la IA de Slack, NotebookLM de Google y en todos los navegadores de IA lanzados. A finales de 2025, los propios responsables de seguridad de OpenAI declararon públicamente que la inyección de prompts podría no resolverse nunca por completo en los agentes de navegador, y el Centro Nacional de Ciberseguridad del Reino Unido estuvo de acuerdo.
El hecho fundamental de seguridad en la IA agente es sencillo y aún carecemos de una respuesta clara al respecto: el modelo recibe sus instrucciones y las de un atacante a través del mismo canal, y no puede distinguirlas de manera fiable. A continuación: por qué eso es cierto, por qué afecta a los agentes mucho más que a los chatbots, y qué medidas de defensa son efectivas, en contraste con las que se presentan en las diapositivas de los proveedores.
Un solo canal para todo
El mecanismo es lo primero, porque una interpretación errónea de él es donde comienza una orientación de seguridad deficiente.
Un modelo de lenguaje recibe una sola entrada: una larga secuencia de tokens. La instrucción del sistema forma parte de ella. La pregunta del usuario también son tokens. Lo mismo ocurre con la página web que el agente acaba de descargar, el correo electrónico que ha leído, la salida de la herramienta que ha recibido, el PDF analizado y el texto alternativo de una imagen. Todo llega como una única secuencia plana, y el modelo predice qué vendrá a continuación. No hay nada que indique si algunos tokens son comandos confiables del operador y otros son datos no confiables a analizar. Simon Willison, quien acuñó el término inyección de instrucciones en 2022, lo describe de esta manera: los modelos seguirán gustosamente cualquier instrucción que reciban, ya provenga del operador o de cualquier otro lugar.
Este es el núcleo del problema, y es muy profundo. Ninguna actualización del modelo podrá solucionarlo, ya que la debilidad está integrada en el diseño mismo. Estos sistemas fueron creados para seguir instrucciones formuladas en lenguaje sencillo. Luego les entregamos texto en lenguaje sencillo extraído de Internet y fingimos sorpresa cuando se ejecutan las órdenes implícitas. La inyección no es más que el cumplimiento de instrucciones por parte de un sistema que obedece a un jefe equivocado.
Compare la inyección SQL, que le dio su nombre al ataque. Existe una solución real para la inyección SQL en las consultas parametrizadas, donde se indica de manera inequívoca a la base de datos que esta parte es un comando y esta otra es datos, y que nunca deben tratarse como un comando. Tres décadas de seguridad en la web dependen de trazar esa línea dentro de la máquina. Dentro de un LLM, nadie sabe cómo hacerlo. Todo ocurre a través del mismo canal, y el canal de comandos y el canal de datos son uno solo. Por eso falla el reflejo común de indicarle al modelo en el prompt del sistema que ignore las instrucciones encontradas en el contenido web. Estás utilizando el canal comprometido para defender el canal comprometido, y un contenido bien elaborado siempre puede superar una advertencia en idioma inglés.
Hay dos tipos de ataques que a menudo se confunden. En la inyección directa, el propio usuario escribe algo hostil, como una solicitud para revelar el mensaje del sistema. Esto se asemeja más a un jailbreak: una persona que ataca a un agente al que tiene permiso para utilizar. La inyección indirecta es la que pone en peligro a los agentes. La instrucción hostil se oculta en material externo que el agente procesa durante su trabajo, como una página web, un correo electrónico, una invitación de calendario, un comentario de código o un problema en GitHub. El atacante nunca se dirige al agente; simplemente deja una trampa en contenido que espera que este lea algún día en nombre de una víctima que confía en él. Todos los incidentes mencionados anteriormente fueron de este tipo. Este método es escalable porque el atacante no necesita acceso a usted, solo cierta influencia sobre lo que decida utilizar como objetivo para su agente.
La tríada letal
El modelo mental más útil aquí es la “trifecta letal” de Simon Willison, que explica por qué algunos agentes son extremadamente vulnerables a la explotación mientras que otros solo resultan irritantes de atacar.
Un agente se convierte en un arma para el robo de datos cuando combina tres capacidades.
- Acceso a datos privados. Puede leer su correo electrónico, repositorios privados, registros de clientes o wikis internos. Por lo general, esa es la razón de su existencia, por lo que no se puede simplemente eliminarlo.
- Exposición a contenido no confiable. Procesa texto que no escribió y que usted no ha verificado: páginas web, correos electrónicos entrantes, documentos, resultados de sistemas de terceros. De nuevo, suele ser ese el objetivo.
- Una forma de comunicarse con el exterior. Puede enviar datos a un lugar donde un atacante pueda verlos, ya sea realizando una solicitud HTTP, enviando un correo electrónico, llamando a una API, renderizando una imagen desde la URL de un atacante o abriendo una solicitud de integración.
Cualquiera de estos es aceptable, y normalmente dos de ellos son suficientes para sobrevivir. Tener los tres en un mismo agente con un único conjunto de credenciales es como tener un arma cargada apuntando a tus datos. Un atacante que controle la segunda capacidad puede secuestrar las instrucciones del agente, utilizar la primera para recopilar secretos y la tercera para enviarlos. Esa es exactamente la secuencia que siguieron los ataques EchoLeak y GitHub MCP.
El caso de GitHub es lo suficientemente claro como para analizarlo en detalle. Invariant Labs lo demostró en mayo de 2025. Un desarrollador conecta un agente de programación al servidor oficial MCP de GitHub mediante un token de acceso personal, uno que, según lo configuran la mayoría de las personas, cubre todos sus repositorios, tanto públicos como privados. El desarrollador solicita algo inofensivo, como revisar los problemas abiertos en un repositorio público. El agente los lee; uno de ellos fue presentado por un atacante y contenía instrucciones ocultas: leer los repositorios privados de ese usuario y publicar lo encontrado en una solicitud de integración pública. El agente cuenta con la segunda capacidad (solo lee el contenido del atacante), la primera (el token permite acceder a repositorios privados) y la tercera (puede crear una solicitud de integración pública). Lo hace todo. En la demostración, el código privado e incluso la información de pago personal quedaron visibles para cualquiera. Toda acción que realizó el token estuvo dentro de sus permisos, y el agente funcionó exactamente como fue diseñado. La tríada simplemente se cerró.
Miren la solución. La medida de mitigación de Docker no intentó detectar el problema malicioso. Rompió la tríada debido a la política establecida: cada sesión está vinculada a un único repositorio, por lo que en cuanto el agente intenta acceder a otro, se bloquea sin importar lo que indiquen las instrucciones. El modelo no se volvió más inteligente. Se eliminó una capacidad en el punto donde estas se combinan, y esa es la estructura de toda defensa real.
Por qué los agentes son mucho peores que los chatbots
Las preocupaciones iniciales sobre la seguridad de los LLM hicieron que la inyección pareciera algo tolerable. Un chatbot decía algo grosero o filtraba su prompt. Era molesto, pero no desastroso. Los agentes, en cambio, elevan el riesgo en todas direcciones.
Los chatbots generan texto, mientras que los agentes realizan acciones. Si se secuestra un chatbot, una sola persona puede leer una respuesta diferente. Pero si se secuestra un agente, este mismo actúa de forma distinta, con capacidades reales: puede enviar correos electrónicos, transferir fondos, borrar registros, fusionar código o ejecutar comandos de shell. La lista de los diez problemas más graves de 2026 del proyecto OWASP Agentic Security parece ser precisamente una lista de estos resultados: secuestro de objetivos, uso indebido de herramientas, abuso de privilegios, envenenamiento de memoria y fallos que se propagan en configuraciones con múltiples agentes. Cada uno de ellos es una forma de inyección agravada por la conexión del modelo con capacidades reales.
Tres factores explican esta exposición.
La superficie de ataque abarca todo lo que lee el agente. En un agente real, la instrucción del operador representa solo una pequeña parte de los tokens, y el 70 % o más del contexto suele estar formado por resultados de herramientas y contenido recuperado. Esta distribución desequilibrada también constituye un problema de seguridad. La mayor parte de lo que procesa el modelo al tomar decisiones proviene del exterior, y cualquier token de ese contenido podría ser una instrucción. Tu instrucción de confianza es solo un error de redondeo frente a una avalancha de entradas no confiables.
La autonomía elimina los obstáculos causados por la lentitud humana. El valor de un agente radica en su capacidad para ejecutar ciclos sin solicitar permiso en cada paso, pero cada paso no supervisado es una oportunidad para que se ejecute una instrucción inyectada sin que nadie la detenga. Cuanto más autónomo e impresionante sea el agente, más amplia se vuelve esa ventana de posibilidades. La capacidad y la posibilidad de inyección crecen juntas, lo que significa que, manteniendo todo constante, cuanto más potente sea el agente, más costoso resultará perderlo ante un atacante.
La persistencia y el encadenamiento añaden más problemas. Los agentes tienen memoria, y esa memoria puede ser manipulada: un atacante introduce un “hecho” falso en el almacenamiento a largo plazo el lunes, lo que distorsiona las decisiones durante semanas. Los agentes se comunican entre sí, por lo que una inyección en los datos de un subagente se propaga a lo largo de toda la cadena sin que nadie supervise el proceso completo. Además, navegadores basados en agentes como Atlas y Comet colocan un agente injetable en la pestaña donde uno está conectado a su banco, su correo electrónico y la consola de administración de su empresa al mismo tiempo. Los investigadores ya han engañado a Atlas con texto malicioso disfrazado de URL y con contenido que implanta recuerdos falsos. La respuesta de OpenAI merece reconocimiento por su honestidad: ha reforzado el producto mediante entrenamiento adversarial y pruebas automatizadas, y ha informado claramente a los usuarios de que el problema aún no está completamente resuelto.
Defensas que ayudan
Sinceramente, nadie sabe cómo hacer que un modelo resista las inyecciones el 100% del tiempo. Cada medida de defensa que existe reduce el riesgo, pero ninguna lo elimina por completo. La verdadera seguridad proviene de combinar capas imperfectas y, sobre todo, de diseñar el sistema de tal manera que una inyección exitosa no pueda acceder a nada valioso. A continuación se presentan las medidas de defensa reales, separadas de las ilusiones reconfortantes.
Primero, rompa con la trifecta. Rinde más que cualquier otra cosa aquí y no requiere aprendizaje automático. Para cada agente, verifique si posee las tres capacidades al mismo tiempo y, de ser así, si se puede eliminar una de ellas en ese contexto. Un agente que lee páginas web no confiables no debería tener también credenciales de bases de datos de producción. Un agente que accede a datos privados debe tener su comunicación saliente limitada a una lista de permisos tan estricta que no quede espacio para enviar secretos. La solución de GitHub de usar un repositorio por sesión es una forma de romper con la trifecta. Funciona porque se basa en la arquitectura y no en probabilidades.
Utilice un diseño que mantenga al planificador alejado de entradas peligrosas. La investigación más prometedora considera las inyecciones como una cuestión relacionada con el flujo de datos y no con si es posible detectarlas. El patrón Dual LLM y CaMeL, su versión más estricta (“Derrotar las inyecciones de prompts mediante el diseño”, 2025), dividen al agente en dos roles. Un modelo con privilegios lee su solicitud y planifica los pasos a seguir, pero nunca ve material no confiable. Un modelo en cuarentena lee el material no confiable, ya sea un correo electrónico o una página web, pero carece de herramientas y no puede actuar. CaMeL va aún más allá: el plan del modelo con privilegios se compila en un programa restringido, y un intérprete personalizado sigue el origen de cada valor. Todo lo que proviene de una fuente no confiable recibe esa etiqueta y no puede llevar a cabo acciones peligrosas a menos que así lo indique una política. Eso se acerca más a las consultas parametrizadas para los LLM, un límite entre comandos y datos que de hecho se aplica. Hay un costo: alguien tiene que redactar las políticas, y los interminables mensajes de aprobación pueden hacer que los usuarios presionen “sí” por reflejo. Aun así, se basa en principios, y los principios resisten ante un atacante decidido.
Restrinja las acciones mediante una escalera de permisos. Clasifique cada acción según el daño que podría causar, y deje que el sistema de control, no la instrucción, aplique esa clasificación. La lectura se realiza en silencio; todo lo reversible se registra, aquello difícil de revertir (enviar, eliminar, pagar, fusionar) necesita confirmación humana que muestre exactamente qué va a ocurrir, y las acciones irreversibles y costosas se bloquean o se dirigen a un proceso de aprobación del que el modelo no puede influir. Una instrucción es una sugerencia con la que un atacante puede discutir, mientras que una regla del sistema de control es un obstáculo que no puede superar. Pedirle al modelo que siempre pregunte antes de enviar dinero vale la pena, pero por sí solo no sirve de nada. Hacer que el código de pago requiera un token que el modelo nunca posee constituye una medida de seguridad.
Aplicar el principio de menor privilegio con credenciales con alcance limitado. La inyección solo puede causar daños en proporción a lo que se permite hacer al agente, por lo que se debe otorgar a cada agente el alcance más restringido, un token de vida más corta y la menor cantidad de herramientas necesarias para cumplir su función. El incidente en GitHub se debió a que un token con amplios derechos se comportó como tales, y el uso de un alcance OAuth específico por repositorio lo habría evitado. Se trata de medidas básicas y aburridas de seguridad, pero son más efectivas que cualquier truco ingenioso.
Añada la detección, pero no dependa de ella. Los equipos recurren primero a esta capa, cuando en realidad debería ser la última. Los clasificadores de inyección son modelos entrenados para reconocer frases como “ignorar instrucciones anteriores” y sus innumerables variantes, y logran detectar una gran cantidad de ataques. Los clasificadores para uso informático de Anthropic, el filtro XPIA de Microsoft y muchas startups trabajan en este ámbito. Úselos, ya que hacen que los ataques cuesten más. Solo tenga claro qué ofrecen. Un clasificador que bloquea el 99 % de los intentos suena excelente, pero desde el punto de vista de la seguridad se considera un fracaso, porque la inyección no es ruido aleatorio. El atacante puede intentarlo una y otra vez hasta adaptarse a su filtro. El primer paso en EchoLeak fue un correo electrónico diseñado para pasar por el clasificador de inyección de Microsoft, y lo logró. Frente a un atacante que se adapta, una tasa de fugas del 1 % representa un obstáculo significativo. Mantenga la detección como una capa adicional, nunca como la base de su seguridad.
Recuerde todo. Cada llamada a una herramienta, cada documento recuperado y cada acción realizada deben registrarse y poder atribuirse. En términos de seguridad, eso constituye su capa de detección e investigación forense. Después de los hechos, desea saber qué leyó el agente justo antes del comportamiento anómalo y de dónde provinieron las instrucciones, además de querer recibir alertas de anomalías cuando de repente accede a recursos fuera de su patrón habitual. No puede defenderse, ni siquiera comprender, un ataque que no puede ver. Un agente que no es observable no solo es difícil de depurar, sino que representa una brecha de seguridad de la cual solo tendrá conocimiento a través de otra persona.
Tres incidentes para estudiar
Los patrones se mantienen cuando están vinculados a eventos reales. Estos tres, correspondientes a aproximadamente dieciocho meses, muestran diferentes niveles de gravedad del problema.
EchoLeak (Microsoft 365 Copilot, CVE-2025-32711). Lo que destaca es la ausencia de cualquier clic, más que cualquier truco. Descubierto en enero de 2025, corregido en mayo y hecho público en junio, fue la primera inyección de comando que extrajo datos reales de un sistema de IA en producción sin que el usuario realizara ninguna acción. Consistió en cuatro estrategias de evasión: un correo electrónico diseñado para superar el clasificador XPIA, enlaces en Markdown de estilo de referencia que eludieron la censura de enlaces, una etiqueta de imagen que se cargaba por sí sola y enviaba una solicitud externa, y una API de previsualización de Teams en la lista blanca que actuaba como relé para que los datos salieran por una vía aprobada. Cada medida que tenía Microsoft era sensata por separado. El atacante encontró las brechas entre ellas. Una serie de capas de detección también representa una serie de brechas, y un adversario paciente explora todas ellas.
El robo en GitHub MCP (Invariant Labs, mayo de 2025). Ya se trataba anteriormente, pero vale la pena reiterar la conclusión: nada falló. Ninguna credencial falló y el modelo permaneció intacto. Un token de acceso amplio, un agente que leía los problemas escritos por un atacante y la capacidad de abrir una PR pública juntos constituyeron la vulnerabilidad. No había código de explotación ni error de memoria que corregir, solo tres capacidades que nunca deberían haber compartido una sesión. Eso es lo que hace de la seguridad de los agentes una nueva disciplina. El defecto radica en cómo se combinan las partes, no en alguna parte en particular.
Los navegadores con agente (Atlas y Comet, finales de 2025). Tan pronto como se lanzaron ChatGPT Atlas y Comet de Perplexity, los investigadores demostraron de inmediato inyecciones en el omnibox, donde texto disfrazado de dirección web se ejecutaba como instrucción, así como ataques a la memoria que dejaban un contexto falso de una sesión a otra. La coubicación es lo que hace que este caso sea especialmente grave. El agente injetable reside en el lugar donde estás autenticado simultáneamente en tu banco, correo electrónico y consolas de administración, la combinación ideal en el lugar de mayor riesgo. La reacción de OpenAI estableció un tono honesto en la industria mediante entrenamiento adversarial, equipos de pruebas automatizados y un reconocimiento abierto de que este problema aún no se ha resuelto. Confía en sus palabras y diseña como si tu agente del navegador eventualmente fuera engañado.
Qué evaluar, por capas
Piensa en capas y elige algo para cada una.
- Defensas basadas en patrones de diseño: CaMeL y el patrón Dual LLM. Estos separan la planificación de los datos no confiables y rastrean el origen de los mismos, lo que brinda las garantías más sólidas.
- Clasificadores de inyección: Los clasificadores de Anthropic, Microsoft XPIA, Lakera Guard, PromptArmor y protectai/rebuff. Estos detectan contenido adversarial en entradas no confiables, aumentando los costos sin crear una barrera total.
- Gateways y aplicación de políticas: Los interceptores Docker MCP Gateway, Invariant Guardrails y las listas de permisos de salida. Estos rompen el triángulo de amenazas mediante políticas que delimitan las sesiones, bloquean el acceso entre recursos y limitan el tráfico saliente.
- Herramientas y pruebas de equipo rojo: AgentDojo, AgentDyn, BIPIA, CyberSecEval y deepteam, que permiten que las pruebas de inyección sean repetibles y medibles.
Una regla que evita problemas: no compre un solo producto y piense que está protegido. Cada uno de los elementos mencionados anteriormente representa una capa, y lo importante aquí es que ninguna capa por sí sola es suficiente. Una postura sólida combina defensas basadas en patrones de diseño, credenciales con alcance definido, una estructura de permisos, un clasificador y un seguimiento completo, seleccionados de tal manera que, incluso si se supera una de ellas, el atacante seguirá enfrentándose a las siguientes.
Modos de fallo en entornos reales
- La cadena de exfiltración. El contenido no fiable indica al agente que recoja datos privados y los envíe, como ocurre en EchoLeak y GitHub MCP. Para contrarrestarlo, hay que romper este proceso mediante listas de permisos de salida, el seguimiento del flujo de datos (CaMeL) y la limitación de las credenciales.
- El agente confundido. El contenido inyectado hace que el agente realice una acción que cambia el estado y que el usuario nunca solicitó, como enviar un correo electrónico, eliminar un archivo o aprobar una transacción. Se puede detener esto mediante una estructura de permisos en niveles, que exige la aprobación de una persona para cualquier acción significativa, con la regla establecida en el sistema.
- El acceso sin clic. No se necesita interacción del usuario, ya que el desencadenante es la lectura en segundo plano habitual del agente, como ocurre con la carga automática de imágenes en EchoLeak. Es necesario restringir la obtención automática y el procesamiento externo, controlar las salidas de datos y considerar todo lo consumido de forma pasiva como algo hostil.
Un pase de seguridad de una semana
Se trata de algo sencillo, concreto y aplicable a un agente que ya posee.
Día 1: mapee el trío completo de medidas de seguridad. Tome cada agente que utilice y anote qué datos privados puede acceder, qué contenido no confiable ingiere y cómo puede enviar información hacia el exterior. Cualquier agente que cuente con las tres características se coloca al principio de la lista. Ese inventario será el documento de seguridad más valioso que escriba, y basta con una tarde para elaborarlo.
Día 2: elimine al menos un aspecto de cada trifecta. Para cada agente arriesgado, quite una capacidad en esa configuración. Divídalo en dos agentes con funciones más limitadas, reduzca sus credenciales o limite el tráfico saliente a una lista de permisos. No siempre será posible eliminar a los tres, pero quitar solo uno evita semanas de trabajo para reforzar la seguridad.
Día 3: cree la escalera de permisos. Enumere todas las acciones que puede realizar el agente y clasifíquelas según si son silenciosas, registradas, confirmadas o bloqueadas según su radio de impacto. Haga obligatorio el uso de los dos niveles superiores mediante código, fuera del alcance del modelo, y verifique que los mensajes de confirmación muestren lo que realmente ocurrirá.
Día 4: ataque a su propio agente. Prepare diez entradas hostiles, incluyendo una página con trampa, un mensaje, un problema, una invitación, un PDF con texto invisible y una imagen cuyo texto alternativo contiene instrucciones. Ejecute el agente contra cada una de ellas en un entorno aislado y observe qué sucede. Algo funcionará, y descubrirlo usted mismo es mejor que que lo haga otra persona. Un estándar como AgentDojo permite que este ejercicio sea reproducible.
Día 5: agregue mecanismos de detección y mantenga las expectativas realistas. Coloque un clasificador de inyecciones frente a las entradas no confiables y registre qué elementos marca como sospechosos. Se trata de una alarma que aumenta los costos para el atacante, no de una barrera real. Envíe sus resultados al sistema de seguimiento que activará el día 6.
Día 6: active el seguimiento con fines de seguridad. Asegúrese de que cada llamada a una herramienta, recuperación de datos y acción realizada quede registrada con un propietario claro, y establezca una alerta para los accesos a recursos que se salgan de los patrones normales. Si ya existe el seguimiento, lo que está haciendo es cambiar la configuración, no iniciar un proyecto.
Día 7: anote todo y vuelva a probar después de cada cambio. La resistencia a inyecciones no es un hito que se supera, sino una propiedad que se mantiene. Cada herramienta, fuente de datos o capacidad nueva puede volver a activar la combinación de vulnerabilidades que ya había resuelto, por lo que añada la pregunta “¿Esto vuelve a activar esa combinación?” a la lista de verificación y vuelva a ejecutar los ataques del día cuatro siempre que la respuesta sea afirmativa.
Fin sin solución definitiva
La inyección de comandos aún no se ha resuelto, y es posible que no sea posible solucionarla de la misma manera que se resolvió la inyección SQL, porque la característica que hace que estos modelos sean útiles, al seguir instrucciones en lenguaje común, es precisamente la que los hace susceptibles de ser explotados, y nadie sabe cómo mantener una sin la otra. Las personas que desarrollan navegadores de vanguardia han comenzado a decirlo abiertamente, lo cual representa el avance más alentador hasta ahora: la industria ha dejado de fingir que un modelo más inteligente hará desaparecer el problema.
Estar esperando una solución no es un plan. El plan consiste en que los agentes permanezcan seguros incluso después de que el modelo sea engañado, porque eso ocurrirá en algún momento. Eso redirige los esfuerzos de ingeniería: lejos de prompts del sistema más astutos que pidan precaución, hacia la estructura que rodea al modelo. Rompa esa combinación letal, mantenga la planificación separada de los datos no confiables, limite al máximo cada credencial, coloque cada acción importante detrás de una barrera que el modelo no pueda superar con palabras y observe todo. Todo eso está en el sistema de control y nada de ello en el modelo.
El modelo es un componente capaz, confiado y susceptible de ser manipulado, y el sistema de control es la forma en que se utiliza de manera segura. Si hace del modelo su límite de seguridad, sufrirá brechas. Si coloca ese límite fuera de él, bajo su control, tendrá una oportunidad.
Leer más
- DS-STAR explicado: el agente de ciencia de datos de Google y por qué su enfoque funciona — Una explicación detallada del agente de ciencia de datos DS-STAR de Google: sus siete módulos, el ciclo de informes DS-STAR+, los prompts publicados, los resultados de las pruebas de eliminación y las limitaciones actuales.
- Notas prácticas: Estoy ejecutando un agente de programación AI localmente y su rendimiento es casi el doble — Guía paso a paso de las Notas prácticas: Estoy ejecutando un agente de programación AI localmente y su rendimiento es casi el doble: contratos, verificaciones y espacios para código listo para usar para los equipos que implementan este modelo.