Cómo probar permisos negativos para demostrar que un agente no puede hacer lo que no debe

La seguridad de un flujo no se demuestra solamente mostrando que la acción correcta funciona. Un equipo puede probar que un agente crea una tarea, lee un documento o actualiza un registro con una credencial autorizada y concluir que la integración está lista. Falta la mitad del examen: comprobar qué ocurre cuando intenta una acción que no debería poder realizar. Una prueba negativa de permisos diseña deliberadamente intentos prohibidos y espera un rechazo verificable. El objetivo no es provocar errores por curiosidad, sino demostrar que la frontera de autoridad existe también cuando el sistema recibe una instrucción válida desde el punto de vista técnico.

Empieza construyendo una matriz de actor, recurso y acción antes de escribir casos de prueba. En filas pueden aparecer usuarios, agentes, servicios o credenciales; en columnas, operaciones como leer, crear, modificar, eliminar, aprobar o exportar. Cada cruce debe indicar permitido, denegado o condicionado. Esa matriz evita probar permisos de forma anecdótica. También ayuda a descubrir combinaciones olvidadas: quizá un agente puede editar un cliente propio, pero no uno de otra cuenta; puede generar un borrador, pero no enviarlo; puede leer un archivo, pero no cambiar su configuración de acceso. La prueba nace de esa frontera explícita.

Para cada permiso importante diseña al menos un caso que deba fallar de manera controlada. Si una credencial solo puede leer, intenta escribir. Si un rol puede modificar elementos de su equipo, intenta modificar uno ajeno. Si una automatización puede preparar pagos pero no aprobarlos, intenta llegar a la aprobación. El resultado esperado debe incluir más que “algo salió mal”: conviene definir el tipo de rechazo, el estado final y la ausencia de efectos secundarios. Un sistema seguro no debería crear parcialmente un recurso, cambiar un campo o dejar una cola pendiente antes de anunciar que la operación estaba prohibida.

Los límites más valiosos suelen aparecer en condiciones cercanas al borde, no en prohibiciones obvias. Es fácil verificar que un usuario sin sesión no pueda entrar; más interesante es comprobar qué ocurre con una sesión válida cuyo rol cambió hace un minuto, con una credencial revocada, con un recurso transferido a otro propietario o con una acción permitida sobre un objeto pero prohibida sobre sus adjuntos. Esos casos revelan permisos heredados, cachés o validaciones aplicadas demasiado tarde. La pregunta es si la autorización se evalúa en el momento y sobre el recurso correctos, no si existe una pantalla que dice “sin acceso”.

La evidencia debe registrar quién intentó qué, sobre cuál recurso y por qué fue rechazado. Un mensaje genérico como “forbidden” puede ser suficiente para el usuario final, pero la operación necesita trazabilidad interna. El log debería permitir distinguir falta de autenticación, rol insuficiente, alcance incorrecto, política vencida o restricción específica del recurso. Al mismo tiempo, el rechazo no debería filtrar datos que el actor no estaba autorizado a conocer. Una buena prueba confirma ambas cosas: existe información suficiente para investigar internamente y no se expone información sensible al solicitante bloqueado.

Automatiza estas pruebas alrededor de cambios de permisos y no solo antes del primer lanzamiento. Agregar un rol, cambiar una integración o ampliar una capacidad puede abrir rutas que antes estaban cerradas. Por eso conviene mantener un conjunto pequeño de pruebas negativas críticas dentro de la regresión. Cuando una política cambia, se actualiza la matriz y se ejecutan nuevamente los casos de borde. La señal de alerta más importante es un intento que antes era denegado y ahora termina en éxito sin una decisión explícita. Esa transición merece revisión aunque todas las pruebas positivas sigan pasando.

Un sistema de permisos confiable puede demostrar tanto su capacidad como su incapacidad deliberada. La validación final debería responder qué acciones puede realizar cada actor, cuáles no, bajo qué condiciones cambia la respuesta y qué evidencia queda cuando alguien cruza el límite. Esa disciplina reduce el riesgo de confiar en una interfaz o en una intención documentada que el backend no aplica realmente. En agentes y automatizaciones, donde una credencial puede ejecutar muchas acciones con rapidez, probar el “no” es tan importante como probar el “sí”. La frontera de seguridad existe cuando el rechazo también es un comportamiento diseñado y repetible.