La propiedad de los agentes de IA es la primitiva de confianza
El 15 de mayo de 2026, investigadores de Ben-Gurion University of the Negev, Northeastern University y Amrita Vishwa Vidyapeetham definieron la atribución de agentes como el problema de vincular una interacción observada de un agente de IA con la cuenta responsable en el proveedor que lo aloja.1
La frase suena acotada. El problema no lo es. Un agente puede enviar spam a usuarios, extraer datos de sistemas, hacerse pasar por un representante de soporte, ejecutar una tarea de ciberseguridad, invocar herramientas, gastar dinero o modificar infraestructura mientras la parte afectada ve el comportamiento, pero no puede identificar al operador que desplegó el agente.1
La propiedad de los agentes de IA es la primitiva de confianza que falta. Cada acción autónoma debería corresponder a una cuenta responsable, una sesión, un alcance de autoridad, un propietario humano u organizacional y una vía para detenerla. Los registros te dicen qué ocurrió. La propiedad te dice quién puede responder por ello.
Resumen
La seguridad de los agentes no puede quedarse en permisos de herramientas, ganchos en tiempo de ejecución o evidencia en la respuesta final. Esos controles importan, pero no contestan la pregunta de responsabilidad: ¿quién es dueño del agente en ejecución?
El nuevo artículo sobre atribución de agentes propone un protocolo mediado por proveedores que usa canarios para conectar una interacción dañina observada con una sesión y una cuenta del proveedor.1 Esa investigación apunta a la respuesta ante abusos y a la responsabilidad legal. Los equipos de producto necesitan una versión cotidiana más pequeña dentro de sus propios sistemas: cada ejecución de agente debería llevar un registro de propiedad que conecte cuenta, sesión, alcance de permisos, actividad de herramientas, ruta de revisión e interruptor de apagado.
Ideas clave
Para equipos de plataformas de agentes: - Trata la propiedad como un campo del entorno de ejecución, no como una ocurrencia tardía de facturación. - Adjunta propietario, cuenta, sesión, alcance de herramientas y controles de detención a cada ejecución de agente.
Para equipos de seguridad: - Los registros sin propiedad retrasan la respuesta a incidentes. La propiedad sin registros debilita la evidencia. - Exige ambas cosas: una traza de acciones y una ruta hacia la cuenta responsable.
Para equipos de producto: - Muéstrales a los usuarios quién o qué actúa en su nombre. - Separa la acción delegada de la responsabilidad delegada.
Para equipos de política y confianza: - Diseña la atribución para respuestas autorizadas, no para desanonimización casual. - Registra lo suficiente para detener daños, revisar abusos y respetar el debido proceso.
La propiedad no es un nombre de perfil
La mayoría de los productos ya muestran alguna forma de identidad. Una ventana de chat puede mostrar un espacio de trabajo, el avatar de un usuario, el nombre de un bot, una etiqueta de clave API o una organización. Esa superficie puede ayudar a las personas a orientarse, pero no prueba la propiedad.
La propiedad de agentes necesita un contrato más estricto:
| Campo | Pregunta que responde |
|---|---|
| Cuenta | ¿Qué cliente, espacio de trabajo o cuenta de proveedor financió la ejecución? |
| Sesión | ¿Qué ejecución concreta produjo la acción? |
| Operador | ¿Qué persona, servicio o política delegó el trabajo? |
| Alcance de autoridad | ¿Qué herramientas, claves, presupuestos y recursos podía usar el agente? |
| Traza de acciones | ¿Qué prompts, aprobaciones, llamadas de herramientas, salidas y decisiones de red ocurrieron? |
| Vía de detención | ¿Quién puede pausar, revocar, limitar o terminar la ejecución? |
| Ruta de revisión | ¿Quién puede investigar después de una queja o alerta? |
La lista parece operativa porque la propiedad es operativa. Una etiqueta no ayuda cuando un agente envía 2.000 mensajes dañinos o satura un endpoint de terceros. El equipo de respuesta necesita la sesión, la cuenta, el alcance de autoridad y la vía de detención.
Las claves de agentes necesitan presupuestos de riesgo cubre el lado de la autoridad: las claves deberían conceder capacidades limitadas e impuestas desde el servidor. La propiedad cubre el lado de la responsabilidad: cada uso de esa autoridad debería apuntar a un registro responsable.
Qué aporta el artículo sobre atribución
El artículo formaliza una brecha que los operadores de agentes reconocerán rápido. La víctima ve el comportamiento del agente. El proveedor ve las llamadas al modelo y los registros de cuenta. Ninguna de las dos partes, por sí sola, ve ambas perspectivas.1
El protocolo propuesto une esas perspectivas con canarios. Una parte autorizada inyecta un marcador en contenido que es probable que el agente sospechoso consuma. Si el agente reenvía ese contenido a una llamada de modelo alojada por un proveedor, el proveedor puede buscar en una ventana temporal estrecha de registros de sesión, encontrar el canario, recuperar la sesión y conectar la sesión con una cuenta.1
El artículo separa los casos fáciles de los difíciles:
| Contexto | Forma práctica del canario | Por qué funciona |
|---|---|---|
| Uso indebido no adversarial | Marcador léxico, identificador o cadena única | El agente pasa contenido al modelo sin filtrarlo. |
| Abuso adversarial | Canarios léxicos o semánticos con valor para la tarea | Quitar el canario también elimina contenido que el agente necesita. |
| Respuesta del proveedor | Búsqueda de registros en una ventana temporal estrecha | El proveedor busca sesiones cercanas al momento de inyección, no todos los registros históricos. |
La idea de que el canario tenga utilidad importa. Un agente de estafa puede necesitar señales emocionales de un objetivo. Un agente web puede necesitar contenido visible de la página. Un agente de ciberseguridad puede necesitar nombres de archivo y artefactos de respuesta. Si el operador filtra con demasiada agresividad, el agente pierde rendimiento en la tarea junto con la evidencia de atribución.1
El experimento del artículo con agentes de ciberseguridad vuelve concreto ese intercambio. Un adversario consciente del canario redujo la tasa de resolución del agente de 51% a 9% cuando la supresión eliminó artefactos relevantes para la tarea. Los nombres de archivo y los identificadores visibles en el cuerpo aún conservaron evidencia de atribución en 77% y 70%, respectivamente, mientras que los canarios semánticos alcanzaron al menos una tasa de verdaderos positivos de 98% en la variante semántica adversarial.1
Esos números no deberían convertirse en marketing de producto. El artículo prueba agentes, envoltorios y familias de canarios específicos. La lección sí debería sobrevivir: la atribución funciona mejor cuando la señal viaja en contenido que el agente realmente necesita.
Los registros son necesarios, pero no suficientes
La publicación de OpenAI sobre la seguridad de Codex describe una forma madura de control: ejecución acotada, aprobaciones, política de red administrada, almacenamiento de credenciales, reglas, configuración administrada y telemetría nativa para agentes.2 El lado de la telemetría incluye registros de OpenTelemetry para prompts de usuario, decisiones de aprobación, resultados de ejecución de herramientas, uso de servidores MCP y eventos de permitir o denegar en el proxy de red.2
OpenAI también describe un flujo de trabajo de triaje de seguridad que usa registros de Codex para inspeccionar la solicitud original, la actividad de herramientas, las decisiones de aprobación, los resultados de herramientas y las decisiones de política de red alrededor de alertas de endpoints sospechosos.2
Esa evidencia es necesaria. Aun así, necesita propiedad.
Una traza de herramienta puede decir:
| Evidencia de la traza | Pregunta de propiedad que falta |
|---|---|
| El agente llamó a una herramienta de shell | ¿Qué cuenta autorizó la ejecución? |
| El agente chocó con un bloqueo de red | ¿Qué propietario de política puede revisar el bloqueo? |
| El agente solicitó aprobación | ¿Quién concedió, denegó o delegó la aprobación? |
| El agente usó un servidor MCP | ¿Qué espacio de trabajo configuró ese servidor? |
| El agente produjo una salida | ¿Qué operador acepta responsabilidad por la publicación? |
Las trazas de ejecución de agentes son el contrato del entorno de ejecución sostiene que las trazas prueban el recorrido. La propiedad prueba la parte responsable detrás de ese recorrido. Los sistemas sólidos necesitan ambos registros unidos a nivel de sesión.
Codex muestra por qué el problema ya no es teórico
El anuncio de Codex de OpenAI del 14 de mayo dice que más de 4 millones de personas usan Codex cada semana y describe un flujo de trabajo móvil donde los usuarios pueden revisar salidas, aprobar comandos, cambiar modelos, iniciar trabajo y seguir capturas de pantalla, salida de terminal, diffs, resultados de pruebas y aprobaciones desde un teléfono.3 El mismo anuncio dice que Remote SSH alcanzó disponibilidad general, lo que permite a Codex ejecutar hilos dentro de máquinas remotas y entornos administrados.3
Esa forma de producto empuja el trabajo de agentes a través de dispositivos, máquinas, hilos, aprobaciones, credenciales y herramientas locales. Una sola ejecución de agente puede involucrar una laptop, una aprobación desde el teléfono, un host remoto, un proyecto, un plugin, un navegador, una shell y una operación de control de versiones.
El registro de propiedad tiene que viajar con la ejecución. De lo contrario, el sistema puede responder “¿qué comando se ejecutó?” mientras pierde “¿quién era dueño de la ejecución cuando se ejecutó el comando?”.
Los ganchos de Codex hacen real el arnés planteó los ganchos, las aprobaciones, la custodia de Git, la evidencia y el criterio como una capa operativa alrededor del trabajo con agentes. La propiedad pertenece a esa misma capa. Un gancho puede bloquear una acción riesgosa. Una traza puede explicar una acción completada. La propiedad conecta la ejecución con la cuenta y el operador que pueden responder por ambos resultados.
El contrato de propiedad en tiempo de ejecución
Los equipos no necesitan el protocolo completo de atribución con canarios para cada tarea interna. Necesitan un contrato de propiedad de primera parte que vuelva rutinaria la atribución antes de que algo salga mal.
Empieza con un registro por cada ejecución de agente:
| Campo del registro de propiedad | Comportamiento mínimo |
|---|---|
run_id |
ID estable para la sesión o tarea del agente. |
account_id |
Cliente, espacio de trabajo, tenant u organización que posee la ejecución. |
operator_id |
Persona, servicio, tarea programada o política que inició la ejecución. |
delegation_source |
Clic en UI, llamada API, regla programada, aprobación móvil o token de automatización. |
authority_bundle |
Herramientas, claves, alcances, presupuestos, raíces con escritura, política de red y dominios de datos. |
approval_events |
Quién aprobó qué, cuándo y bajo qué política. |
trace_pointer |
Enlace a prompts, llamadas de herramientas, salidas, errores y decisiones de red. |
stop_controls |
Controles para pausar, revocar, limitar, aislar o terminar. |
review_owner |
Equipo o cola que recibe revisiones de abuso, seguridad, protección o calidad. |
retention_policy |
Cuánto tiempo permanece disponible el registro y quién puede acceder a él. |
El registro debería ubicarse por debajo de la transcripción del chat y por encima de los registros crudos de infraestructura. Soporte de producto puede usarlo. Seguridad puede usarlo. Cumplimiento puede usarlo. Ingeniería puede usarlo durante una reversión.
Los nombres de los campos importan menos que el principio invariable: ninguna acción de agente sin un registro de ejecución responsable.
La propiedad necesita límites de privacidad
La atribución puede volverse abusiva si los equipos la tratan como permiso para desenmascarar a todos por defecto. El artículo sobre propiedad nombra ese riesgo directamente y enmarca el protocolo alrededor de autoridades autorizadas y auditables, legitimidad de política y proceso legal.1
Los equipos de producto deberían copiar esa moderación.
| Límite | Regla de producto |
|---|---|
| Acceso | Solo revisores autorizados pueden inspeccionar registros de propietario. |
| Propósito | Solo abuso, seguridad, protección, soporte, cumplimiento o respuesta a incidentes. |
| Divulgación | La divulgación externa requiere política, proceso o base legal. |
| Minimización | Almacena lo suficiente para detener daños y revisar la ejecución, no cada detalle privado para siempre. |
| Auditoría | Registra cada consulta de propiedad y cada divulgación. |
La propiedad no debería convertirse en vigilancia casual. Una atribución fuerte da a víctimas, plataformas, proveedores y operadores una ruta de respuesta. Una gobernanza débil convierte la misma primitiva en otro problema de confianza.
El principio de diseño es simple: haz que cada agente rinda cuentas ante el sistema, y que cada consulta de propiedad rinda cuentas ante la política.
Dónde encaja la propiedad con los controles de agentes existentes
La propiedad no reemplaza el resto de la pila.
El anuncio de OpenAI sobre Agents SDK apunta hacia la misma forma en capas. El SDK da a los agentes espacios de trabajo controlados, inspección de archivos y herramientas, MCP, skills, AGENTS.md, shell, parches, ejecución aislada y espacios de trabajo basados en manifiestos.4 AgentTrust plantea un argumento de seguridad complementario: inspeccionar llamadas de herramientas antes de la ejecución y devolver veredictos estructurados como permitir, advertir, bloquear o revisar.5
Esos sistemas deciden qué puede hacer el agente a continuación. La propiedad decide quién responde por la ejecución.
| Control | Función | Lo que agrega la propiedad |
|---|---|---|
| Claves con alcance | Limitar lo que el agente puede hacer | Qué cuenta y operador concedieron ese alcance |
| Ganchos en tiempo de ejecución | Interceptar acciones riesgosas | Qué ejecución activó el gancho |
| Umbrales de aprobación | Agregar juicio humano | Quién aprobó qué expansión de autoridad |
| Trazas de ejecución | Mostrar qué ocurrió | Quién posee la traza y quién puede actuar sobre ella |
| Paquetes de revisión | Empaquetar evidencia | Qué propietario acepta el resultado |
| Herramientas de modelo | Producir estimaciones tipadas | Qué sistema delegó autoridad al modelo |
Los agentes de IA deberían llamar modelos sostiene que los agentes deberían llamar a modelos entrenados en lugar de inventar estimaciones. La propiedad extiende la misma disciplina a la autoridad. El sistema debería saber si una acción vino de un clic humano, una sesión de agente, una herramienta de modelo, una automatización programada o una política delegada.
Esa distinción protege a los usuarios. Un usuario no debería tener que adivinar si una acción vino de él, de un asistente actuando bajo su cuenta, de una política de la organización o de una automatización comprometida.
Los agentes necesitan superficies de supervisión cubre el lado visible para el usuario de ese problema. La propiedad aporta el registro que vive debajo de la superficie. Los paquetes de revisión son la nueva respuesta final cubre el artefacto de cierre. La propiedad aporta la parte que puede aceptar, rechazar o revocar ese artefacto.
La regla de decisión
Antes de desplegar un agente que pueda afectar a otras personas o sistemas externos, haz una pregunta:
Si alguien se queja de este agente mañana, ¿podemos identificar la ejecución, la cuenta, el alcance de autoridad, el evento de aprobación y la persona o equipo que puede detenerlo?
Si la respuesta es no, el agente no está listo para producción.
Puede que el producto ya tenga registros. Puede que ya tenga permisos. Puede que ya tenga prompts que le dicen al modelo cómo comportarse. Esas piezas no equivalen a propiedad hasta que se unen en un registro responsable.
La propiedad de agentes debería volverse tan normal como los ID de solicitud, los registros de auditoría y las claves API. El trabajo puede sonar burocrático, pero la alternativa es peor: sistemas autónomos que pueden actuar mientras nadie puede responder por la acción.
Preguntas frecuentes
¿Qué es la propiedad de agentes de IA?
La propiedad de agentes de IA es el registro en tiempo de ejecución que conecta una acción del agente con la cuenta, sesión, operador, alcance de autoridad, traza y vía de detención responsables de la ejecución.
¿En qué se diferencia la propiedad de agentes de la atribución de agentes?
La propiedad de agentes es un contrato de producto de primera parte. El sistema registra la propiedad antes y durante una ejecución. La atribución de agentes resuelve el problema más difícil a posteriori: vincular un comportamiento dañino observado con una cuenta responsable del proveedor cuando la parte afectada todavía no conoce al propietario.1
¿Por qué fallan los registros por sí solos?
Los registros pueden mostrar comandos, llamadas de herramientas, aprobaciones y decisiones de red. Fallan cuando no pueden responder quién delegó la ejecución, quién era dueño del alcance de autoridad y quién puede detener o revisar el agente.
¿Los proveedores deberían revelar propietarios de agentes a cualquiera que lo pida?
No. La consulta de propiedad debería requerir acceso autorizado, legitimidad de política y auditoría. La divulgación externa debería exigir el proceso adecuado. La atribución solo protege la confianza cuando la ruta de consulta tiene su propia gobernanza.1
¿Cuál es el requisito mínimo para producción?
Cada ejecución de agente que pueda afectar sistemas externos debería tener un ID de ejecución, ID de cuenta, ID de operador, paquete de autoridad, registro de aprobación, puntero a la traza, control de detención, propietario de revisión y política de retención.
Referencias
-
Ruben Chocron, Doron Jonathan Ben Chayim, Eyal Lenga, Gilad Gressel, Alina Oprea, and Yisroel Mirsky, “Who Owns This Agent? Tracing AI Agents Back to Their Owners,” arXiv:2605.16035v1, enviado el 15 de mayo de 2026. Fuente de la definición de atribución de agentes, el modelo de amenazas de LLM alojados por proveedores, el protocolo de atribución basado en canarios, la taxonomía de canarios léxicos y semánticos, el intercambio entre utilidad y evasión, las cifras de evaluación de agentes de ciberseguridad, la propiedad de búsqueda en ventana acotada, las limitaciones y el marco ético alrededor de autoridades autorizadas y auditables. ↩↩↩↩↩↩↩↩↩↩
-
OpenAI, “Running Codex safely at OpenAI,” OpenAI, 8 de mayo de 2026. Fuente del aislamiento de Codex, aprobaciones, política de red administrada, controles de identidad y credenciales, configuración administrada, eventos de OpenTelemetry, registros de Compliance Platform y el uso de registros de Codex por parte de OpenAI en triaje de seguridad. ↩↩↩
-
OpenAI, “Work with Codex from anywhere,” OpenAI, 14 de mayo de 2026. Fuente del uso semanal de Codex, control móvil, conexión a máquinas remotas, estado en vivo entre hilos y aprobaciones, capturas de pantalla, salida de terminal, diffs, resultados de pruebas, disponibilidad general de Remote SSH, disponibilidad general de ganchos y tokens de acceso programático. ↩↩
-
OpenAI, “The next evolution of the Agents SDK,” OpenAI, 15 de abril de 2026. Fuente del bucle de agente nativo del modelo en Agents SDK, espacios de trabajo controlados, inspección de archivos y herramientas, MCP, skills, AGENTS.md, shell, apply_patch, ejecución nativa aislada, abstracción de manifiesto y separación entre orquestación de agentes y entornos de cómputo. ↩
-
Chenglin Yang, “AgentTrust: Runtime Safety Evaluation and Interception for AI Agent Tool Use,” arXiv:2605.04785v1, enviado el 6 de mayo de 2026. Fuente de la interceptación de llamadas de herramientas antes de la ejecución, veredictos permitir/advertir/bloquear/revisar, desofuscación de shell, detección RiskChain, alcance del benchmark e integración con servidores MCP. ↩