Un agente que hace un trabajo útil tiene una credencial. La clave de API, el rol de base de datos, el permiso en la nube, el ámbito de pago. Eso es lo que lo hace útil. Es también todo el problema.
Un agente lee texto y actúa sobre él. Ese es el diseño, no un fallo del modelo de un proveedor. Así que cualquiera que consiga poner texto delante de tu agente actúa con la credencial de tu agente. Un ticket de soporte. Un PDF de factura. Una página que consulta. El README de una dependencia que el agente resume. El atacante nunca necesita tu clave. Necesita que tu agente lea una frase.
La velocidad elimina la segunda línea de defensa. Una persona engañada toma una sola decisión equivocada y suele darse cuenta. Un agente engañado toma la misma decisión varios cientos de veces antes de que nadie abra un panel.
Los filtros son parciales por construcción
El primer instinto es filtrar la entrada: analizar el ticket, puntuar el prompt, categorizar el documento, rechazar los que resulten sospechosos.
Los filtros ayudan. No cierran el agujero, y la razón es estructural más que una cuestión de ajuste. Un filtro es un clasificador sobre texto libre, y el texto lo escribe el atacante. Todo clasificador tiene una tasa de falsos negativos. El atacante puede seguir buscando hasta dar con uno, y tú te enteras después, si es que te enteras.
Ese compromiso está bien donde equivocarse sale barato. No es base para dejar que el software mueva dinero, borre copias de seguridad o cambie una regla de producción.
Así que da por hecho que la inyección funciona. Da por hecho que manipulan el modelo el día que importa. Entonces la pregunta útil es otra: ¿qué puede hacer realmente el agente una vez manipulado?
Autorización, no persuasión
Empieza por no darle autoridad al agente.
Saca la credencial del agente. El agente tiene una sola clave que sirve para pedir, no para actuar. Toda acción sale como una propuesta firmada: esta acción, estos argumentos, estos recursos. Una propuesta es una petición. Tenerla no concede nada.
La propuesta se encuentra con una política que tú firmaste. La política la clasifica por lo que toca, lo que cuesta y si se puede deshacer. Las acciones rutinarias se conceden en milisegundos, así que el agente nunca tiene que esperar a algo que siempre iba a estar bien. Las acciones peligrosas se retienen. Una acción sin regla se rechaza, nunca se adivina. Lo desconocido nunca es riesgo bajo.
Una acción retenida necesita personas, y las necesita de una manera concreta. Los aprobadores firman los bytes exactos que se van a ejecutar, no un resumen de ellos. La regla es un quorum: retenida, quorum 2-of-2 requerido. Un aprobador firma y el otro rechaza, así que no se alcanza el quorum y no se ejecutó nada. El silencio no es consentimiento. Quien propuso la acción no puede aprobarla.
Después, la ejecución. Solo se ejecutan las propuestas concedidas, y se ejecutan con la identidad de ZIFFER, no con la del agente. Tus sistemas aceptan la acción desde esa identidad y desde ninguna otra. Un agente totalmente secuestrado que intenta ir directo choca contra un muro, no contra una alerta.
Lo que una decisión tiene que dejar detrás
Cada resultado escribe un comprobante: qué se propuso, cómo se clasificó, quién firmó, qué se ejecutó. Los comprobantes se firman, se añaden a un libro de registro y se anclan fuera del sistema que los produjo, antes de que se libere una acción irreversible. Nadie reescribe ese historial después, nosotros incluidos.
Esa es la parte que convierte una política en evidencia. Un registro dice lo que un servicio afirma que pasó. Un comprobante permite que otra persona lo verifique, sin acceso a producción y sin tener que fiarse de tu palabra.
La forma de la solución
La inyección de prompts no espera a un prompt mejor, y no es un problema de calidad del modelo que se resuelva en la hoja de ruta de otro. Es lo que pasa cuando se entregan credenciales a algo que recibe instrucciones de desconocidos.
Así que no le entregues credenciales. Deja que proponga. Deja que tu política conceda. Mantén a tus personas en las acciones que las merecen, y guarda un comprobante de todo lo que se ejecutó.
El agente sigue siendo exactamente tan capaz como lo construiste. Deja de ser lo que decide.
ZIFFER está construido sobre una especificación abierta, y cada afirmación que contiene está pensada para reproducirse en tu propia máquina. La documentación es el punto de partida.