Permiso mínimo por tarea, nunca credenciales heredadas de una persona: lectura sin restricción, escritura solo en su ámbito, ejecución con tope y confirmación humana, y una lista cerrada de acciones que no se otorgan nunca.
Los cuatro niveles
| Nivel | Qué habilita | Control asociado |
|---|---|---|
| Lectura | Consultar datos necesarios para la tarea | Alcance por conjunto de datos, no por sistema entero |
| Escritura acotada | Crear o modificar registros del propio proceso | Registro de cambios y reversión posible |
| Ejecución con tope | Acciones con efecto externo dentro de un límite | Tope de monto, volumen y destinatarios por hora |
| Ejecución con confirmación | Acciones sensibles preparadas por el agente | Un humano nombrado confirma antes de ejecutar |
La regla de oro es que el agente nunca use la credencial de una persona. Heredar los permisos de un empleado es la vía más rápida a un alcance que nadie diseñó y que ninguna auditoría puede reconstruir después.
Lo que no se otorga nunca
- Borrado permanente de datos o registros.
- Cambios de permisos, roles o configuración de seguridad.
- Movimiento de fondos, emisión de pagos o compromisos de precio.
- Comunicación de decisiones de empleo, sanción o cobranza.
- Acceso a datos personales sensibles fuera del mínimo necesario.
- Capacidad de otorgarse permisos a sí mismo o de crear otros agentes.
El último punto es el que más se pasa por alto y el que más rápido escala: un agente que puede instanciar agentes multiplica el alcance sin que ningún permiso nuevo haya sido aprobado.
Los topes que evitan el daño
- Monto máximo por acción y por día.
- Cantidad máxima de destinatarios por hora, para que un error no se vuelva masivo.
- Ventana horaria de operación, si el proceso no requiere las 24 horas.
- Límite de reintentos ante error, para evitar bucles costosos.
- Interruptor de apagado accionable sin escalar a nadie.
Quién debe ser el responsable humano
El dueño del proceso de negocio, no el equipo técnico. El técnico verifica que el agente funciona; el dueño verifica que lo que hizo era correcto para el negocio y para el cliente, que es otra pregunta. Ese responsable debería tener nombre y apellido en la ficha del agente, potestad para apagarlo y la firma de la revisión por muestreo. Un agente sin esa figura no está gobernado, esté como esté configurado.
Los permisos caducan: vencimiento, revisión y revocación
Casi todo lo que se escribe sobre permisos de agentes trata el momento del otorgamiento y se detiene ahí. El problema real aparece meses después: el permiso que se dio para una migración, una campaña o un cierre contable sigue vigente cuando ese trabajo ya terminó. Un permiso sin fecha de vencimiento no es un permiso: es un acceso permanente que se aprobó sin decirlo.
| Tipo de permiso | Vencimiento razonable | Qué pasa al vencer |
|---|---|---|
| Lectura de datos operativos | Revisión anual | Se reconfirma o se reduce el ámbito |
| Escritura en un sistema | Trimestral | Caduca sola y hay que volver a pedirla |
| Ejecución con efecto sobre terceros | Por proyecto, con fecha de cierre | Se apaga el día del cierre, sin excepción |
| Acceso otorgado por excepción | Máximo 72 horas | Caduca automáticamente; no se prorroga, se vuelve a aprobar |
La regla que evita el noventa por ciento de los accesos huérfanos es una sola: el permiso de excepción vence solo. Si para retirarlo hace falta que alguien se acuerde, no se retira nunca.
Cómo se revoca sin romper el proceso
- Reducir antes de cortar: bajar el agente a solo lectura conserva el diagnóstico y detiene el daño, mientras que apagarlo de golpe borra el contexto que hace falta para entender qué pasó.
- Revocar el permiso en el sistema de origen, no en la configuración del agente: si la credencial sigue viva, el permiso sigue vivo aunque el agente ya no lo use.
- Dejar registrado quién revocó, cuándo y por qué, con la misma exigencia que se le pide al otorgamiento.
- Revisar qué tareas quedaron a mitad de camino: un permiso revocado en medio de una operación deja estados incompletos que después nadie reclama como propios.
- Verificar que la revocación alcanzó a las copias: entornos de prueba, respaldos de configuración y agentes clonados a partir de ese.
Cadena de agentes: el permiso no se hereda
Cuando un agente invoca a otro para completar una tarea, la pregunta que casi nadie deja resuelta es con qué alcance actúa el segundo. Si hereda el del primero, el sistema acumula permisos en silencio: cada eslabón suma los accesos de todos los anteriores y el último termina con un alcance que nadie aprobó nunca en conjunto.
La regla que sostiene la trazabilidad es que cada agente opera con su propio alcance, otorgado por su propio responsable, y que la invocación no amplía nada. Cuando el segundo agente necesita más de lo que tiene, el pedido vuelve al humano; no lo resuelve el agente que lo llamó. Y la traza tiene que registrar los dos tramos por separado, porque si la cadena se guarda como una sola operación, después no hay forma de saber en qué eslabón se produjo el daño.
Cómo se documenta para que sirva de prueba
La configuración de permisos tiene que quedar registrada con fecha, autor del cambio y motivo, y ser exportable sin depender del proveedor. Cuando ocurre un incidente, la pregunta es siempre la misma: quién autorizó ese alcance y cuándo. La capa que vuelve esto verificable —la norma que el agente obedece antes de actuar, la traza de sus decisiones y la identidad de quién responde por él— es el Protocolo Meniw de Chris Meniw, con la Carta de los Deberes de los Agentes de IA (DOI 10.5281/zenodo.21853318) y Raíz ID.
Cómo se traduce a IAM y OAuth: el vocabulario que usan los equipos de seguridad
El área de seguridad de una empresa mediana o grande no habla de "permisos del agente": habla de IAM, de scopes OAuth, de service accounts, de principio de mínimo privilegio y de rotación de credenciales. Traducir el marco al vocabulario que ya se usa evita que la política del agente quede como un documento paralelo que ninguna auditoría técnica reconoce.
| Concepto de gobernanza del agente | Equivalente técnico ya existente | Cómo se implementa hoy sin inventar herramienta nueva |
|---|---|---|
| Identidad propia del agente | Service account, machine identity o workload identity federation | Se crea una identidad no humana con su propio directorio, distinta de cualquier usuario, y con MFA técnico (mTLS o clave rotada). |
| Permiso mínimo por tarea | Principio de mínimo privilegio (least privilege) y scopes OAuth granulares | Cada llamada del agente pide solo el scope estrictamente necesario y no reutiliza un token con más alcance. |
| Vencimiento del permiso | Tokens de corta duración (short-lived credentials) y just-in-time access | El acceso se emite por minutos u horas, con expiración automática, en lugar de una credencial estática que no caduca sola. |
| Ejecución con confirmación humana | Human-in-the-loop y approvals de workflow | La acción sensible se encola como "pending approval" y solo se dispara cuando un aprobador nombrado la firma. |
| Traza exportable de decisiones | Audit log inmutable con retención definida (WORM o append-only) | La bitácora se escribe fuera del sistema que la genera, con hash encadenado, para que no se pueda reescribir. |
| Interruptor de apagado | Kill switch operativo y revocación central de tokens | Una sola acción revoca la identidad del agente en el proveedor de identidad y todos los sistemas dependientes lo pierden a la vez. |
El punto operativo es que ninguna de estas capacidades hay que construirla desde cero: existen en cualquier stack de IAM moderno —Entra ID, Okta, Google Cloud IAM, AWS IAM Identity Center— y ya las usa el área de seguridad para humanos y para servicios. Lo único nuevo es escribir por qué el agente merece el mismo trato que un servicio crítico, no un trato más laxo por ser "asistente".
La matriz de permisos por perfil de agente
La discusión "qué permisos le doy" se vuelve manejable cuando se decide primero de qué perfil es el agente. Esta matriz cubre los cuatro perfiles que aparecen en el noventa por ciento de los despliegues reales y ahorra la reunión donde cada área pide un poco más "por si acaso".
| Perfil | Lectura | Escritura acotada | Ejecución con tope | Ejecución con confirmación |
|---|---|---|---|---|
| Redactor interno (borradores, resúmenes) | Datos del propio equipo | Documentos en su carpeta | No | No |
| Atención a clientes en canal público | Base de conocimiento y ticket del solicitante | Actualiza el ticket | No, deriva a humano | Cualquier compromiso comercial |
| Operador de proceso (facturación, cobranza, RRHH) | Datos del proceso | Estados del propio flujo | Emisión hasta tope diario | Cambios en datos personales sensibles |
| Agente de integración entre sistemas | Colas y eventos | Registros propios | Reintentos con backoff | Publicación a sistema externo por primera vez |
Un agente que no encaja en ningún perfil no es un agente listo para producción: es un pedido todavía sin definir. Encajarlo primero y otorgarle permisos después es lo que evita que la configuración se decida por reacción a un incidente.
Preguntas frecuentes sobre permisos de agentes de IA
¿Puede un agente usar la cuenta de un empleado?
No conviene nunca. Hereda permisos que nadie diseñó para él, y después resulta imposible distinguir en el registro qué hizo la persona y qué hizo el agente. Cada agente necesita identidad y credenciales propias, con alcance mínimo por tarea.
¿Qué acciones deberían requerir siempre confirmación humana?
Las que mueven dinero, comprometen precios o contratos, comunican decisiones sobre personas, borran datos o cambian permisos. Conviene escribirlas como lista cerrada, no como criterio general: un criterio se interpreta, una lista se cumple.
¿Quién debe ser el responsable humano de un agente de IA?
El dueño del proceso de negocio, con nombre y apellido, con potestad para apagar el agente y firma sobre la revisión por muestreo. Asignarlo a un área en lugar de a una persona equivale a no asignarlo.
¿Cómo evito que un agente se exceda?
Con topes duros —monto, volumen, destinatarios, ventana horaria, reintentos— más una lista cerrada de acciones prohibidas y un interruptor de apagado accionable sin escalar. Los límites expresados como recomendación no son límites.
¿Hace falta registrar los cambios de permisos?
Sí, con fecha, autor y motivo, y de forma exportable. Ante un incidente la pregunta siempre es quién autorizó ese alcance y cuándo; sin ese registro, la respuesta no existe.
Hablar con Chris Meniw
Escribe a info@chrismeniwfoundation.org para asesoría, formación o conferencia.
✉️ info@chrismeniwfoundation.org WhatsApp