Suplantación de solicitudes de aprobación en macOS para revisar agentes de IA

Las solicitudes de aprobación son un objetivo atractivo porque convierten un ataque técnico difícil en un simple reflejo humano. Un atacante no necesita robar una credencial si consigue que un revisor apruebe una solicitud que parece normal, urgente y conocida.

El problema se vuelve más serio cuando los agentes de programación autónomos pueden llamar a APIs o ejecutar comandos SSH. Un revisor quizá esté mirando a la vez una solicitud de cambios, una terminal, una ventana de chat y un montón de notificaciones. Si la interfaz de aprobación no deja claro su origen y alcance, el revisor está haciendo trabajo de seguridad desde una miniatura.

La solución no consiste en enseñar a la gente a memorizar todos los diálogos de macOS. La memoria visual pierde frente a una ventana parecida creada por alguien que ha estudiado las mismas capturas de pantalla. Los revisores necesitan una forma repetible de vincular una aprobación con tres hechos: el proceso que la solicita, la acción que está a punto de ocurrir y el lugar de confianza donde se recoge la aprobación.

Una ventana conocida no demuestra quién la controla

Una ventana que se parece a una solicitud del sistema sigue siendo solo un conjunto de píxeles hasta que la relacionas con un proceso en ejecución y una solicitud concreta. Las esquinas redondeadas, el orden conocido de los botones, un icono de la barra de menús, una referencia a Touch ID y una frase que parece de Apple no demuestran el origen. Solo demuestran que alguien sabe cómo es macOS.

La diferencia parece obvia cuando se expresa así, pero los hábitos de revisión suelen borrarla. La gente pregunta: «¿Se parece esto a la solicitud que vi la semana pasada?». La pregunta correcta es: «¿Qué proceso provocó esta solicitud y dónde puedo inspeccionar ese proceso sin depender de esta ventana?»

macOS ofrece controles útiles sobre la procedencia del software. Apple explica en su documentación sobre el proceso de firma de aplicaciones en macOS que una firma de Developer ID permite verificar que el software no ha sido alterado desde que lo firmó su desarrollador. Apple también separa esa garantía de la notarización, que comprueba si el software enviado contiene contenido malicioso conocido. Estos controles importan, pero ninguno convierte cada frase mostrada por una aplicación firmada en una solicitud de autorización confiable.

Un programa malicioso puede no estar firmado, pero también puede estarlo. Un programa legítimo puede estar comprometido. También puede solicitar una acción que no tenga sentido para la tarea actual. El diseño visual del diálogo no puede responder a esas preguntas.

Trata cualquier pantalla de aprobación como una de estas cuatro cosas hasta demostrar lo contrario:

• Una interfaz de consentimiento o autenticación propiedad de macOS.
• Una ventana propiedad de la aplicación que querías usar.
• Una notificación que indica que una aplicación quiere llamar tu atención.
• Una página web o una capa superpuesta diseñada para parecerse a una de las tres anteriores.

La primera categoría puede usar controles del sistema, pero no tomes decisiones de aprobación basándote solo en la apariencia. Las demás son contenido de una aplicación. Pueden ser útiles, pero necesitan una revisión más sólida que «reconozco la forma de ese botón».

Toda aprobación debe vincular actor, acción y canal

Un revisor solo puede decidir con criterio cuando una aprobación une el actor, la acción y el canal. La mayoría de las solicitudes débiles identifican uno de esos elementos y dejan que la persona adivine los demás.

El actor es el proceso local que hace la solicitud. En un flujo de trabajo con agentes, no es simplemente «el asistente de programación». Es el proceso concreto iniciado para esta ejecución, con una autoridad de firma identificable cuando el flujo puede proporcionarla. Si una solicitud solo dice «el asistente de IA necesita aprobación», ha ocultado al revisor el dato más útil.

La acción es la operación real. «Permitir acceso a la red» no describe la acción si la operación consiste en crear un usuario de producción en un endpoint de API concreto. «Aprobar SSH» tampoco basta si el comando puede ser una consulta de estado de solo lectura o un despliegue remoto destructivo. El revisor necesita el verbo, el destino y las consecuencias que la herramienta pueda describir honestamente.

El canal es el lugar por el que viaja la decisión. Una notificación de escritorio es un mecanismo de entrega. Una página del navegador puede ser una interfaz de aplicación. Una ventana nativa puede ser el plano de control correcto. Ninguna de esas etiquetas garantiza la seguridad por sí sola. El revisor necesita un canal esperado que pueda volver a abrir de forma independiente.

