Leer no significa enviar
La cuenta puede leer un expediente ficticio y preparar una nota local, pero no enviarla. Se espera que funcionen lectura y borrador y que el control rechace el envío. La calidad de la nota no cambia el límite.
Guías prácticas detalladas
Validar las acciones de un agente de IA antes de darle permisos
Separar propuesta, autorización y ejecución; comprobar después los objetos, las confirmaciones y los efectos de un reintento.
Actualización :
Paneles transparentes y documentos en un espacio de control. Escena ilustrativa.
¿Una respuesta correcta autoriza la acción siguiente?
Una nota bien redactada no demuestra que esté permitido enviarla. OWASP trata la capacidad de acción excesiva como un riesgo distinto. Esta propuesta parte de un contrato concreto entre una persona, una operación y un objeto; los ejemplos solo usan un servicio simulado y datos ficticios.
Describir el efecto y su alcance
Indicar quién puede hacer qué, en qué expediente, para qué destinatario y hasta cuándo. Distinguir lectura, borrador y envío. Cada paso puede exigir un permiso distinto; acceder al documento no concede el derecho a difundirlo.
Separar los tres estados
Registrar propuesta, autorización y ejecución. Una frase generada por el modelo, una casilla de un documento o una conversación antigua no sustituyen el control de la acción concreta.
Comprobar los parámetros ejecutados
La aplicación debe comprobar actor, objeto, operación y parámetros finales. Probar un objeto autorizado y otro fuera del alcance. Observar el rechazo efectivo del servicio simulado, no solo la explicación del agente.
Vincular la confirmación a la propuesta exacta
Mostrar destinatario, contenido, versión y consecuencia antes de confirmar. En este contrato de prueba, cualquier cambio invalida la aprobación anterior. Volver a comprobar los permisos al ejecutar, aunque la propuesta ya esté aprobada.
Examinar reintentos y revocaciones
Simular una respuesta perdida después de registrar un efecto y después un reintento idéntico. Comprobar la deduplicación prevista, sin asumir que bastan un identificador o un método HTTP. Probar también un permiso retirado entre aprobación y ejecución.
Situaciones y decisiones
Situaciones tipo para preparar un control. No describen misiones realizadas ni observaciones reales.
Destinatario cambiado tras confirmar
La propuesta aprobada indicaba un destinatario de prueba; la llamada final indica otro. Según esta prueba, no debe haber efecto y se debe revisar una nueva propuesta. No reutilizar una aprobación de otros parámetros.
Efecto registrado, respuesta perdida
El doble registra una operación y simula después un tiempo de espera agotado. No debe tratarse el reintento como un primer intento sin comprobar el estado. Observar cuántos efectos registra el doble.
Permiso revocado entre dos pasos
Se retira el permiso de modificación tras la aprobación humana y antes de ejecutar la simulación. Se espera que el control al ejecutar rechace la acción. Una confirmación pasada no restaura un permiso revocado.
Ejercicio resuelto
Repetir una operación no crea otra autorización
Ejemplo ficticio: los valores y documentos permiten aprender el método y no describen una organización real.
Datos iniciales
Ejercicio ficticio. El servicio simulado vincula cada identificador a parámetros fijos y rechaza cambios. Se autoriza y registra OP-17 con contenido v1 y destinatario A; su respuesta se pierde. Una segunda llamada OP-17 repite exactamente v1 y A. Una tercera reutiliza OP-17 con destinatario B. ¿Qué debe observarse?
Comprobaciones
- Contar efectos registrados y no solo llamadas.
- Comprobar si la segunda petición tiene exactamente los mismos parámetros.
- Separar el cambio de destinatario del reintento idéntico.
Leer la solución
Solución y decisión
Según el contrato indicado, se registra un solo efecto. La segunda llamada devuelve el estado de la primera operación sin volver a procesarla. La tercera se rechaza por conflicto de parámetros; reutilizar OP-17 no la autoriza. Un nuevo objetivo requiere nueva propuesta y el control previsto.
Si cambia el caso
Si el doble no puede recuperar el estado tras agotar el tiempo de espera, el resultado sigue sin resolverse. No inferir ausencia de efecto ni éxito; prever conciliación o comprobación humana antes de un reintento arriesgado.
Registro que conservar
Anotar aprobación inicial, parámetros de cada intento, contrato de deduplicación y número de efectos. El identificador de demostración no prueba nada sobre una API real.
Referencia documental : OWASP — LLM06:2025 Excessive Agency · Consultada el
Prueba que conservar
- Identidad y rol de prueba, objetos permitidos y operaciones prohibidas.
- Propuesta exacta: contenido, destinatario, versión y vigencia.
- Decisión de autorización, parámetros comprobados y estado al ejecutar.
- Identificador de operación, intentos, respuestas y número de efectos registrados.
Referencias oficiales
Protocolos relacionados
Comprobaciones antes de concluir
- ¿El control rechaza un objeto o destinatario fuera de alcance?
- ¿Cambiar contenido o versión invalida la confirmación anterior?
- ¿Se tiene en cuenta la revocación del permiso antes del efecto?
- Tras agotar el tiempo de espera, ¿se distingue entre ausencia de efecto, efecto confirmado y estado sin resolver?
Preguntas frecuentes
¿Basta con una confirmación humana?
Aprueba una propuesta en un contexto concreto. La acción final debe seguir correspondiendo a esa propuesta y los permisos deben continuar vigentes.
¿Un tiempo de espera agotado significa que no ocurrió nada?
No. Describe lo que el cliente no recibió a tiempo. El servicio puede haber registrado la operación; comprobar su estado antes de decidir un reintento.
¿El mismo identificador garantiza un único efecto?
Solo si el servicio aplica y prueba un contrato de deduplicación adecuado. El ejercicio lo establece expresamente; no debe suponerse que lo ofrece una API real.