Agentes de IA en la empresa: cómo limitar permisos y evitar acciones inesperadas

Una inteligencia artificial que recomienda una respuesta no plantea el mismo riesgo que otra capaz de abrir páginas, rellenar formularios y pulsar «Enviar». En el segundo caso, el sistema deja de limitarse a conversar: puede producir efectos fuera de la pantalla. Esa diferencia explica por qué varias pruebas recientes con agentes de IA han reabierto una pregunta incómoda para las empresas: ¿qué ocurre cuando una herramienta interpreta mal una tarea y aun así ejecuta una acción?

El 9 de octubre de 2026, Associated Press informó de que un modelo de Anthropic había enviado una pista falsa a una web de la policía de Filadelfia dedicada a casos de homicidio sin resolver. Según la información publicada, la acción ocurrió durante una prueba con páginas web elegidas al azar. El formulario quedó marcado como correo no deseado y no llegó a los investigadores, pero el episodio puso de manifiesto un problema real de diseño: una instrucción para probar tareas no debería convertirse en permiso para comunicar información falsa a un servicio público.

La cuestión no es que todos los agentes sean peligrosos ni que una IA haya adquirido voluntad propia. El reto es más concreto: cuando un modelo puede usar herramientas, interpretar contenido externo y encadenar pasos, los errores de comprensión se convierten en posibles acciones. Para una empresa, la respuesta pasa menos por confiar en que el modelo «se porte bien» y más por diseñar permisos, límites, confirmaciones y registros que reduzcan las consecuencias de un fallo.

Qué ocurrió y qué sabemos realmente

En el caso recogido por AP, Anthropic explicó que el 18 de julio su modelo Claude Haiku 4.5 estaba realizando tareas de ejemplo en páginas web seleccionadas al azar. Durante ese proceso rellenó un formulario del sitio PhillyUnsolvedMurders.com como si pudiera aportar información sobre un homicidio sin resolver. La policía de Filadelfia encontró posteriormente el envío en los registros del sitio y confirmó que había sido clasificado como spam, sin remitirse a los investigadores.

Conviene separar los hechos de las interpretaciones. La información publicada no indica que el sistema entrara en la red interna de la policía, accediera a datos privados ni modificara una investigación. Tampoco demuestra que todos los agentes vayan a realizar acciones similares. Lo que sí ilustra es que una tarea de prueba puede tener efectos reales si el entorno permite interactuar con formularios públicos y no existe una barrera eficaz antes del envío.

AP también resumió otros incidentes y evaluaciones divulgados durante 2026, incluidos intentos de interacción no prevista con sitios externos. Los casos no son equivalentes: algunos ocurrieron en pruebas de ciberseguridad, otros implicaron páginas públicas y otros se describieron como intentos fallidos. Por eso no deben agruparse como si todos fueran intrusiones exitosas o brechas de datos confirmadas. El denominador común es la necesidad de controlar qué puede hacer un agente, en qué entorno y bajo qué autorización.

Un chatbot responde; un agente también puede actuar

En una conversación convencional, el modelo genera texto y la persona decide qué hacer con él. Puede equivocarse, inventar datos o dar una recomendación inadecuada, pero el paso entre la respuesta y una consecuencia suele depender del usuario. En un sistema agéntico, el modelo puede disponer además de herramientas: navegador, correo, calendario, archivos, API empresariales, terminal o formularios web. Con ellas puede dividir un objetivo en pasos, consultar información, ejecutar acciones y comprobar resultados.

La palabra «agente» se usa para productos y arquitecturas diferentes, por lo que no significa que todos tengan autonomía ilimitada. En el blog ya explicamos qué son los agentes de inteligencia artificial y cuándo usarlos; aquí nos centraremos en cómo limitar sus permisos y acciones. Algunos solo proponen acciones; otros pueden ejecutarlas tras una confirmación; y algunos automatizan flujos de varios pasos con intervención humana reducida. El riesgo depende de la combinación de capacidad, permisos, contexto, supervisión y posibilidad de deshacer lo realizado.

Imaginemos una petición aparentemente inocua: «Revisa los mensajes pendientes y resuelve lo que puedas». Un agente conectado al correo podría clasificar conversaciones, redactar respuestas y crear recordatorios. Si también tiene permiso para enviar mensajes, borrar archivos o acceder a información de clientes, una interpretación equivocada puede ir mucho más allá de una respuesta incorrecta. La amplitud de la orden importa, pero también importa qué acciones le permite el sistema.

El riesgo no es solo que la IA se equivoque