Esta es la diferencia en la práctica.

Una solicitud débil dice:

El ayudante de despliegue necesita permiso. ¿Permitir?

Una solicitud que se puede revisar dice:

Proceso: ejecución de agente local firmado desde Terminal

Acción: POST /v1/releases a api.example.internal

Autoridad: credencial de despliegue de producción

Alcance: esta única solicitud

Canal de decisión: la aplicación de aprobación en ejecución

La segunda solicitud aún puede merecer un rechazo. No pasa nada. Su objetivo no es hacer que la aprobación parezca segura. Su objetivo es hacer que la autoridad solicitada sea lo bastante clara para que una persona pueda decidir.

Esto también revela un error frecuente de los equipos con los «agentes de confianza». Confiar en un actor no significa permitirle cualquier acción. Un proceso puede ser conocido aunque su destino solicitado sea incorrecto. El destino puede ser el esperado aunque el alcance de la credencial sea excesivo. Un flujo de revisión seguro coloca esos datos juntos en lugar de convertir la aprobación en una validación general.

Las notificaciones deben iniciar la revisión, no recoger el consentimiento

Una notificación sirve para interrumpir, no es una interfaz de autorización fiable. Tiene poco espacio, compite con todas las demás alertas del escritorio y puede contener texto diseñado para provocar un clic rápido. Si una notificación dice «Urgente: aprueba antes de que caduque el despliegue», ya está ejerciendo presión antes de que sepas quién creó el mensaje o si existe algún despliegue.

La configuración de Notificaciones de Apple permite controlar las vistas previas, decidir si las notificaciones aparecen en la pantalla bloqueada y establecer si aparecen mientras la pantalla se comparte o se duplica. Apple también permite gestionar los permisos y la presentación de cada aplicación. Estos controles reducen la exposición no deseada, pero no convierten el texto de una notificación en un registro de transacción confiable.

Los revisores deben usar una notificación solo como indicador. Lee el nombre de la aplicación, anota la hora y abre la aplicación esperada desde un lugar conocido. Si la solicitud es real, la aplicación debería mostrar la misma acción pendiente con contexto suficiente para evaluarla. Si la notificación abre una página del navegador, otra aplicación auxiliar o una ventana sin una solicitud pendiente correspondiente, detente.

No enseñes a los revisores a aprobar porque el icono de la notificación parece correcto. Los iconos son pequeños, pueden resultar desconocidos y confundirse con nombres parecidos. La pregunta importante es si la notificación lleva de vuelta a la interfaz de control que ya esperas usar para ese flujo de trabajo.

Desactiva las vistas previas de las herramientas que puedan mostrar destinos sensibles, nombres de cuentas o detalles de solicitudes en una pantalla bloqueada. Desactiva las notificaciones mientras compartes la pantalla si los asistentes a la reunión no deberían verlas. Son ajustes de confidencialidad, no controles contra la suplantación, pero eliminan una fuente útil de presión y filtraciones.

Una notificación es especialmente mala para acciones de gran impacto porque obliga al revisor a decidir antes de tener contexto. La conducta correcta está diseñada para ser más lenta: notificación, abrir la aplicación esperada, inspeccionar la solicitud y después aprobar o rechazar. Ese movimiento adicional no es fricción gratuita. Interrumpe el intento del atacante de controlar tanto el mensaje como el camino hacia el clic.

Las capas superpuestas explotan la atención, no un fallo de macOS

Una ventana de aprobación parecida no necesita romper los controles de seguridad de macOS para ser peligrosa. Una aplicación normal puede dibujar una ventana corriente, colocarla sobre otra aplicación, usar un título similar y hacer que aparezca después de un desencadenante creíble. El ataque funciona porque el revisor aporta la atribución que falta.

La explicación habitual es demasiado sencilla: «Una solicitud falsa debe ser malware con permisos especiales de pantalla». A veces el malware busca permisos amplios, pero una capa superpuesta convincente no siempre los necesita. Cualquier aplicación puede mostrar su propio contenido. Una pestaña del navegador puede mostrar una página web que imite una pantalla de consentimiento. Una sesión de soporte remoto puede pedir al usuario que apruebe un paso mientras un operador controla la historia.

No confundas la capacidad de ver una pantalla con la capacidad de crear una ventana. Apple trata «Grabación de pantalla y audio del sistema» como un permiso de Privacidad y seguridad que los usuarios pueden permitir o rechazar para aplicaciones y sitios web concretos. Controla la captura del contenido de la pantalla y del audio. No certifica una solicitud, y conceder ese permiso no identifica quién controla la ventana que tienes delante.

