¿Por qué son peligrosas las solicitudes de aprobación parecidas?

Una aprobación humana solo aporta seguridad cuando la persona puede saber qué autoriza el clic. Si dos solicitudes se ven iguales en pantalla, pero difieren en el cuerpo, las cabeceras, la identidad de la ejecución o los comandos, la aprobación es puro teatro. La persona no revisó la acción. Reconoció una etiqueta conocida y siguió adelante.

Es fácil crear este problema en las herramientas para agentes porque el resumen visible suele empezar por los campos menos interesantes: un título, un nombre de host, un método y quizá un comando corto. Esos campos ayudan a orientarse, pero no definen la autoridad. Un POST al mismo endpoint puede crear un borrador inocuo o publicar un cambio en producción. Un comando SSH puede mostrar una versión o eliminar un directorio. Una solicitud enviada con una cabecera de otro inquilino puede cruzar un límite aunque cada palabra de la URL siga en su sitio.

He visto cómo los flujos de aprobación se volvían inútiles por buenas intenciones. Alguien quiere menos interrupciones y agrupa llamadas parecidas. Alguien quiere una tarjeta ordenada y contrae el cuerpo de la solicitud. Alguien quiere una etiqueta estable para las analíticas y la reutiliza en todas las acciones de una misma familia. Cuando el revisor ve la décima tarjeta conocida, el sistema ya le ha enseñado que los detalles no importan. Al atacante, o al agente defectuoso, le basta una sola diferencia oculta.

Las etiquetas idénticas pueden ocultar una autoridad diferente

Un título y un destino son pistas, no el objeto que la persona está autorizando. Tratar ambos elementos como identidad crea una clase de colisiones: muchas operaciones distintas se convierten en una sola solicitud reconocible.

Piensa en un servicio de despliegue con un único endpoint, POST /v1/releases. Primero, un agente envía una versión en borrador y después pide publicarla. Si ambas tarjetas dicen «Release request» y muestran api.example.test, el revisor debe abrir un panel de detalles y leer el cuerpo para distinguirlas. En la práctica, las tarjetas repetidas enseñan a la gente que el panel contiene el mismo ruido cada vez. La solicitud de publicación llega después de ese aprendizaje.

El mismo problema aparece en tareas más cotidianas. Una API de control de código fuente puede usar la misma ruta para actualizar el título de una solicitud de cambios, modificar una opción de combinación o sustituir a los revisores. Una API en la nube puede usar la misma ruta de recurso para una simulación y un cambio real mediante un solo campo. Un endpoint de tickets puede escribir en un incidente privado o en una página pública de estado según una cabecera. El destino indica dónde llegó la solicitud. No indica qué hará el servicio remoto.

En los comandos, la falsa similitud suele empezar con una cadena amigable para mostrar. Estos pares nunca deben compartir una identidad de aprobación:

• find build -type f -delete y find build -type f -print
• git push origin HEAD desde un clon personal y desde una copia de trabajo de publicación
• curl -X POST con un cuerpo JSON que crea un borrador y otro que envía un mensaje
• ssh deploy@host usando una cuenta de solo lectura y usando una cuenta autorizada para modificar archivos del servicio

La distinción que suele perderse es la diferencia entre similitud y equivalencia. La similitud indica que dos acciones tienen suficientes elementos en común como para agruparlas visualmente. La equivalencia indica que una aprobación cubre legítimamente la otra acción. La primera es una decisión de presentación. La segunda concede autoridad. Confundirlas es la forma en que una interfaz compacta amplía permisos en silencio.

Una solicitud puede agrupar acciones repetidas para facilitar la lectura, pero esa agrupación nunca debe decidir si un clic anterior se aplica. La comprobación de autorización necesita un objeto más estricto que la etiqueta de la tarjeta.

La aprobación debe vincularse a la solicitud ejecutada

El objeto aprobado debe ser una descripción canónica de la acción que enviará el ejecutor, junto con el contexto de identidad con el que la enviará. Si cambia cualquier campo que aporte autoridad, el sistema debe volver a preguntar o hacer que el campo cambiado sea imposible de pasar por alto y exigir una nueva decisión.

