Permisos y credenciales en automatizaciones con IA: cómo evitar que un agente pueda hacer más de lo necesario

El riesgo no empieza cuando el agente se equivoca, sino cuando puede ejecutar demasiado

Un equipo crea un agente para consultar información de clientes y preparar respuestas. Durante el piloto, la conexión al CRM se hace con una cuenta administrativa porque es la forma más rápida de comprobar que la integración funciona. La demostración sale bien: el agente localiza contactos y prepara respuestas con contexto.

El problema aparece después: la cuenta que solo necesitaba consultar clientes también puede modificar campos, exportar información, borrar registros o cambiar configuraciones. El agente nunca necesitó esas capacidades. Simplemente nadie las retiró cuando el piloto dejó de ser una prueba.

Este patrón es especialmente importante en agentes de IA porque el sistema no se limita a ejecutar una secuencia fija. Puede interpretar lenguaje natural, elegir una herramienta y construir los parámetros de una acción. Esa flexibilidad es precisamente lo que hace útiles a muchos agentes, pero también obliga a separar dos preguntas:

• ¿Qué puede decidir o proponer el agente?
• ¿Qué puede ejecutar realmente en los sistemas conectados?

La primera depende del diseño del agente, del modelo, de las instrucciones y del contexto. La segunda debería depender de controles externos: identidades, credenciales, permisos, herramientas, validaciones y políticas.

En nuestra guía sobre workflow frente a agente de IA explicamos cuándo una tarea necesita decisiones contextuales y cuándo conviene mantener una secuencia determinista. Aquí partimos de un caso distinto: ya hemos decidido utilizar un agente con herramientas y queremos limitar su capacidad real de actuar.

Cinco capas de control: identidad, credencial, permiso, herramienta y aprobación

En muchas conversaciones empresariales estas palabras se mezclan. “El agente tiene acceso al CRM” puede significar varias cosas muy diferentes. Para diseñar bien el control conviene separar cinco capas.

La separación es importante porque una capa puede limitar a la anterior. Una credencial puede tener permiso de escritura, pero la herramienta expuesta al agente puede permitir únicamente añadir una nota. Y aunque esa herramienta exista, una política puede exigir una aprobación antes de utilizarla en determinados casos.

Dar acceso técnico no equivale a dar autonomía operativa. Esa diferencia es una de las decisiones más importantes cuando una automatización incorpora IA.

Qué significa dar al agente solo los permisos que necesita

NIST define el principio de mínimo privilegio como restringir recursos y autorizaciones al mínimo necesario para realizar las tareas asignadas. En un proyecto empresarial no hace falta convertir esa idea en terminología de seguridad. Se puede traducir a decisiones muy concretas.

Google aplica una lógica equivalente en sus políticas OAuth: las aplicaciones deben solicitar el conjunto de scopes —alcances de autorización— más pequeño necesario para la funcionalidad elegida por el usuario. Microsoft Graph recomienda igualmente utilizar los permisos menos privilegiados necesarios para que la aplicación funcione.

Esto no significa que “menos permisos” sea siempre una decisión trivial. Una lectura amplia puede ser muy sensible si permite acceder a información confidencial de miles de clientes. En cambio, una escritura muy acotada puede ser aceptable si solo crea una tarea reversible y queda registrada.

Por eso, el diseño debería combinar alcance, sensibilidad, impacto y reversibilidad. No basta con etiquetar una operación como lectura o escritura.

Las credenciales no deben estar dentro del prompt

Una API key o un token no son información que el modelo necesite “conocer”. Son mecanismos que permiten a una aplicación demostrar quién es o qué acceso tiene frente a otro sistema. Por eso deberían gestionarse en la infraestructura destinada a secretos y credenciales, no aparecer en instrucciones, documentos de contexto o mensajes accesibles innecesariamente al modelo.

La arquitectura puede utilizar la credencial para ejecutar una herramienta sin que el valor secreto forme parte del contexto que interpreta la IA. Esa separación reduce exposición innecesaria y facilita otras tareas básicas: rotar una credencial, revocarla, cambiarla por entorno o saber quién es responsable de ella.