Los permisos de Accesibilidad exigen la misma disciplina. Existen porque algunas aplicaciones legítimas necesitan interactuar con elementos de la interfaz, pero un revisor no debe deducir que todas las ventanas de una aplicación con acceso a Accesibilidad pertenecen al sistema. El historial de permisos puede ayudar en una investigación. No puede servir como prueba en el momento de la aprobación.

Una revisión útil de una capa superpuesta empieza por el comportamiento, no por la decoración:

• ¿Apareció la solicitud justo después de una acción que iniciaste?
• ¿Al cambiar de aplicación y volver a abrir la aplicación esperada aparece la misma solicitud?
• ¿La solicitud indica el destino y el alcance con términos que coinciden con tu trabajo?
• ¿Pide una contraseña, una frase de recuperación o un secreto que este flujo nunca debería necesitar?
• ¿Intenta impedir que inspecciones la solicitud en otro lugar?

El último punto detecta más solicitudes maliciosas de lo que mucha gente espera. Un flujo de control real debería soportar unos segundos de verificación. Uno engañoso suele inventar una cuenta atrás, afirmar que la solicitud fallará si abandonas la ventana o hacer sentir al revisor que cualquier demora causará daños.

Una suplantación creíble tiene una secuencia reconocible

Imagina que un ingeniero pide a un agente que actualice un entorno de pruebas. La salida de la terminal del agente indica que necesita aprobación para una llamada a una API. Casi al mismo tiempo aparece una notificación: «Se necesita autorización para el despliegue. Abre el Centro de seguridad».

El ingeniero hace clic. Se abre una ventana con un título parecido al de un panel de seguridad conocido de macOS. Contiene una descripción breve, un destino que empieza por el dominio corporativo esperado y botones con las etiquetas «Cancelar» y «Permitir». Incluso menciona Touch ID, aunque la ventana nunca inicia una comprobación biométrica real.

El engaño funciona si el ingeniero acepta la historia visual. Puede haber varios problemas a la vez:

1. La notificación puede proceder de una aplicación distinta de la aplicación de aprobación.
2. La notificación puede haber abierto una página del navegador o una herramienta auxiliar en lugar del control de aprobación real.
3. El destino mostrado puede ser un dominio parecido, una redirección o un permiso amplio de cuenta, no la solicitud concreta del despliegue.
4. El proceso que inició el agente puede ser distinto del proceso que solicita la aprobación.
5. La acción puede no dejar un registro duradero después del clic, lo que impediría al revisor reconstruir qué permitió.

Por eso un protocolo de revisión debe resistir una imitación visual perfecta. El ingeniero debería dejar la ventana abierta sin pulsar ninguno de los botones, poner en primer plano la aplicación de aprobación esperada desde la barra de menús o la carpeta Aplicaciones y buscar una solicitud pendiente generada por la ejecución actual del agente. Si no hay una solicitud correspondiente, la ventana emergente no se vuelve más confiable por estar bien diseñada.

Si existe una solicitud correspondiente, compara las dos descripciones. Una solicitud legítima debería identificar la misma acción, el mismo endpoint y la misma autoridad. Si la aplicación esperada muestra un comando SSH y la ventana emergente describe una aprobación de despliegue genérica, rechaza ambas hasta entender la discrepancia. Los atacantes se benefician cuando los revisores tratan una coincidencia parcial como confirmación.

La parte más incómoda es que una suplantación suele usar datos reales. Puede conocer el nombre del proyecto, el nombre del entorno y la hora de un despliegue real. Esos detalles demuestran que el atacante tiene contexto. No demuestran que la acción solicitada pertenezca al proceso esperado.

Verifica la aplicación instalada antes de necesitar una aprobación

No puedes comprobar cuidadosamente una identidad mientras una ventana afirma que la acción caducará en diez segundos. Establece la identidad de la aplicación esperada durante la configuración, regístrala en la documentación del equipo y prueba el método de verificación durante una jornada normal.

Para una aplicación instalada en una ruta conocida, este comando muestra la información de firma que ve macOS:

codesign -dvvv "/Applications/Expected Approval App.app" 2>&1 | grep -E 'Identifier=|TeamIdentifier=|Authority='

La salida tiene esta forma general:

Identifier=com.example.approvals
TeamIdentifier=ABCDE12345
Authority=Developer ID Application: Example Software, Inc. (ABCDE12345)
Authority=Developer ID Certification Authority
Authority=Apple Root CA