En HTTP, esa descripción suele incluir el método, el esquema y el host, la ruta normalizada, los valores de consulta, los bytes del cuerpo o una forma canónica del cuerpo definida de antemano, las cabeceras seleccionadas, la referencia de la credencial y la ejecución del agente. No incluyas valores secretos en la interfaz ni en los registros solo para conseguirlo. Una referencia como payments-production identifica la autoridad sin exponer el token. El ejecutor puede vincular la aprobación al registro interno de la bóveda que realmente utilizará.

Las cabeceras merecen más cuidado del que les dedican la mayoría de las interfaces. Algunas solo afectan a detalles del transporte. Otras seleccionan una organización, activan un modo administrativo, establecen un ámbito de idempotencia, eligen una cuenta regional o cambian la forma en que el receptor interpreta el cuerpo. Mantén una lista explícita de los campos que pueden omitirse porque no pueden afectar a la acción remota. Todo lo demás debe aparecer en la identidad canónica hasta que alguien demuestre que excluirlo no supone ningún riesgo.

Para un comando, construye la descripción a partir del plan de ejecución y no de una cadena de shell. El plan incluye el ejecutable, el vector de argumentos, el directorio de trabajo, el host de destino cuando corresponda, la identidad del usuario, la referencia de la credencial y las variables de entorno que afectan al comportamiento. Una cadena de shell es un formato de presentación que pierde información. Las reglas de comillas, la expansión, las variables heredadas y un directorio de trabajo distinto pueden convertir una línea aparentemente igual en otra acción.

Aquí es donde los equipos suelen defender una regla permisiva como «mismo destino y mismo verbo es suficiente». Es popular porque reduce las solicitudes rápidamente y hace que las demostraciones parezcan fluidas. Es incorrecta porque los verbos HTTP describen clases generales, no consecuencias. POST no es una categoría de permisos, y ssh tampoco.

Usa una huella digital de la solicitud para vincular la decisión, pero no la muestres como única prueba. Un resumen criptográfico es excelente para comprobar la igualdad dentro del motor de aprobaciones. Las personas necesitan ver los campos que llevaron al resultado. Dales ambas cosas: diferencias estructuradas y legibles en la tarjeta, y una identidad canónica exacta detrás de ella.

La repetición no demuestra que una llamada sea segura

Un reintento puede compartir todos los campos de ejecución con un intento anterior y aun así requerir un tratamiento diferente al de un duplicado no relacionado. El sistema debe clasificar el motivo de la repetición antes de decidir si suprime una solicitud.

El caso más seguro de llamada repetida es un reintento de transporte en el que el ejecutor sabe que la primera solicitud nunca llegó al servicio remoto, o cuando el servicio remoto ofrece un mecanismo de idempotencia vinculado a la operación exacta. Incluso entonces, el motor de aprobaciones debe vincular el reintento a la operación aprobada original y registrar esa relación. No debe limitarse a detectar que dos hashes coinciden en algún punto del historial reciente.

Un duplicado después de un fallo de red de resultado incierto es distinto. El servicio remoto podría haber aceptado la primera llamada antes de que se interrumpiera la conexión. Repetirla podría enviar un segundo correo, crear un segundo problema o cobrar dos veces. El revisor necesita un mensaje que indique que se desconoce el resultado del intento anterior. Una tarjeta de aspecto conocido que solo diga «Reintentando solicitud» oculta la decisión que debe tomar.

Una acción idéntica posterior de otra ejecución también es diferente. Puede proceder de otro proceso del agente, de código nuevo, de una sesión de terminal copiada o de otra persona que usa la misma máquina. La autorización por ejecución existe porque la identidad y la duración del proceso importan. Reutilizar una aprobación antigua entre ejecuciones convierte una decisión limitada en una concesión permanente.

Usa estados separados en tu modelo:

1. El usuario aprobó una acción planificada exacta.
2. El ejecutor intentó realizarla y sabe si la envió.
3. El lado remoto informó de éxito, fallo o un resultado desconocido.
4. Una acción posterior afirma tener una relación con la primera.

No reduzcas esos estados a una insignia verde. Una aprobación registra la intención. El resultado del transporte registra las pruebas de entrega. La respuesta remota registra el resultado. Responden a preguntas distintas, y el registro de auditoría debe conservar las tres cosas.

Los cuerpos necesitan una revisión semántica y una vinculación a nivel de bytes

El cuerpo de una solicitud puede contener toda la consecuencia de una llamada a una API, así que ocultarlo tras una etiqueta genérica como «payload adjunto» es un error de diseño. Muestra una forma legible para la revisión y después vincula la aprobación a la representación exacta que envía el ejecutor.