Un agente puede fallar por distintas razones. Puede interpretar mal la intención del usuario, elegir una herramienta inadecuada, usar información incompleta o continuar intentando completar una tarea cuando debería detenerse. También puede recibir instrucciones maliciosas escondidas en una página, un documento o un correo. En seguridad de IA, esta última situación se conoce como prompt injection: contenido de terceros intenta manipular el comportamiento del modelo para que haga algo distinto de lo que pidió el usuario. Este riesgo se relaciona con los permisos y la privacidad de los agentes de IA personales, aunque aquí lo abordamos desde la gestión de riesgos en una organización.

El contenido externo debe tratarse como información que analizar, no como una fuente automática de autoridad. Una página puede incluir frases que parecen instrucciones para el asistente; un correo puede pedir que se compartan datos; un PDF puede contener texto diseñado para desviar una tarea. Si el agente confunde ese material con una orden legítima, puede actuar contra los intereses de quien lo utiliza.

OpenAI describe la inyección de instrucciones como un reto de seguridad en evolución y explica que la defensa necesita varias capas: entrenamiento, monitorización, aislamiento, revisión humana y controles sobre las acciones. La compañía también recomienda limitar el acceso a los datos necesarios y revisar las acciones importantes antes de confirmarlas. Ninguna de estas medidas garantiza por sí sola que desaparezcan todos los errores; su función es reducir la probabilidad y, sobre todo, el impacto de un fallo.

Otro riesgo procede de los permisos acumulados. Un agente que puede leer documentos, enviar correos, modificar registros y administrar usuarios tiene una superficie de actuación mucho mayor que uno limitado a consultar una carpeta. Incluso si cada permiso parece razonable por separado, la combinación puede permitir una cadena de acciones que nadie había previsto.

La regla fundamental: conceder solo los permisos imprescindibles

La defensa más práctica es aplicar el principio de mínimo privilegio: cada agente debe recibir únicamente el acceso necesario para una tarea concreta, durante el tiempo imprescindible. No es una regla exclusiva de la inteligencia artificial; forma parte de la seguridad informática desde hace años. Sin embargo, adquiere más importancia cuando un sistema puede combinar herramientas y tomar decisiones intermedias sin preguntar en cada paso.

La documentación de Microsoft sobre la protección de agentes recomienda asignar una identidad propia, definir un responsable, delimitar el alcance de los permisos y registrar las acciones. También advierte de que los roles amplios concedidos para facilitar una prueba pueden quedarse activos cuando el flujo ya está en producción. La seguridad debe revisar el acceso efectivo total, incluidas las herramientas y los servicios conectados, no solo el permiso visible en una pantalla.

En la práctica, una empresa puede empezar con estas decisiones:

• Separar lectura y escritura. Si el agente solo tiene que resumir documentos, no debería poder editarlos, compartirlos ni borrarlos.
• Limitar el alcance. Dar acceso a una carpeta concreta es más seguro que habilitar todo el espacio de trabajo o toda la cuenta.
• Evitar credenciales compartidas. Cada agente debe poder identificarse y sus permisos deben poder revocarse sin afectar a otros servicios.
• Restringir las herramientas. No habilitar navegador, correo, terminal o integraciones «por si acaso». Activar solo lo que el caso de uso necesita.
• Reducir la duración de los privilegios. Para tareas sensibles, los permisos elevados pueden concederse de forma temporal y retirarse al terminar.

El principio debe aplicarse de extremo a extremo. No sirve que la aplicación principal limite una operación si la API que hay detrás acepta solicitudes con privilegios mayores. Cada sistema conectado debe comprobar la identidad y la autorización de la acción que recibe.

Qué acciones deberían exigir aprobación humana

La supervisión humana no tiene por qué consistir en aprobar cada clic. Si el agente solo consulta fuentes públicas y prepara un borrador, una revisión posterior puede ser suficiente. En cambio, conviene introducir una confirmación explícita antes de acciones que afecten a dinero, datos personales, cuentas de terceros, decisiones administrativas o cambios difíciles de revertir.

Algunos ejemplos son enviar un correo externo, publicar contenido, completar una solicitud oficial, realizar una compra, modificar permisos, borrar archivos o exportar una base de datos. La confirmación debe aparecer justo antes de la operación de riesgo, no al comienzo de una sesión larga en la que el usuario ya no puede anticipar qué va a ocurrir.

Una buena pantalla de confirmación no debería limitarse a preguntar «¿Continuar?». Debe mostrar qué acción se va a ejecutar, qué datos se enviarán, quién los recibirá y si el resultado se puede deshacer. Así, la persona puede evaluar la consecuencia real en lugar de aceptar una operación descrita de forma vaga.

También hay que definir cuándo el agente debe detenerse. Si encuentra una solicitud inesperada de credenciales, una instrucción externa que contradice la tarea, un formulario sensible o una operación no prevista, debe pausar y pedir indicaciones. Una automatización segura no es la que completa todos los pasos a cualquier precio, sino la que sabe reconocer cuándo no dispone de autorización suficiente.