Algunas prácticas razonables son:

• Guardar secretos en mecanismos destinados a credenciales, no en prompts o documentos compartidos.
• Separar credenciales por aplicación, entorno o función cuando el proveedor y la arquitectura lo permitan.
• Evitar utilizar una cuenta administrativa personal como llave universal para varios agentes.
• Definir propietario y mecanismo de revocación antes de pasar a producción.
• Retirar credenciales y permisos que ya no se utilicen en lugar de acumular accesos históricos.

RFC 9700, publicado por el IETF como Best Current Practice para OAuth 2.0, actualiza recomendaciones de seguridad sobre clientes, tokens y mecanismos de autorización. No convierte OAuth en una garantía automática de seguridad, pero sí refuerza una idea útil para cualquier proyecto: la gestión de credenciales forma parte del diseño del sistema, no es un detalle que se resuelve al final.

Permisos delegados y permisos de aplicación: cuándo utilizar cada uno

Cuando una automatización accede a Microsoft 365, Google Workspace u otros servicios empresariales, suele aparecer una decisión básica: ¿el sistema actúa en nombre de una persona o actúa con una identidad propia?

En un acceso delegado, la aplicación actúa en nombre de una persona que se ha autenticado. La capacidad efectiva puede depender tanto de lo que esa persona puede hacer como de los permisos concedidos a la aplicación.

En un acceso de aplicación —o un modelo equivalente con identidad propia— el proceso actúa sin que una persona tenga que iniciar sesión en cada acción. Esto puede ser necesario para trabajos de back-office, procesos nocturnos o automatizaciones que deben funcionar aunque un empleado concreto no esté conectado.

Microsoft Graph distingue expresamente ambos escenarios y recomienda pedir los permisos menos privilegiados posibles. En términos empresariales, la pregunta práctica es: ¿queremos que el agente herede el contexto de una persona concreta o que disponga de una identidad operativa propia y acotada?

Una cuenta propia puede facilitar trazabilidad y continuidad, pero no sirve de nada si se configura con permisos generales sobre toda la organización. Una cuenta delegada puede limitar el alcance, pero también puede heredar más capacidad de la necesaria si el usuario tiene privilegios amplios.

La integración puede hacer mucho más de lo que debería ver el agente

Este es uno de los controles más útiles en una arquitectura con agentes. Supongamos que una integración con el CRM utiliza una credencial que permite leer y escribir. Eso no obliga a ofrecer al modelo una herramienta genérica del tipo “haz cualquier petición al CRM”.

La capa de herramientas puede traducir una integración amplia en capacidades estrechas y comprensibles:

• Consultar cliente.
• Consultar oportunidad.
• Añadir nota.
• Crear tarea.
• Preparar cambio de estado para validación.

Cuanto más concreta sea la herramienta, menos libertad innecesaria recibe el agente. Además, sus parámetros pueden validarse antes de ejecutar: identificadores válidos, campos permitidos, límites de volumen, formato de fechas o reglas de negocio.

Anthropic documenta, por ejemplo, la posibilidad de restringir qué herramientas de un servidor MCP están disponibles mediante allowed_tools. OpenAI permite limitar el conjunto de herramientas disponible y definir políticas de aprobación para llamadas MCP. Estos mecanismos son ejemplos de producto, no una arquitectura obligatoria. Lo importante es el principio: conectar un sistema y exponer una acción al modelo son decisiones diferentes.

La guía sobre MCP en empresas desarrolla cuándo este protocolo aporta valor frente a APIs o integraciones tradicionales. Aquí basta con entender que, exista MCP o no, la capa que entrega herramientas al agente debería actuar como frontera de capacidad.

Leer, escribir, borrar y ejecutar no deberían tratarse igual

Una matriz sencilla de impacto ayuda más que una regla genérica de “toda escritura necesita aprobación”. El objetivo es diferenciar qué puede ocurrir si la acción es incorrecta y cuánto cuesta revertirla.

Una lectura no es necesariamente inocua. Un agente que solo “consulta” puede tener acceso a contratos, salarios, historiales o información de clientes que nunca necesita para su tarea. Del mismo modo, una escritura puede ser poco problemática si únicamente crea un borrador que una persona revisará después.