No copies esos valores de ejemplo en una lista de comprobación. Registra el identificador y el identificador del equipo del software que tu equipo haya aprobado después de obtenerlo mediante el proceso habitual de distribución de software. El nombre visible es una prueba débil porque varias aplicaciones pueden usar el mismo nombre. El identificador del paquete y el equipo de firma te proporcionan datos que el título de una ventana no ofrece.

Usa una segunda comprobación para conocer el estado de evaluación del paquete instalado:

spctl -a -vv "/Applications/Expected Approval App.app"

La salida habitual incluye una evaluación como accepted, junto con el origen y la procedencia. El texto puede cambiar entre versiones de macOS y métodos de distribución, así que no crees un script que falle porque espera una frase exacta. Úsalo como ayuda para investigar: un rechazo, origen, ruta o identidad de firma inesperados son motivos para detenerse e investigar.

La documentación de Gatekeeper de Apple explica que macOS comprueba, con su configuración predeterminada, si el software descargado procede de un desarrollador identificado, está notarizado y ha sido modificado. Esto protege la ruta de lanzamiento, algo necesario. No sustituye la comprobación de que la aplicación solicita ahora la acción correcta.

Los equipos deberían conservar un registro breve con el nombre de la aplicación, la ubicación habitual de instalación, el identificador del paquete, el equipo de firma y la persona responsable de las actualizaciones. Guárdalo en el mismo lugar interno donde la gente consulta los nombres de los entornos y los contactos de incidentes. Cuando una actualización cambie alguno de esos datos, revisa el cambio como parte de la actualización en lugar de redescubrirlo durante un evento de aprobación.

Evita la alternativa cómoda: «Está en Aplicaciones, así que debe ser la correcta». Aplicaciones es una ubicación, no una afirmación de identidad. Allí también puede haber un paquete copiado o con un nombre similar. La ruta te ofrece un objeto estable que inspeccionar. La firma ofrece una afirmación de identidad. El proceso de tu equipo decide si esa identidad es la esperada.

Revisa la solicitud desde un camino independiente

Cuando aparezca una aprobación, usa siempre la misma rutina breve. Para las solicitudes normales debería tardar menos de un minuto y seguir funcionando aunque la primera ventana sea completamente falsa.

1. Detente ante la primera solicitud. No hagas clic en permitir, cerrar ni sigas un enlace integrado hasta saber qué la abrió.
2. Expresa la acción esperada con palabras sencillas. Por ejemplo: «Le pedí al agente de pruebas que leyera el estado del despliegue». Si la solicitud describe una escritura en producción, una sesión SSH o un acceso amplio a una cuenta, ya existe una discrepancia.
3. Abre la aplicación de aprobación de forma independiente mediante su elemento esperado de la barra de menús, su ubicación en Aplicaciones o un lanzador conocido. No uses la ventana sospechosa como control de navegación.
4. Busca la solicitud pendiente y compara el proceso que la inició, la acción, el destino, la autoridad y el alcance. Que el nombre del proceso coincida no es suficiente.
5. Aprueba solo la solicitud más pequeña que complete la tarea actual. Rechaza una solicitud poco clara, más amplia de lo necesario o incoherente con el trabajo que iniciaste.

Esta rutina rechaza una recomendación popular pero mala: «Aprueba una vez un agente conocido para que deje de interrumpirte». Es popular porque las solicitudes repetidas molestan y los agentes suelen necesitar varias llamadas relacionadas. Es incorrecta porque el volumen de solicitudes es un problema de diseño, no una razón para borrar el límite de revisión.

Un diseño mejor puede autorizar un único proceso conocido durante la ejecución actual, manteniendo las autoridades sensibles sujetas a una confirmación separada. El revisor recibe menos decisiones repetitivas sin conceder permiso permanente a una categoría imprecisa de trabajo.

Sallyport aplica directamente esta separación: un nuevo proceso de agente recibe una solicitud de autorización de sesión que identifica la autoridad de firma de código del proceso, mientras que una credencial puede configurarse para exigir aprobación en cada uso. El agente nunca recibe el secreto, de modo que la aprobación decide si la aplicación ejecuta la acción, en lugar de entregar las credenciales al agente.

La diferencia importa en un incidente real. Si una ejecución del agente empieza a comportarse de forma extraña, revoca su sesión. No esperes a que el agente llegue al siguiente punto de aprobación. Un límite de sesión permite al revisor detener las acciones futuras de ese proceso sin suponer que todas las capacidades aprobadas anteriormente siguen siendo adecuadas.

El texto de aprobación debe mostrar el alcance antes que la urgencia