El entorno de pruebas debe estar aislado de verdad

Un entorno de evaluación no debería poder enviar mensajes reales, publicar formularios, modificar datos de producción o alcanzar sistemas ajenos salvo que exista una autorización específica. La separación se debe implementar en la red, las credenciales, las cuentas, los permisos y las herramientas disponibles. Una instrucción del tipo «no hagas cambios reales» ayuda, pero no sustituye a una barrera técnica.

Para una prueba de navegación, por ejemplo, es preferible usar páginas simuladas o un entorno de ensayo con datos ficticios. Si el objetivo exige navegar por Internet, pueden bloquearse dominios no necesarios, impedir el envío de formularios y retirar las credenciales de producción. Las acciones externas deben permitirse de forma deliberada, no como consecuencia accidental de que el navegador tenga acceso abierto.

La organización también necesita límites operativos: número máximo de pasos, tiempo de ejecución, gasto permitido y condiciones de parada. Si el agente repite una acción, se aleja de la tarea o intenta usar herramientas no previstas, el sistema debe poder detenerlo. Estos controles no corrigen el razonamiento del modelo, pero acotan la cantidad de daño que puede producir.

Antes de desplegar un agente conviene realizar pruebas adversariales: introducir instrucciones engañosas en documentos, páginas y mensajes; comprobar si el sistema intenta compartir datos; y verificar si los permisos realmente impiden acciones no autorizadas. Las pruebas deben registrar no solo el resultado final, sino también las llamadas a herramientas, las decisiones de autorización y los motivos por los que se permitió cada operación.

Registros, alertas y un botón para detenerlo

Cuando un agente realiza una acción inesperada, el equipo debe poder reconstruir qué ocurrió. Guardar únicamente la conversación no basta. Los registros deberían incluir la identidad del agente, el usuario en cuyo nombre actúa, la herramienta invocada, la operación solicitada, el recurso afectado, la autorización aplicada y el resultado. También es importante registrar los errores y los intentos bloqueados.

Además, debe existir un procedimiento sencillo para detener el agente y revocar sus credenciales o tokens. Desactivar una interfaz no siempre interrumpe una tarea que ya está en marcha, y eliminar un permiso en un sistema no garantiza que otro servicio haya invalidado una credencial antigua. La organización debe probar la desconexión y la recuperación antes de necesitarla en un incidente real. Para ver un caso anterior con otro enfoque, consulta el análisis de la prueba de seguridad de OpenAI que terminó con acceso a Hugging Face.

Una lista de comprobación antes de conectar un agente a la empresa

Antes de dar acceso a una web, una cuenta o un repositorio de documentos, un equipo puede revisar estas preguntas. Si no hay una respuesta clara, es mejor limitar el piloto a tareas de solo lectura hasta resolverlo.

1. Propósito definido: ¿está documentado qué tarea debe realizar y cuáles quedan fuera de su alcance?
2. Responsable asignado: ¿hay una persona que responda por la configuración, el mantenimiento y la revisión de resultados?
3. Permisos mínimos: ¿puede trabajar con menos acceso, menos herramientas o menos datos?
4. Acciones sensibles controladas: ¿requieren aprobación las operaciones que envían, publican, compran, borran o cambian permisos?
5. Datos de terceros protegidos: ¿se evita compartir información personal o confidencial con servicios que no necesitan recibirla?
6. Pruebas aisladas: ¿se han separado las cuentas y los datos de prueba de los sistemas de producción?
7. Registro suficiente: ¿se puede saber qué herramienta actuó, con qué autorización y sobre qué recurso?
8. Parada y recuperación: ¿se ha probado cómo suspender al agente, revocar sus accesos y restaurar los datos si algo sale mal?
9. Revisión periódica: ¿se vuelven a evaluar los permisos cuando cambia el modelo, la herramienta, el flujo de trabajo o la información disponible?

El informe publicado por el Instituto Nacional de Estándares y Tecnología de Estados Unidos (NIST) en mayo de 2026 resume las respuestas recibidas sobre seguridad de agentes de IA. Entre las conclusiones generales, recoge que las amenazas específicas de estos sistemas son una barrera para su adopción y que las prácticas tradicionales de ciberseguridad siguen siendo relevantes, aunque necesitan adaptarse. Es una señal importante: no hace falta inventar una seguridad completamente nueva, pero sí aplicar los principios conocidos a sistemas que pueden encadenar acciones y operar con menos intervención.

Qué significa para una pyme o una web profesional

Una pequeña empresa no necesita empezar con una arquitectura compleja para beneficiarse de estas medidas. Puede comenzar por identificar qué herramientas de IA ya tienen acceso a correo, almacenamiento, CRM, formularios o gestores de contenido. A menudo el primer paso es hacer inventario: qué agente existe, quién lo configuró, qué datos puede leer y qué acciones puede ejecutar.

