Los permisos estáticos responden “¿puede llamarse esta herramienta?”. Un sistema agéntico también necesita responder “¿puede llamarse ahora, después de esta secuencia y con esta evidencia?”.
La mayoría de sistemas de control de acceso evalúan una acción de forma aislada. Un principal puede leer un registro, llamar a una API o actualizar un objeto si la petición actual cumple la política.
Los agentes introducen un problema temporal. La seguridad de la siguiente acción puede depender de todo lo ocurrido antes.
AWS hizo concreta esta idea en agosto de 2026 con políticas temporales para AgentCore: reglas de autorización con estado capaces de imponer secuencias, vincular un argumento actual con el resultado de una tool call previa, exigir aprobación antes de acciones privilegiadas y comprobar frescura de datos.
La lección arquitectónica va más allá de una plataforma.
La secuencia forma parte del significado
Pensemos en un flujo de trabajo de pago a proveedores.
Cualquiera de estas acciones puede estar permitida:
- leer el proveedor;
- leer una factura;
- modificar datos de pago;
- liberar un pago.
Pero una secuencia:
cambiar cuenta bancaria → liberar inmediatamente el pago
debería tener una política muy distinta de:
leer factura → comparar contrato → proponer pago → obtener aprobación → liberar
Los permisos de herramientas son idénticos. El significado de la secuencia, no.
La gobernanza agéntica necesita por tanto una noción de estado del flujo de trabajo.
Las precondiciones deben poder comprobarse por máquina
Los procedimientos humanos incluyen frases como:
“Solo aprobar si se ha revisado el informe de análisis previo más reciente.”
En un sistema agéntico esa regla debería convertirse en evidencia ejecutable:
- ID del resultado;
- timestamp;
- fuente;
- estado;
- revisor o política;
- relación con la acción solicitada.
El runtime puede entonces rechazar una operación privilegiada si la evidencia falta, está obsoleta o pertenece a otro caso.
Eso es más fuerte que escribir la instrucción en el system prompt. El prompt indica al agente qué debería hacer. La política decide qué puede hacer.
La aprobación es un evento, no un booleano
Revisión humana suele implementarse con un “approved = true” genérico. Es demasiado débil para procesos serios.
Un registro útil de aprobación debería responder:
- quién aprobó;
- qué acción exacta;
- contra qué snapshot de datos;
- para qué importe o alcance;
- cuándo expira;
- si los parámetros pueden cambiar después;
- si una acción posterior ya consumió esa aprobación.
Una aprobación de 5.000 € no debería autorizar silenciosamente 50.000 € porque el agente modificó un argumento después.
La aprobación pertenece a una transición de estado.
Los rate limits pertenecen junto a la política temporal
AWS anunció rate limiting junto con controles temporales y tiene sentido arquitectónico. Una acción segura de forma individual puede volverse insegura repetida 10.000 veces.
En sistemas agénticos la política debería considerar:
qué × cuándo × después de qué × cuántas veces × en nombre de quién
Un agente de atención puede emitir un pequeño crédito, pero solo un número limitado por cliente, agente y día. Un agente de seguridad puede consultar un sistema sensible, pero no con concurrencia ilimitada.
La frecuencia cambia el riesgo.
Diseñar máquinas de estado donde el negocio lo merece
No todo agente necesita una state machine formal. Pero los procesos de alto impacto se benefician de fases explícitas:
RECOPILAR → VERIFICAR → PROPONER → APROBAR → EJECUTAR → CONFIRMAR
Cada transición puede declarar:
- evidencia requerida;
- herramientas permitidas;
- identidades autorizadas;
- límites temporales;
- reversión;
- salida de auditoría.
El modelo puede decidir cómo recopilar evidencia dentro de una fase. No debería poder inventarse la secuencia de control.
Este diseño híbrido conserva flexibilidad de razonamiento dentro de una gobernanza determinista.
La visión de Lexdatum
La siguiente generación de salvaguardas no será un filtro alrededor de un prompt. Será política con estado alrededor de acciones empresariales.
El principio práctico es simple:
El runtime debe conocer suficiente contexto del flujo de trabajo para rechazar una acción localmente válida pero globalmente insegura.
Esa es la diferencia entre permisos para software y gobernanza para agentes.
Sources
Nota de investigación: este análisis se basa en información pública disponible el 1 de septiembre de 2026. Las capacidades de producto, precios e interpretaciones regulatorias pueden cambiar. Las afirmaciones de proveedores se identifican como tales. No constituye asesoramiento jurídico, de seguridad, financiero ni de inversión.