JSON lo complica porque su apariencia y su significado pueden diferir. El orden de los campos de un objeto normalmente no cambia la interpretación del receptor, mientras que el orden de una matriz puede cambiarla por completo. Los espacios en blanco normalmente no importan, pero sí importan dentro de una cadena que los contiene. Un número escrito como 1 puede tratarse de forma distinta que 1.0 en un servicio con una descodificación flexible o personalizada. No inventes un normalizador JSON universal suponiendo que conserva la semántica.

Un enfoque práctico tiene dos capas. Primero, conserva los bytes del cuerpo saliente y calcula un resumen criptográfico sobre ellos para vincular la autorización. Segundo, analiza los tipos de contenido conocidos en un árbol de visualización que haga legibles los campos. Si el analizador no puede interpretar el cuerpo de forma segura, muestra un fragmento escapado, su longitud y un resumen, y exige que la persona lo expanda antes de aprobar cuando la llamada tenga consecuencias.

Prueba con pares diseñados para engañar a un revisor desprevenido. Los dos archivos de prueba siguientes comparten título, método y destino. Deben producir huellas digitales distintas y mostrar una diferencia visible en la vista de aprobación.

{
  "title": "Release request",
  "method": "POST",
  "url": "https://api.example.test/v1/releases",
  "headers": {"Content-Type": "application/json"},
  "body": {"version": "2.4.1", "state": "draft"}
}

{
  "title": "Release request",
  "method": "POST",
  "url": "https://api.example.test/v1/releases",
  "headers": {"Content-Type": "application/json"},
  "body": {"version": "2.4.1", "state": "published"}
}

La prueba debe comprobar algo más que fingerprintA != fingerprintB. Debe verificar que la tarjeta mostrada identifica state como un campo modificado, que una aprobación para el caso de borrador falla frente al caso publicado y que el registro de actividad conserva el resumen del cuerpo y su resumen criptográfico. La última comprobación detecta una solución defectuosa muy conocida: los ingenieros corrigen la comprobación de autorización, pero dejan a revisores e investigadores mirando un registro que no ayuda.

Los cuerpos binarios y los formularios necesitan la misma disciplina. Una carga multipart puede conservar el nombre y el tipo de contenido del archivo mientras sustituye el documento enviado. Un formulario codificado puede cambiar role=user por role=admin en un campo que una tarjeta compacta nunca muestra. Si la acción remota importa, el cuerpo también importa.

Las cabeceras y las credenciales crean cambios de alcance ocultos

La credencial usada para enviar una solicitud forma parte de la acción, aunque la URL y el cuerpo sean idénticos byte por byte. Una tarjeta que dice «Update invoice», pero oculta si usa una credencial de pruebas o de producción, pide al revisor que apruebe a ciegas.

Nunca muestres un token bearer, una contraseña, una clave privada ni una cabecera secreta personalizada. En su lugar, asigna a cada registro secreto una etiqueta humana estable y muestra la etiqueta, la clase de cuenta y la advertencia de permisos que el operador haya configurado deliberadamente. El revisor quizá no necesite ver el texto del token, pero sí debe saber que billing-read cambió a billing-admin o que ahora una acción se ejecuta como otra cuenta SSH.

Las cabeceras personalizadas provocan las sorpresas más desagradables porque a menudo parecen simples elementos de infraestructura. Un valor X-Organization puede redirigir una solicitud conocida a otro inquilino. Una cabecera X-Mode: live puede cruzar la línea entre una simulación y una operación real. Un Idempotency-Key puede decidir si el receptor trata una solicitud como una repetición o como una instrucción nueva. Incluye estos campos en la comparación mostrada cuando afecten al alcance.

La ocultación debe conservar la detección de cambios. Sustituir cada valor sensible por *** solo es aceptable si la interfaz aún puede indicar que cambió la referencia del secreto. Si dos secretos distintos se muestran como ***, tú mismo has creado una colisión entre solicitudes parecidas. Muestra una etiqueta que no sea secreta o un alias interno estable, nunca el material en sí.

Un conjunto de casos útil cambia una dimensión cada vez: la misma solicitud con otra referencia de credencial, la misma credencial con otra cabecera de organización, la misma cabecera con otro valor de consulta y el cambio completo de una vez. Los casos de una sola dimensión detectan omisiones en el proceso de creación de la forma canónica. El caso combinado descubre código de interfaz que trunca las diferencias después de mostrar la primera.