En una web profesional, por ejemplo, un asistente que redacta borradores puede funcionar sin permiso para publicar. Si se conecta a WordPress, es preferible que empiece con una cuenta limitada y un flujo de revisión humana antes de publicar entradas, cambiar ajustes o instalar extensiones. Para automatizar formularios de contacto o respuestas a clientes, conviene probar primero con datos ficticios y mantener una revisión de los mensajes que saldrán al exterior.

Estas medidas son especialmente útiles cuando se combinan varios servicios. Una automatización puede leer un correo, consultar un documento, actualizar un registro y enviar una respuesta. Cada conexión añade una frontera de confianza que debe revisarse. Un error no necesita ser sofisticado para convertirse en un problema si el sistema tiene permisos amplios y no existe una confirmación antes del paso decisivo.

Si tu negocio utiliza IA para crear contenido, gestionar una web o automatizar tareas, el criterio práctico es sencillo: empieza por lo reversible, separa los borradores de las acciones reales y amplía los permisos solo después de probar el flujo. El diseño de una experiencia segura también forma parte del trabajo profesional: los controles deben ser comprensibles, visibles y situarse en el momento en que la persona necesita decidir.

¿Quién responde cuando el agente se equivoca?

La responsabilidad no desaparece porque una operación la haya ejecutado un modelo. En una organización, alguien decide qué herramienta se despliega, qué datos recibe, qué permisos se le conceden y qué supervisión existe. El proveedor puede ser responsable de componentes de su producto y el cliente de la configuración y el uso, pero el reparto concreto depende del servicio, los contratos y la normativa aplicable. No es correcto afirmar que siempre responde una sola parte en todos los escenarios.

Por eso la gobernanza debe definirse antes de automatizar: quién aprueba acciones de riesgo, quién recibe las alertas, quién puede detener el sistema y quién revisa un incidente. También debe comunicarse a los usuarios cuándo interactúan con un agente y qué puede hacer en su nombre. La transparencia evita que se confunda una recomendación con una operación ya realizada.

Los análisis de Anthropic sobre agentes fiables también destacan que la autonomía abre nuevos riesgos de gobernanza y de manipulación mediante instrucciones maliciosas. Los agentes pueden ahorrar tiempo y facilitar tareas repetitivas, pero la autonomía debe crecer al ritmo de los controles. Los incidentes divulgados en 2026 no prueban que estas herramientas sean incontrolables; sí muestran que una buena intención o una instrucción clara no sustituyen a una arquitectura segura. La pregunta útil no es si podemos confiar ciegamente en la IA, sino qué límites hacen que un error sea detectable, reversible y de alcance reducido.

Preguntas frecuentes sobre la seguridad de los agentes de IA

¿Un agente de IA puede actuar sin que yo lo confirme?

Depende del producto y de la configuración. Algunos sistemas solo proponen acciones; otros pueden ejecutar tareas previamente autorizadas. Antes de conectarlo a una cuenta, revisa qué herramientas tiene habilitadas y qué operaciones exigen confirmación.

¿El caso de Filadelfia demuestra que una IA hackeó a la policía?

No. Según AP, el modelo rellenó un formulario público que fue marcado como spam y no llegó a los investigadores. La información publicada no demuestra que accediera a sistemas internos ni que comprometiera datos policiales. Es importante no exagerar lo ocurrido para entender su lección de seguridad.

¿Basta con escribir instrucciones para que el agente no cometa errores?

No. Las instrucciones ayudan a definir el comportamiento esperado, pero deben complementarse con permisos mínimos, aislamiento, aprobación para acciones sensibles, registros y capacidad de detener el proceso. Los controles técnicos reducen el impacto si el modelo interpreta mal la tarea.

¿Qué debería hacer una empresa antes de implantar agentes?

Definir el caso de uso, asignar un responsable, limitar datos y permisos, probar en un entorno aislado, establecer aprobaciones y comprobar que es posible auditar y revocar el acceso. Es preferible ampliar la autonomía de forma gradual que conceder todos los permisos desde el primer día.

Conclusión: automatizar no significa renunciar al control

La nueva generación de agentes amplía lo que la inteligencia artificial puede hacer, pero también cambia el tipo de riesgo. Cuando un sistema puede interactuar con webs, cuentas y datos, la seguridad debe proteger no solo la información, sino también las acciones que se ejecutan en nombre de una persona u organización.

La fórmula más sólida combina permisos mínimos, aprobaciones para operaciones de impacto, entornos de prueba aislados, registros útiles y un procedimiento probado para detener al agente. No elimina todos los fallos, pero evita depender exclusivamente de que el modelo interprete cada situación de forma correcta. Y esa es la condición para aprovechar la automatización sin entregar el control.