El nivel de control debería responder a cinco variables: impacto, reversibilidad, sensibilidad, frecuencia y capacidad de detectar un error.

Tener permiso técnico no significa que una acción deba ejecutarse sin aprobación

Un agente puede disponer legítimamente de una herramienta y, aun así, necesitar una condición adicional antes de utilizarla. La aprobación funciona como una segunda barrera para determinados casos.

Por ejemplo, consultar un registro autorizado o crear un borrador puede ser automático. Enviar una comunicación sensible, eliminar un registro o ejecutar una operación económica puede requerir una aprobación según las reglas del proceso.

OpenAI documenta políticas de aprobación para llamadas a herramientas MCP, incluyendo opciones para exigir aprobación siempre, nunca o mediante filtros asociados a determinadas herramientas o acciones de solo lectura. El detalle técnico puede variar entre plataformas; el principio empresarial es estable: “la herramienta existe” y “el agente puede ejecutarla sin una segunda comprobación” son decisiones diferentes.

Esto no convierte la entrada en una repetición de nuestra guía sobre human-in-the-loop. Allí el foco es cuándo debe intervenir una persona dentro del proceso. Aquí la aprobación aparece únicamente como una de las barreras posibles cuando el permiso técnico es más amplio que la autonomía que queremos conceder.

Qué ocurre si el agente interpreta mal un correo, documento o mensaje externo

Los agentes empresariales suelen trabajar con información que no controla la organización por completo: correos recibidos, archivos de terceros, formularios, páginas web o mensajes de clientes. Ese contenido puede ser ambiguo, erróneo o incluso intentar influir en el comportamiento del sistema.

Aquí basta con entender la consecuencia para los permisos: el modelo puede interpretar contenido que no debe tener autoridad para ampliar su propia capacidad.

Si un correo contiene una frase que parece una orden, el agente puede analizarla. Lo que no debería ocurrir es que esa frase cambie los permisos reales del sistema o habilite herramientas que estaban bloqueadas. Las barreras de autorización deben vivir fuera del texto que procesa el modelo.

Este diseño no elimina todos los riesgos. Sí limita el posible impacto de una interpretación incorrecta: si el agente solo puede consultar un cliente y crear una tarea, un error no debería transformarse por arte de magia en permiso para exportar la base completa o borrar registros.

Dónde vive cada control en una arquitectura de agentes

Para dirección no es necesario entrar en librerías o diagramas de infraestructura. Es suficiente con separar cuatro zonas.

La idea clave es que el modelo no decide por sí solo qué permisos tiene. Puede decidir qué herramienta parece apropiada dentro del conjunto que se le ofrece, pero la autorización debe imponerse mediante credenciales, scopes, funciones disponibles, reglas y validaciones.

Esta separación también facilita el mantenimiento: cambiar de modelo o de sistema de destino no debería obligar a redefinir desde cero qué puede hacer el agente.

Errores habituales que se arrastran del piloto a producción

Muchos problemas de permisos no nacen de una decisión deliberada de dar demasiado acceso. Aparecen porque, durante una prueba, se elige la configuración que permite avanzar más rápido y esa configuración termina llegando a producción sin una revisión específica.

Un caso habitual es reutilizar una cuenta de administrador porque “funciona para todo”. Otro es compartir la misma API key entre varios flujos, de forma que después resulte difícil saber qué automatización hizo una llamada concreta o revocar únicamente una de ellas. También es frecuente conceder lectura y escritura cuando solo hacía falta consultar información, o exponer una herramienta genérica porque evita crear varias funciones más estrechas.

Hay otros fallos menos visibles: mantener permisos de pruebas cuando cambia el alcance del proyecto, no saber quién es responsable de una credencial, guardar secretos en documentos de configuración accesibles a demasiadas personas o carecer de un procedimiento claro para retirar el acceso cuando se desactiva un agente.

También conviene revisar el sentido contrario. Reducir permisos sin comprobar el proceso puede romper tareas necesarias y generar excepciones manuales. El objetivo no es retirar acceso de forma indiscriminada, sino hacer coincidir cada capacidad con una necesidad operativa identificada.

