Seguridad de agentes de IA: siete controles para empresas
Revisa acceso, aprobaciones, datos y recuperación antes de conectar un agente de IA. Incluye ejemplos para equipos de India y Estados Unidos.
Traducción del artículo original: revisión general del 12 de septiembre de 2026 y ejemplo de permisos de Lovable comprobado el 23 de septiembre. Los ejercicios son hipotéticos, no pruebas realizadas ni una certificación.
Qué significa proteger un agente de IA
Preparar una respuesta y enviarla requieren permisos distintos. La diferencia importa todavía más si el asistente puede leer contratos, cambiar pedidos o ejecutar código. La evaluación comienza por la acción delegada y las pruebas necesarias para permitirla.
La seguridad de agentes protege los datos, herramientas y sistemas que pueden consultar o modificar: qué acciones tienen disponibles, bajo qué autoridad y cómo se verifica su ejecución. OWASP llama capacidad de actuación excesiva al riesgo de conceder demasiadas funciones, permisos o autonomía. Un conector de lectura que también permite borrar o comunicarse con terceros amplía el riesgo.
La inyección de instrucciones introduce órdenes maliciosas en páginas, documentos o correos procesados por el modelo. Es distinta del exceso de permisos, aunque ambos problemas pueden combinarse. También puede producirse una acción incorrecta sin un atacante.
Siete controles antes de una prueba piloto
Usa estas preguntas con tu desarrollador o proveedor. Los resultados de aprobación y rechazo siguientes son ejercicios propuestos con tickets sintéticos: no los hemos ejecutado. Superar uno solo aporta evidencia sobre ese ejercicio, no sobre toda la seguridad del sistema.
| Control | Qué comprobar | Resultado aceptable | Motivo para detenerse |
|---|---|---|---|
| 1. Acceso limitado | Lista de registros y acciones permitidos, aplicada por el servicio en cada solicitud. Evita depender de una cuenta administradora compartida. | Lee T-104 y su pedido de prueba vinculado. | Puede consultar el pedido de otro cliente. No conectes registros reales hasta corregirlo. |
| 2. Contenido externo | Un correo es información para procesar, no autoridad para cambiar herramientas. Se necesitan defensas por capas; una instrucción de precaución no basta. | Un correo de prueba que pide exportar otros tickets no puede activar la exportación. | El correo modifica las herramientas disponibles o la tarea permitida. |
| 3. Aprobación exacta | El revisor ve destinatario, texto y registro concreto. Cambiarlos invalida la aprobación; propuesta y ejecución quedan separadas. | En una prueba posterior de envío aislado, cambiar el destinatario exige nueva aprobación. | Aprobar una versión permite enviar otra. El piloto de borradores no debe disponer de herramienta de envío. |
| 4. Aislamiento | Espacio separado, datos sintéticos y destinos de red permitidos. Identifica qué credenciales añadiría producción y qué restringe realmente el entorno aislado. | T-104 pertenece a una cuenta de prueba. | La demostración necesita credenciales de administrador de la tienda real. |
| 5. Registro sin secretos | Registra destino, hora, referencia de aprobación y resultado; contrástalos con el servicio. Protege también el acceso a los registros y evita contraseñas, tokens y contenido innecesario. | Puede reconstruirse la versión del borrador y la decisión sin mostrar credenciales. | Aparece un token o el resultado no puede vincularse con T-104. |
| 6. Límites operativos | Límites de reintentos, llamadas y gasto; protección contra duplicados cuando un tiempo de espera deja el resultado incierto. | Una solicitud repetida se retiene para revisión al alcanzar el límite configurado. | Sigue reintentando sin una condición de parada visible. |
| 7. Parada y recuperación | Un responsable puede impedir acciones nuevas, revocar acceso y revisar trabajo pendiente. Un mensaje enviado quizá no pueda retirarse. | Desactivar la integración bloquea nuevas solicitudes y deja visibles los borradores pendientes. | Continúa trabajando tras revocar el acceso o nadie identifica qué sigue en curso. |
Ejemplo: los permisos guardados pueden abarcar varios proyectos
La documentación de Lovable consultada el 23 de septiembre de 2026 indica que los permisos del agente se aplican entre espacios de trabajo y proyectos, aunque la lista de conectores depende del espacio. Las acciones pueden permitirse automáticamente, exigir confirmación o denegarse. No comprobamos su aplicación dentro de una cuenta.
Si una agencia pasa de una demostración interna al espacio de un cliente, conviene revisar los permisos durante la entrega: documentar aprobaciones permanentes, retirar accesos innecesarios y comprobar con registros sintéticos que una escritura rechazada no se ejecuta. No supongas que cambiar de proyecto borra aprobaciones anteriores. Otros productos pueden delimitar sus permisos de otra forma.
Este ejemplo tiene una comprobación específica posterior; no actualiza la fecha de verificación del incidente ni del resto de la lista.
Flujo de revisión en cuatro pasos
Este flujo de soporte es ilustrativo, no un agente en funcionamiento ni una certificación. Preparar borradores y enviar mensajes se evalúan por separado.
| Paso | Acción y ejemplo | Cuándo detenerse |
|---|---|---|
| 1. Delimitar | Nombra ticket, datos y responsable. Una agencia india solo lee T-104 y la política de entrega aprobada de su cliente estadounidense; empieza con datos sintéticos. | El conector expone otros pedidos o requiere acceso de administrador real. |
| 2. Preparar | Genera una versión del borrador sin herramienta de envío. No puede reembolsar ni cambiar el pedido aunque el cliente lo solicite. | Inventa una fecha de entrega, revela otros datos o pide herramientas fuera de alcance. |
| 3. Revisar | Una persona comprueba destinatario y texto, aprueba o rechaza y, en este primer piloto, envía mediante el sistema oficial. Si el revisor autorizado no está disponible, se deja en cola: el silencio no autoriza. | El destinatario o contenido cambia después de revisar. Un futuro envío automático necesita controles específicos nuevos. |
| 4. Verificar | Marca T-104 como rechazado, en cola o entregado a una persona. El envío humano, si existe, se vincula por separado con la referencia del sistema de soporte. | Los registros discrepan o el resultado no está resuelto. Investiga antes de reenviar o ampliar la prueba. |
Una agencia de India que da soporte a un cliente de Estados Unidos
En este caso hipotético, la primera fase solo prepara respuestas sobre entregas. Una persona revisa y, cuando corresponde, envía por el sistema oficial de la tienda. El agente no tiene herramienta de envío, no cambia direcciones y no emite reembolsos. No se afirma que exista una implementación real.
| Campo | Información para el revisor |
|---|---|
| Tarea | Preparar respuesta de entrega para el ticket sintético T-104. |
| Datos | Política aprobada y pedido de prueba vinculado. |
| Resultado propuesto | Respuesta completa y destinatario exacto. |
| Límites | Sin reembolso, cambio de dirección, destinatario adicional ni consultas a otros pedidos. |
| Decisión | Identidad del revisor, aprobación o rechazo y versión aprobada. |
| Estado del borrador | Rechazado, en cola o entregado a una persona; identificar la versión revisada. |
| Envío humano separado | Vincular la referencia del mensaje del sistema de soporte. Terminar el borrador no demuestra entrega. |
Qué respuesta debe rechazar el revisor
El ticket y las respuestas siguientes son inventados para el ejercicio. El pedido figura «en tránsito», sin fecha confirmada ni reembolso aprobado. El cliente pregunta si se garantiza la entrega mañana o se le devolverá el dinero.
Borrador A, rechazar: «Tu pedido llegará mañana. Si no llega, emitiremos automáticamente un reembolso completo». Ninguna promesa está respaldada y la tarea no permite comprometer un reembolso. Regístralo como rechazado: no se ha enviado ningún mensaje ni iniciado ningún reembolso.
Borrador B, para revisión humana: «Tu pedido figura actualmente en tránsito. El registro disponible no confirma una fecha de entrega. No puedo confirmar un reembolso solo con este estado; tu solicitud necesita revisión de nuestro equipo de soporte».
La segunda versión se ajusta a los hechos disponibles, pero aún requiere verificar destinatario, estado actual y política aprobada. No afirma que la derivación al equipo ya haya ocurrido. Cualquier traspaso o envío humano necesita su propio resultado registrado.
Si el revisor del cliente no está disponible por la diferencia horaria, deja el borrador en cola según una regla acordada previamente. No confundas silencio con consentimiento. Revisa por separado tratamiento de datos y responsabilidades contractuales de los servicios y jurisdicciones reales.
Criterios de aceptación para una pequeña empresa
En la primera fase, compara cada resultado de la aplicación con una expectativa observable usando datos sintéticos. Estos son ejercicios propuestos, no pruebas ejecutadas por UseAIVisora.
| Ejercicio | Resultado esperado |
|---|---|
| Pregunta de entrega habitual | Borrador respaldado por datos para el ticket correcto. |
| Necesita el pedido de otro cliente | Acceso denegado o derivado, sin revelar el registro ajeno. |
| El revisor rechaza | Borrador rechazado; el agente carece de capacidad de envío. |
| Cambia el destinatario | Vuelve a revisión antes de que una persona lo use. |
| Se agota el tiempo de generación | Resultado pendiente hasta comprobarlo, nunca marcado como entregado. |
| El responsable desactiva la integración | Fallan las solicitudes nuevas y queda visible el trabajo pendiente. |
La fase 2 evalúa por separado una herramienta de envío, primero en un entorno aislado con destinatarios de prueba. Cambiar destinatario o texto debe exigir nueva aprobación; una acción rechazada no puede ejecutarse; un resultado de entrega incierto debe comprobarse antes de reenviar. Completar la fase 1 no concede esos permisos.
Registra versión configurada, resultado observado y problemas abiertos. Si falla un límite, mantén esa acción fuera del piloto. Una demostración satisfactoria solo es evidencia sobre esa configuración, no sobre todas las entradas futuras o actualizaciones del modelo.
Qué ocurrió en RubyGems y qué no está confirmado
RubyGems aloja paquetes usados por desarrolladores Ruby. Su comunicado del 11 de septiembre de 2026 revisó una campaña de publicaciones de spam ocurrida en mayo: bloqueó cuentas, pausó temporalmente altas nuevas y retiró más de 500 paquetes maliciosos. Las instalaciones y publicaciones de usuarios existentes no se vieron afectadas.
Los investigadores atribuyeron la actividad a agentes de OpenAI, pero RubyGems no pudo determinar con sus propias pruebas si agentes de IA crearon o publicaron los paquetes. Los investigadores identificaron código destinado a obtener claves API de otros usuarios; la investigación de RubyGems no encontró pruebas de que esos intentos tuvieran éxito.
El episodio fue en mayo; la aclaración, en septiembre. No demuestra que todos los agentes comerciales sean inseguros ni que se robaran credenciales con éxito. La lección operativa es más limitada: evaluar lo que una integración puede hacer en servicios externos, aunque la tarea parezca inocua.
Dónde encaja la gobernanza
Los controles necesitan un responsable que determine tareas aceptables, conserve pruebas y reaccione cuando cambien las condiciones. Esa responsabilidad continuada forma parte de la gobernanza de agentes.
El marco de gestión de riesgos de IA de NIST es voluntario. Sus cuatro funciones —gobernar, contextualizar, medir y gestionar— ayudan a organizar responsabilidades y revisiones. Esta hoja no certifica cumplimiento normativo en Estados Unidos ni en India.
La siguiente decisión: probar, restringir o detener
- Inicia un piloto limitado de borradores cuando los ejercicios sintéticos cumplan lo esperado, exista un alcance documentado y un revisor se responsabilice de las excepciones. Permite evaluar ese flujo, no certifica producción.
- Mantén el envío en manos humanas si los borradores funcionan pero faltan pruebas sobre aprobación específica, duplicados o registros de entrega. Un texto convincente no justifica conceder envío.
- Detén la conexión e investiga si expone otros registros o credenciales, evita aprobaciones o continúa tras la revocación. Reanuda solo después de corregir el control y repetir el ejercicio pertinente.
Pide al proveedor que demuestre una acción rechazada con el mismo cuidado que una correcta. Amplía el acceso según lo que la integración realmente impida o permita.
Preguntas frecuentes
¿Un agente de solo lectura es seguro?
Impide ciertos cambios, pero aún puede revelar información sensible. Limita registros y destinos de salida; evalúa el flujo completo y las herramientas conectadas.
¿Una instrucción de sistema evita cualquier acción no autorizada?
No. Las instrucciones definen la tarea, pero la aplicación y sus servicios deben imponer permisos y aprobaciones. El contenido recuperado también puede contener órdenes hostiles.
¿Hay que comprar una plataforma de gobernanza?
No. Documenta primero un flujo, sus permisos, revisor y resultados de aceptación. Una plataforma adicional solo ayuda si resuelve controles o registros que tus herramientas no cubren.
¿Los ejemplos de Estados Unidos e India son asesoría legal?
No. Ilustran decisiones operativas transfronterizas. Datos, contratos y obligaciones sectoriales requieren revisión para el negocio y los servicios concretos.
Fuentes
Estas son las fuentes oficiales del artículo original. Muchas de sus páginas están en inglés.