Las sesiones indican quién vuelve a solicitar la acción

Una aprobación también es una decisión sobre quién llama. La misma acción de un proceso nuevo del agente no hereda la confianza que diste al proceso anterior solo porque comparta el directorio de trabajo o el nombre del ejecutable.

La autoridad de firma de código es útil porque un proceso puede atribuirse cualquier nombre amigable. Aun así, no hace que todas sus solicitudes sean equivalentes. Un proceso confiable puede ejecutar una instrucción modificada, leer un archivo contaminado del repositorio o seguir una indicación que el operador no pretendía darle. La identidad del proceso responde a «¿quién inició esta ejecución?». La vinculación de la solicitud responde a «¿qué hará esta ejecución?». Necesitas ambas.

Registra un identificador de sesión al iniciar el proceso y adjúntalo a cada acción propuesta y ejecutada. Cuando el proceso termina, su autorización temporal también debe terminar. Si aparece un proceso nuevo, muestra una aprobación nueva aunque su título y destino coincidan con una acción reciente. No decidas que dos procesos son iguales porque tienen la misma ruta de ejecutable. Los actualizadores, los binarios copiados, los envoltorios y las compilaciones locales de desarrollo hacen que ese atajo no sea fiable.

Ten cuidado con las herramientas de larga duración. Un proceso que funciona durante días no merece una aprobación general e infinita solo porque no haya terminado. Para las credenciales sensibles o las acciones con efectos irreversibles, exige aprobación en cada llamada. Para el trabajo repetido de bajo riesgo, limita el permiso a una sesión definida y haz que la sesión sea visible en el registro. La persona que opera el sistema debe poder revocar la ejecución que genera solicitudes no deseadas sin buscar en una configuración más amplia de la cuenta.

Sallyport aplica autorización por sesión de forma predeterminada y puede exigir confirmación en cada uso de una entrada seleccionada de la bóveda. Esta separación fija es más fácil de entender que un conjunto de excepciones que nadie puede reconstruir durante un incidente.

Los comandos SSH necesitan un plan de ejecución, no una cadena bonita

El texto del shell es especialmente bueno para hacerse pasar por sí mismo. El revisor ve un comando compacto mientras el shell resuelve alias, expande variables, hereda un directorio y se conecta con una credencial que la pantalla nunca menciona.

Si tu ejecutor acepta un vector de argumentos directo, mantenlo así. Muestra el ejecutable y cada argumento como campos separados, y añade el directorio de trabajo resuelto, el host remoto, el usuario remoto y la etiqueta de la credencial. Si debes invocar un shell, indícalo claramente y muestra el programa de shell exacto y los bytes del script. Una tarjeta que embellece el contenido de sh -c, pero oculta sh -c, omite la parte más importante.

Estos comandos parecen relacionados, pero autorizan comportamientos materialmente distintos:

ssh [email protected] 'systemctl status web'
ssh [email protected] 'systemctl restart web'

La diferencia entre los verbos se ve en este par sencillo. Los fallos reales la ocultan de forma más eficaz: una variable se expande a otro host, una ruta remota procede de un valor de entorno o una sustitución de comando obtiene instrucciones de un archivo que el agente modificó antes. Captura los valores después de la expansión cuando sea posible. Cuando la expansión ocurre de forma remota o no puede resolverse con seguridad, indica esa limitación y exige una aprobación más deliberada.

No trates la diferencia entre lectura y escritura como una propiedad que siempre puedas deducir del texto del comando. cat puede provocar una lectura de dispositivo con efectos secundarios. Un cliente que parece inofensivo puede ejecutar un hook remoto. Cuando puedas, prefiere familias de comandos explícitas con semántica conocida y exige aprobación humana para la ejecución de shells ambiguos. Pretender clasificar con precisión todos los comandos produce una falsa sensación de seguridad.

Prueba el límite con pares de colisión

Las pruebas de aprobación deben comenzar con pares que una persona pueda confundir con la misma acción. Las pruebas unitarias que solo demuestran que el caso normal permite aprobar y enviar una solicitud hacen muy poco frente a esta clase de fallos.

Crea una tabla de las dimensiones que aportan autoridad y prepara un caso emparejado para cada una. Mantén fijo el título y el destino en la mayoría de los casos. El objetivo es demostrar que el motor no usa accidentalmente esas etiquetas cómodas como identidad.

