Los limites de un agente de IA no se escriben en el prompt. Se escriben en el modelo de permisos. La regla practica que Meta publico en noviembre de 2025, la Regla de Dos para agentes, sostiene que un agente deberia cumplir como mucho dos de tres propiedades: procesar entrada no confiable, acceder a datos sensibles y cambiar el estado o comunicarse hacia fuera. Un agente que cumple las tres puede convertirse en una herramienta de exfiltracion de datos con un unico fragmento de texto inyectado. Un modelo de permisos que funciona opera en cuatro capas (identidad, herramienta, argumento y presupuesto) y marca de antemano las acciones irreversibles para aprobacion humana.
Por que un prompt no es un control de seguridad
La instruccion mas comun que encontramos en los proyectos que heredamos dice algo asi: no borres clientes, no envies correos sin aprobacion, no expongas informacion interna. Esa frase vive en el prompt del sistema y parece proteccion. No lo es.
Un prompt es una sugerencia estadistica, no un permiso. Compite por la atencion del modelo con cualquier otro texto del contexto, incluido el texto que llego de fuera. En el momento en que el agente lee un correo, una pagina web, un archivo subido por un cliente o el resultado de una herramienta, ese texto ocupa el mismo espacio que tus instrucciones. Esa es toda la idea detras de la inyeccion de prompts, y por eso no puedes salir del problema redactando mejor.
La separacion correcta es sencilla: el prompt define la intencion, el modelo de permisos define la capacidad. Lo que el agente no puede hacer tecnicamente, no lo hara, por muy convincentemente que se le persuada de que deberia.
La Regla de Dos: el marco mas practico publicado hasta ahora
El 1 de noviembre de 2025 Meta publico un marco inusualmente simple para disenar agentes mas seguros. Identifica tres propiedades y sostiene que un agente, dentro de una misma sesion, deberia cumplir como mucho dos de ellas.
| Propiedad | Que significa | Ejemplo tipico |
|---|---|---|
| A. Entrada no confiable | El agente lee contenido que controla otra persona | Correo entrante, formularios, paginas web, documentos subidos |
| B. Acceso a datos sensibles | El agente puede leer datos privados o sistemas internos | CRM, nominas, base de conocimiento interna, buzon de correo |
| C. Cambio de estado o comunicacion externa | El agente puede escribir, enviar o publicar | Enviar correo, llamar a una API externa, actualizar un registro, cobrar |
El peligro vive en la combinacion de las tres. Un agente que lee un correo entrante (A), extrae datos de clientes del CRM (B) y puede enviar correo hacia fuera (C) se convierte en una maquina de exfiltracion en el momento en que alguien le envia un mensaje con una instruccion oculta. El atacante no necesita romper nada: necesita escribir texto.
La propia Meta subraya que la regla no es una linea de meta. No protege contra los errores del agente, contra inyecciones que solo producen desinformacion en la respuesta, ni contra permisos demasiado amplios dentro de los dos ejes que conservaste. Es una herramienta para reducir el peor escenario, no un sustituto de la defensa en profundidad.
Como romper la combinacion en la practica
En la mayoria de los casos no tienes que renunciar a la capacidad: tienes que repartirla entre dos agentes o dos etapas. Estos son los tres patrones que funcionan.
| Patron | Que se separa | Cuando usarlo |
|---|---|---|
| Lector y ejecutor | Un agente lee la entrada no confiable y devuelve solo un resumen estructurado; un segundo agente actua sobre ese resumen contra los sistemas reales | Procesamiento de correo, formularios, documentos de clientes |
| Firma humana | El agente cumple las tres propiedades pero la accion C pasa por aprobacion humana | Cuando el proceso realmente no se puede dividir |
| Canal de salida cerrado | El agente solo puede escribir a destinos de una lista blanca fija | Informes internos, actualizacion de registros, generacion de borradores |
El segundo patron es el mas comun, y tambien el que se degrada: una aprobacion que se convierte en reflejo deja de ser un control.
Un modelo de permisos en cuatro capas
El permiso de un agente no es una cuestion binaria de acceso a sistemas. Se construye en cuatro capas, y cada capa que te saltas abre una clase entera de fallos.
| Capa | La pregunta que responde | Que pasa cuando falta |
|---|---|---|
| Identidad | En nombre de quien actua el agente | Acciones atribuidas a una cuenta de servicio anonima; sin rastro de auditoria ni reconstruccion posible |
| Herramienta | Que acciones existen siquiera para el | El agente descubre capacidades que nunca se disenaron para el, como borrar a traves de una herramienta generica de actualizacion |
| Argumento | Sobre que puede ejecutar esa accion | Herramienta correcta, alcance equivocado: una actualizacion aplicada a todos los registros en lugar de a uno |
| Presupuesto | Cuanto, a que velocidad y hasta cuando | Un bucle que ejecuta cientos de pasos o miles de llamadas antes de que nadie se de cuenta |
La capa de argumentos es la que mas a menudo se olvida, y la que causa la mayor parte del dano real. Un agente con permiso para actualizar el estado de un pedido sin limite de alcance puede actualizar todos los pedidos. La regla es simple: toda herramienta de escritura valida sus argumentos en el servidor, no en las instrucciones al modelo.
Inyeccion de prompts y mal uso de herramientas: lo que ya ha ocurrido
En diciembre de 2025 OWASP publico su Top 10 de riesgos para aplicaciones agenticas. El riesgo etiquetado como ASI02, mal uso y explotacion de herramientas, describe exactamente el caso en el que un agente usa de forma destructiva una herramienta autorizada, y la mitigacion que recomienda son permisos granulares y validacion estricta de argumentos antes de ejecutar. No es una recomendacion teorica.
Un ejemplo concreto: la CVE-2025-59528 en Flowise, una plataforma de bajo codigo para construir aplicaciones agenticas, se origino en el tratamiento inseguro de los datos de configuracion de CustomMCP y permitia inyectar y ejecutar JavaScript arbitrario. La vulnerabilidad no estaba en el modelo. Estaba en la capa entre el modelo y las herramientas, precisamente el lugar que la mayoria de los equipos trata como fontaneria.
La propia especificacion va en la misma direccion: la revision estable de Model Context Protocol del 28 de julio de 2026 enumera el refuerzo de la autorizacion como uno de sus cambios principales, junto al paso a un protocolo sin estado. Quien construye hoy una capa de herramientas parte de una linea base mejor que hace un ano, pero la linea base no sustituye a tus propias decisiones.
Lo que un agente nunca hace solo
La siguiente lista es independiente del sector. Son acciones donde el coste de un error supera el coste de la friccion.
Mover dinero. Cobrar, abonar, reembolsar, cambiar condiciones de pago.
Comunicar hacia fuera en nombre de la empresa. Correo a clientes, mensajes, publicaciones: redactar si, enviar no.
Borrar o cualquier accion irreversible. Todo lo que no tenga boton de deshacer.
Cambiar permisos. Un agente que puede ampliar sus propios permisos no es un agente, es un agujero.
Actuar con alcance amplio. Actualizaciones masivas, exportaciones de bases de datos, cambios de configuracion del sistema.
Decisiones con consecuencia legal o regulatoria. Denegar una reclamacion, clasificar a un empleado, cotizar un precio vinculante.
Como se ve cuando esta bien hecho
Un buen modelo de permisos es aburrido. Parece una tabla: cada herramienta tiene un responsable, un nivel de riesgo, un rango de argumentos permitido, un techo diario de llamadas y una marca de si requiere aprobacion. Esa tabla se escribe antes del primer prompt y se revisa en cada cambio.
Tres pruebas que vale la pena ejecutar sobre cualquier agente antes de produccion: intentar inyectar una instruccion por cada canal de entrada no confiable y confirmar que nunca llega a una herramienta de escritura; ejecutar cada herramienta de escritura con un argumento fuera de rango y confirmar que se rechaza en el servidor; y ejecutar el agente contra un objetivo imposible y confirmar que se detiene en el techo de presupuesto en lugar de continuar.
Preguntas frecuentes
Que es la Regla de Dos de Meta?
Un marco de seguridad publicado por Meta en noviembre de 2025 que sostiene que un agente, dentro de una misma sesion, deberia cumplir como mucho dos de tres propiedades: procesar entrada no confiable, acceder a datos sensibles y poder cambiar el estado o comunicarse hacia fuera. Combinar las tres convierte una sola inyeccion de prompt en una fuga de datos.
Se puede prevenir por completo la inyeccion de prompts?
No con los metodos disponibles hoy. Cualquier texto que entra en el contexto compite por la atencion del modelo, incluido el que viene de fuentes externas. La defensa, por tanto, no es la prevencion sino la limitacion del dano: permisos minimos, separacion entre leer la entrada y ejecutar acciones, y aprobacion humana para los pasos irreversibles.
Cual es la diferencia entre permisos de usuario y permisos de agente?
Los permisos de usuario se comprueban una vez al iniciar sesion y asumen criterio humano durante toda la sesion. Los permisos de un agente deben comprobarse en cada llamada, a nivel de herramienta y a nivel de argumento, porque no hay criterio humano entre pasos. En la practica eso significa validacion en el servidor y no confianza en las instrucciones al modelo.
Como se restringe a un agente sin volverlo inutil?
Dividiendo en lugar de bloqueando. Un agente lector que devuelve un resumen estructurado, mas un agente ejecutor que actua unicamente sobre ese resumen, conserva toda la capacidad de negocio y elimina la combinacion peligrosa. Donde dividir es imposible, se anade un punto de aprobacion solo en la accion de salida.
Quien deberia ser el responsable del modelo de permisos?
Quien asume las consecuencias si sale una accion equivocada: normalmente el responsable del proceso de negocio, no el equipo de desarrollo. El equipo tecnico lo implementa, pero decidir que acciones son irreversibles y cuales requieren aprobacion es una decision de negocio.