Cómo auditar qué puede hacer realmente un agente

Antes de ampliar autonomía, conviene dejar de hablar en términos generales y hacer inventario. “Tiene acceso al CRM y al correo” es demasiado poco preciso para gobernar una automatización.

Una auditoría inicial puede registrar, para cada sistema conectado:

La auditoría suele revelar problemas más simples que un sofisticado ataque informático: cuentas de administrador reutilizadas, API keys compartidas entre entornos, permisos de pruebas que siguen activos en producción, herramientas demasiado genéricas o credenciales cuyo propietario ya nadie identifica.

También permite medir algo que suele ignorarse. En lugar de contar solo respuestas correctas del agente, podemos seguir indicadores de control: número de sistemas accesibles, herramientas expuestas, acciones de escritura disponibles, operaciones que requieren aprobación o credenciales sin propietario identificado. Estas métricas describen la superficie de acceso; no demuestran seguridad absoluta.

La evaluación del comportamiento sigue siendo necesaria. Nuestra guía sobre cómo evaluar un agente antes de darle más autonomía explica cómo trabajar con casos normales, casos límite y regresiones. Pero incluso un agente que obtiene buenos resultados en esas pruebas debería conservar límites técnicos coherentes con la tarea.

Ampliar autonomía no debería significar ampliar todos los permisos de golpe

En muchos pilotos resulta más prudente empezar por una capacidad limitada y ampliar después con evidencia. No como una escalera obligatoria, sino como patrón de diseño.

Un agente puede empezar consultando información y preparando una recomendación. Después puede crear borradores o tareas que sean fáciles de corregir. Más adelante, si el proceso está bien entendido y las excepciones están controladas, puede ejecutar determinadas acciones de escritura de forma autónoma.

Las operaciones de mayor impacto no tienen por qué llegar nunca a ser totalmente autónomas. Eso no convierte al sistema en “menos inteligente”. Significa que la organización ha decidido dónde la autonomía aporta valor y dónde una segunda barrera sigue siendo adecuada.

La autonomía, por tanto, no debería medirse solo por cuánto decide el modelo. También por cuánto puede ejecutar sin una comprobación externa.

Qué revisar antes de pasar un agente a producción

Una revisión inicial no sustituye una auditoría de seguridad. Sirve para detectar configuraciones evidentes antes de operar con datos y sistemas reales.

• Existe una identidad adecuada para la automatización cuando el proveedor y el caso lo permiten.
• La credencial tiene un propietario claro y no depende de una cuenta personal olvidada.
• Los permisos se corresponden con las tareas reales, no con todo lo que permite la integración.
• Lectura y escritura están separadas cuando el sistema ofrece permisos suficientemente granulares.
• El agente solo ve las herramientas necesarias para el proceso concreto.
• Las operaciones sensibles tienen una regla, validación o aprobación adicional cuando su impacto lo justifica.
• Los secretos están fuera de prompts y documentos de contexto.
• Existe una forma conocida de revocar y rotar las credenciales.
• Las acciones y resultados importantes quedan registrados.
• Se ha probado qué ocurre cuando una herramienta falla, devuelve un resultado inesperado o el agente construye parámetros incorrectos.

Si varias de estas respuestas son “no sabemos”, el problema no es necesariamente el agente. Puede ser que la arquitectura todavía no haya definido bien sus límites.

Preguntas frecuentes sobre permisos y credenciales de agentes de IA

Antes de dar más autonomía, conviene saber exactamente qué puede hacer el agente

Si vuestra automatización con IA ya consulta sistemas empresariales, crea registros, prepara comunicaciones o ejecuta acciones, podemos revisar la arquitectura desde una pregunta muy concreta: qué puede leer, modificar y ejecutar realmente cada agente, con qué identidad y bajo qué controles.

El resultado no tiene por qué ser “poner aprobación humana a todo”. Puede ser reducir un permiso, separar una credencial, crear una herramienta más estrecha, añadir una validación o mantener determinada acción fuera del alcance del agente.