Ejecuta estos casos en tres capas. En la capa de canonicalización, comprueba que las identidades sean distintas. En la capa de autorización, intenta enviar el caso B usando una aprobación emitida para el caso A y espera un rechazo. En la capa de interfaz, toma una instantánea o una captura estructurada de accesibilidad y comprueba que el campo modificado aparezca sin abrir una vista secundaria. Una diferencia que solo existe después de varios clics es una diferencia que la mayoría de los revisores pasará por alto.

Después añade pruebas de mutación. Elimina cada campo de la identidad canónica en una rama de prueba y verifica que falle una prueba de colisión. Parece minucioso hasta que alguien refactoriza un objeto de solicitud y deja de pasar silenciosamente una cabecera, un directorio de trabajo o una etiqueta de credencial al adaptador de aprobación. La prueba debe hacer que esa omisión sea evidente.

La ruta de acciones de Sallyport mantiene los secretos en su bóveda cifrada y devuelve los resultados al agente, no el material secreto. Esta separación facilita las pruebas porque un caso puede referirse a los registros de credenciales mediante su etiqueta, mientras la prueba confirma que el agente nunca recibe la credencial real.

Un fallo plausible empieza con una primera llamada inofensiva

Imagina un agente que mantiene notas de publicación. Crea un borrador mediante un endpoint conocido y el operador aprueba la primera tarjeta después de comprobar el cuerpo. Luego, el agente hace varias actualizaciones pequeñas sobre el mismo borrador. El título de la tarjeta sigue siendo «Release request», el host no cambia y el operador aprende que cada aprobación es rutinaria.

Más tarde, una instrucción del repositorio le dice al agente «termina la publicación». El agente solo cambia state de draft a published y añade una cabecera que selecciona la organización activa. Si la interfaz muestra únicamente el título, el host y el método, la tarjeta final parece idéntica a las anteriores. Si la caché de aprobaciones agrupa las llamadas por título y destino, puede que el sistema ni siquiera vuelva a preguntar.

Nada de esta historia necesita un modelo comprometido ni una explotación espectacular. Basta con un agente que siga una instrucción incorrecta, un revisor acostumbrado a las solicitudes repetidas y una interfaz que oculte los dos campos que cambiaron el efecto. Esas condiciones aparecen en la automatización cotidiana.

La reparación debe cubrir todo el recorrido. Haz visibles el estado y la organización modificados. Vincula la aprobación a ambos valores y al registro de la credencial. Trata la solicitud activa como una acción nueva aunque todo lo demás coincida. Registra la acción propuesta, la decisión y la identidad de la solicitud enviada de forma que el operador pueda inspeccionarlas después. Corregir solo la tarjeta o solo la caché deja otra vía abierta para la colisión.

La fricción debe centrarse en las diferencias importantes

Las personas aprobarán muchas acciones rutinarias si el sistema las presenta con honestidad y solo ahorra fricción cuando cambia la autoridad. Para ello hace falta una regla clara: el silencio es aceptable para un reintento exacto dentro de un caso conocido y acotado; un cuerpo, una cabecera, una credencial, una sesión, un contexto de comando o un destino modificados exigen una nueva decisión.

No compenses una tarjeta imprecisa con más colores de advertencia, textos más largos o un botón de confirmación más intimidante. Esas técnicas ralentizan el trabajo rutinario y acostumbran a las personas a ignorar el ruido visual. Coloca los valores relevantes para la decisión en un diseño estable, marca los cambios con un lenguaje claro y conserva suficientes detalles para comparar la solicitud actual con la última aprobada.

Cuando encuentres un grupo de acciones que realmente pueda compartir una aprobación, documenta en el código y en las pruebas la afirmación de equivalencia. Por ejemplo, un reintento idempotente puede llevar un identificador de operación inmutable que el servicio remoto garantice ejecutar una sola vez. Es una afirmación concreta respaldada por pruebas. «Se parecen en la interfaz» no es una prueba.

Empieza reuniendo diez aprobaciones recientes con el mismo título y destino. Compara sus campos de solicitud canónicos, las etiquetas de las credenciales y los identificadores de sesión. Si encuentras diferencias que el revisor no podía ver en la tarjeta principal, has encontrado un defecto de autorización aunque todavía nadie lo haya aprovechado.