Los equipos suelen dedicar demasiado tiempo a pulir el lenguaje de advertencia y muy poco a decidir qué datos debe contener la aprobación. Una frase mejor en una solicitud débil sigue siendo débil. Una frase algo sencilla con los datos necesarios es más segura.

Pon la acción en primer lugar. «Crear una versión en producción» indica al revisor qué ocurrirá. «Autorizar el flujo de despliegue» oculta la operación tras una etiqueta interna.

Indica después el destino. Un nombre de host, repositorio, cuenta o equipo remoto muestra adónde irá la autoridad. Si el sistema no puede nombrar un destino porque no conoce ninguno, debe decirlo. No debe sustituir la falta de contexto por una frase tranquilizadora como «servicio de confianza».

Expresa el alcance en términos humanos. Una solicitud que permite una única solicitud GET a un endpoint conocido es muy distinta de una credencial disponible para todas las llamadas de una sesión. Aprobar un comando SSH es distinto de permitir un shell sin restricciones. La solicitud debe describir el límite real, no uno idealizado.

Sé honesto sobre lo que el revisor no puede ver. Si una herramienta solo sabe que un agente iniciará una conexión SSH, debe decirlo en lugar de fingir que ha inspeccionado todos los comandos remotos. La precisión falsa enseña a confiar en etiquetas que no corresponden a ninguna medida de control.

Evita los nombres de acciones imprecisos, especialmente estos:

• «Continuar»
• «Conceder acceso»
• «Completar configuración»
• «Verificar identidad»
• «Permitir funcionamiento del agente»

Cada frase pide al revisor que aporte el significado a partir del contexto. Si ese contexto procede de un mensaje de terminal, chat, notificación o ventana emergente controlado por un atacante, el revisor se ha convertido en parte de la suplantación.

Un buen flujo de aprobación también hace que rechazar sea una consecuencia normal. «Rechazar» no debe parecer una excepción peligrosa. Debe detener la acción, conservar información suficiente para que el revisor la inspeccione después y permitir que el usuario vuelva a intentarlo tras corregir la solicitud. Cuando rechazar parece catastrófico, los usuarios aprobarán solo para poder continuar.

Los registros convierten la sospecha en una investigación

Después de una aprobación dudosa, deja de tratar la pantalla como una prueba. Las pantallas desaparecen, las ventanas pueden mentir y la memoria cambia rápidamente. Conserva un registro del proceso que se ejecutó, la acción que solicitó, la decisión del revisor y si la acción llegó a su destino.

Captura primero el intervalo de tiempo. Después guarda la transcripción del agente, el historial de la terminal relevante para la ejecución y el historial de acciones de la herramienta de aprobación. Registra la ruta exacta de la aplicación que mostró la solicitud. Si el elemento sospechoso llegó mediante una notificación, anota el nombre de aplicación mostrado y si al abrirlo se llegó a un navegador, una herramienta auxiliar o la aplicación esperada.

No empieces eliminando la aplicación sospechosa. Si necesitas conservar pruebas para una investigación interna, anota antes su ruta y sus datos de firma. Si el equipo puede estar comprometido, sigue el proceso de incidentes de tu equipo y aíslalo según corresponda. Un evento de suplantación de solicitudes puede ser un ataque de ingeniería social, una aplicación local no deseada, un compromiso del navegador o una señal de que una herramienta legítima tiene un fallo de diseño. Las pruebas indican qué problema tienes.

Para las acciones de los agentes, el registro necesita dos niveles. Un registro debe describir la ejecución y permitir que un operador la revoque. Otro debe describir las llamadas individuales, incluido el destino y la decisión. Sin el primero, no puedes detener correctamente a un actor activo. Sin el segundo, no puedes saber qué habilitó realmente la aprobación.

Sallyport proyecta los registros de sesión y de actividad individual desde un registro de auditoría cifrado y encadenado mediante hashes, y sp audit verify puede verificar la cadena sin conexión sobre el texto cifrado. Eso no hace que una aprobación incorrecta sea inofensiva, pero ofrece al revisor y al investigador una respuesta duradera a la pregunta importante cuando la ventana emergente ya ha desaparecido: ¿qué acción ejecutó realmente este proceso?

El objetivo no es convertir a cada revisor en especialista en seguridad de macOS. Es hacer normal la acción segura: abandonar la interfaz sospechosa, volver a abrir el plano de control esperado, comparar los datos y aprobar solo la solicitud que encaje con el trabajo que tienes delante. Una solicitud que no supera esa comprobación no merece un clic.