¿Puede la identidad del host de extensiones de un IDE demostrar quién es un agente?

Un host de extensiones del editor puede tener una firma de código válida y aun así no permitirte saber qué extensión solicitó una acción sensible. No es un defecto de la firma de código. Es el resultado previsible de pedirle a un mecanismo de identidad del sistema operativo que responda a una pregunta que existe dentro de un mismo proceso.

Esto importa cuando un agente de programación con IA funciona a través de un IDE. El host puede cargar varias extensiones, aceptar comandos de un espacio de trabajo y pasar el trabajo a un intermediario con acceso a una API o a un destino SSH. Si el intermediario aprueba el host una vez y trata esa aprobación como una prueba de la intención de una extensión concreta, concede más autoridad de la que permite la evidencia.

He visto este error presentado como un diseño de seguridad impecable: verificar el editor firmado, mostrar el firmante en un aviso de aprobación y permitir la ejecución. Es un control útil. Se vuelve peligroso cuando el aviso transmite una precisión que no tiene. El host puede ser confiable, mientras la solicitud que cruzó su límite sigue siendo ambigua.

La firma del host identifica el contenedor, no a quienes lo ocupan

La firma de código demuestra hechos sobre una imagen ejecutable. En macOS, Apple describe la firma de código como una forma de establecer el origen y la integridad del software. El sistema puede comprobar que una autoridad de firma confiable firmó el código y que el código cargado sigue coincidiendo con el material firmado. Esa es exactamente la evidencia que necesita una decisión de seguridad cuando pregunta: «¿Qué proceso de aplicación está haciendo la solicitud?»

No demuestra: «¿Qué función de una extensión dentro de ese proceso hizo la solicitud?». Un proceso tiene una sola identidad ejecutable en ese límite. Si un editor inicia un host de extensiones y el host carga diez plugins, el kernel no crea diez identidades de firma de código independientes para su JavaScript, bytecode, callbacks o llamadas a la API de extensiones.

Esa distinción tiene una consecuencia práctica. Un intermediario puede crear un registro defendible como este:

caller executable: /Applications/Editor.app/.../extension-host
signing authority: Example Software Team ID ABC123
process id: 8421
parent process: Editor.app pid 8304

Pero no puede obtener esto solo de la firma:

extension: publisher.cloud-deploy
command: deployCurrentProject
prompt source: chat request 18

El primer bloque contiene evidencia del sistema operativo. El segundo contiene procedencia de la aplicación. Ambos pueden ser útiles, pero merecen un tratamiento diferente en un registro y en una pantalla de aprobación.

A menudo se llama «identidad» a ambas cosas y la distinción se pierde durante la implementación. No la pierdas. El firmante te dice quién produjo la caja. No te dice qué pasajero extendió la mano hacia los controles.

Los hosts compartidos de extensiones agrupan varias autoridades en una sola

Un host de extensiones existe para que el editor pueda cargar y coordinar extensiones. El diseño es práctico, pero convierte al host en un conjunto de autoridades. Un plugin de autocompletado, un formateador, una integración con el control de versiones, un asistente de chat y una extensión del espacio de trabajo pueden ejecutarse en el mismo proceso del host.

Imagina un intermediario que permite una llamada HTTPS después de verificar la firma del editor. La extensión A pide al host que llame a un endpoint de despliegue. La extensión B tiene acceso a una API de extensiones que puede hacer que el mismo host realice trabajo de red, quizá directamente o quizá mediante un comando registrado por A. En el intermediario, ambas solicitudes llegan con el mismo identificador de proceso y la misma autoridad de firma. El intermediario no puede separarlas inspeccionando la firma del host.

La ambigüedad aumenta cuando las extensiones se comunican mediante servicios compartidos del host. Un plugin puede registrar un comando y otro puede invocarlo. Una extensión de chat puede recibir instrucciones de un archivo del repositorio, del contenido de una incidencia o de un resultado de terminal pegado y luego enviar un comando. La atribución tiene ahora varias capas: el host firmado, la extensión que hizo la llamada, la extensión que proporcionó la entrada y la persona o el contenido no confiable que influyó en ella.

Nada de esto hace que las extensiones de IDE sean inseguras por naturaleza. Significa que la aprobación a nivel de host aprueba la autoridad combinada del host. Si resulta demasiado amplia para una operación, necesitas un segundo control que vea la operación en sí.

El nombre de una extensión solo es procedencia cuando el host lo vincula

Un identificador de extensión como publisher.name aporta un contexto útil, pero un intermediario no debe confundir una cadena proporcionada por quien hace la llamada con una prueba. Cualquier código que pueda crear una solicitud puede escribir publisher.name en una cabecera, un cuerpo JSON, un argumento de comando o una variable de entorno. Eso solo indica lo que afirmó.

Un host puede reforzar esa afirmación si obtiene el identificador de su propio registro de extensiones, lo vincula al contexto de ejecución activo y lo envía por un canal local protegido que las extensiones no puedan falsificar. Incluso entonces, el resultado responde a una pregunta más limitada: qué contexto de extensión gestionado por el host inició esta solicitud. Puede no identificar el aviso, el contenido del repositorio ni a la persona que influyó en el contexto.

La prueba útil es sencilla. Pregunta de dónde procede cada campo y quién podría modificarlo.

Por eso, «incluimos el nombre de la extensión en el registro de auditoría» no es una afirmación de seguridad completa. Conserva el nombre. Márcalo como declarado por el host, a menos que la arquitectura dé al intermediario una razón para considerarlo verificado. Esa etiqueta evita que los investigadores futuros traten los metadatos prácticos como una prueba.

La aprobación de sesión tiene un límite útil y otro muy claro

Vale la pena aprobar un proceso del host recién iniciado y verificado. Esto detecta otro ejecutable, una autoridad de firma diferente, una nueva vida del proceso y una ruta de inicio inesperada. También permite que la persona frente al teclado vea quién está a punto de recibir acceso. Para el trabajo rutinario con una credencial limitada, esa interrupción puede ser un buen intercambio.

El límite es que una aprobación de sesión concede a todo el proceso aprobado lo que la sesión permita hacer. Si el proceso aloja muchas extensiones, no puede distinguir una solicitud de la extensión esperada de otra creada por una extensión cargada diferente. Una tarjeta de aprobación clara puede comunicar el firmante y la identidad del proceso del host, pero no debería prometer una atribución a nivel de plugin que no puede ofrecer.

Hay un segundo fallo que los equipos pasan por alto. Aprueban un proceso del editor por la mañana y después instalan o activan una extensión durante la misma sesión de larga duración. Si el host se recarga o carga código nuevo sin cambiar la identidad externa que comprueba el intermediario, la aprobación sigue siendo más amplia de lo que la persona recuerda. La respuesta adecuada depende del comportamiento del host, pero el principio no cambia: los cambios dentro de un host aprobado no son visibles automáticamente para un intermediario externo.

Usa la aprobación de sesión para la pregunta que puede responder: «¿Puede este proceso de host firmado usar esta categoría de acceso mientras exista?». No la conviertas en: «¿Puede esta extensión concreta realizar esta acción irreversible concreta?»

La aprobación por uso compensa la ambigüedad en el momento importante

Para las credenciales sensibles, pide aprobación cuando se forma la acción, no solo cuando aparece el host por primera vez. El aviso debe mostrar suficiente información de la acción propuesta para que una persona pueda decidir de forma razonable: destino, método o destino SSH, etiqueta de la credencial y la parte de la solicitud que tendrá consecuencias.

Supón que un host envía esta solicitud a un intermediario local de acciones:

{
  "channel": "http",
  "credential": "production-deploy",
  "method": "POST",
  "url": "https://deploy.example.internal/releases",
  "body": {"service": "billing", "version": "a1b2c3d"}
}

Una tarjeta de aprobación adecuada debe vincular la decisión al método exacto, el destino, la credencial y el cuerpo, o a un resumen estable del cuerpo. No debe decir solo: «El editor quiere usar production-deploy». Esa redacción convierte la aprobación de una acción en un cheque en blanco para cada llamada que el host pueda hacer antes de que caduque la decisión.

La aprobación por uso no gusta porque interrumpe el flujo. La objeción es razonable para llamadas inofensivas. Pierde fuerza ante una escritura en producción, una credencial de alcance amplio o un comando SSH capaz de cambiar una máquina. La persona que aprueba no necesita identificar con certeza la extensión responsable. Necesita ver la consecuencia que está a punto de salir del equipo y decidir si corresponde.

Una puerta de acceso a la bóveda añade un límite que la aprobación de sesión no puede proporcionar. Mientras la bóveda está bloqueada, se rechaza toda acción, incluidas las llamadas de hosts aprobados previamente. Sallyport aplica ese bloqueo absoluto antes de la autorización de sesión, y una credencial seleccionada puede exigir aprobación en cada uso. Así, el conjunto de controles refleja la realidad: el firmante del host identifica al llamante, la decisión de sesión admite ese proceso durante un tiempo limitado y la decisión por uso cubre la acción sensible.

Las credenciales limitadas reducen el daño de una aprobación correcta

La aprobación no sustituye al alcance de una credencial. Una persona puede aprobar el host correcto y la solicitud correcta, y descubrir después que la credencial permite mucho más de lo que exigía la operación prevista. Es un fallo de diseño de credenciales, no de aprobación.

Divide el acceso según sus consecuencias. Un token que lee un repositorio no debería administrar también todos los proyectos. Una credencial de despliegue no debería crear usuarios ni recuperar secretos que no guardan relación. Para SSH, usa una cuenta separada o una configuración de comando forzado cuando el lado remoto lo permita, en lugar de entregar un shell general a un flujo que solo necesita una tarea de mantenimiento.

La recomendación popular de dar a un agente un único token de desarrollo amplio resulta atractiva porque la configuración tarda cinco minutos. Es un error cuando el token cruza entornos o tiene permisos de escritura. Un token amplio convierte cualquier ambigüedad dentro del host de extensiones en una ambigüedad amplia fuera de él. Las credenciales limitadas facilitan la lectura del aviso de aprobación porque el conjunto de acciones disponibles ya tiene límites claros.

Para las acciones HTTP, limita el destino en el registro de credenciales o en la configuración del intermediario cuando el diseño lo permita. Un token de portador inyectado en cualquier URL arbitraria puede ser exfiltrado por un host al que se haya inducido a llamar a un endpoint controlado por un atacante. Para las acciones SSH, registra el host, la cuenta y la clase de comandos prevista antes de decidir que basta con una aprobación de sesión.

Un fallo conocido empieza con una acción inofensiva de la paleta de comandos

Un desarrollador instala una extensión de asistente y otra de despliegue. Ambas se ejecutan en un único host de extensiones firmado. El desarrollador aprueba el host cuando el asistente pide inspeccionar una API de staging, porque la tarjeta de aprobación muestra correctamente la autoridad de firma del editor.

Más tarde, el desarrollador abre un repositorio que contiene un archivo de tareas con instrucciones para el asistente. El asistente analiza el archivo e invoca un comando del host registrado por la extensión de despliegue. El comando pide al mismo intermediario que use una credencial de producción. La solicitud tiene la misma identidad de proceso firmado que la solicitud de staging. Un intermediario que dependa solo de la aprobación de sesión ve un llamante aprobado y continúa.

En esa secuencia no hace falta falsificar una firma ni comprometer el sistema operativo. El fallo procede de una decisión de aprobación que cubría el host y de una credencial que cubría una acción que el desarrollador no tenía intención de conceder. Un registro de auditoría que solo diga «el editor aprobado hizo una llamada HTTP» no permitirá al equipo saber si la secuencia la inició la extensión de despliegue, el asistente o un archivo de tareas.

Cambia la configuración en tres puntos. Exige aprobación explícita para la credencial de producción en cada uso. Muestra el destino y la información de la versión en esa aprobación. Registra por separado la identidad del host y el contexto de extensión declarado por el host, y conserva el vínculo entre el evento de aprobación y la llamada. La solicitud aún puede ser legítima, pero no podrá pasar por trabajo rutinario en segundo plano.

Los registros de auditoría necesitan una columna de evidencia, no una historia adornada

Los registros se vuelven engañosos cuando reducen los hechos verificados y el contexto declarado por el propio sistema a una sola frase. «El plugin X desplegó el servicio Y» parece preciso, pero puede ocultar una etiqueta de plugin no verificada y una cadena causal desconocida. Registra el evento original junto con su fuente de verdad.

Una estructura de evento útil separa las afirmaciones:

{
  "time": "2026-07-24T10:16:43Z",
  "caller": {
    "signing_authority": "Example Software Team ID ABC123",
    "pid": 8421,
    "started_at": "2026-07-24T09:58:03Z"
  },
  "host_reported_context": {
    "extension_id": "publisher.cloud-deploy",
    "workspace": "/work/payments"
  },
  "action": {
    "channel": "http",
    "method": "POST",
    "destination": "https://deploy.example.internal/releases",
    "credential": "production-deploy"
  },
  "authorization": {
    "session_approved": true,
    "per_use_approved": true
  }
}

La cuestión no es añadir más campos al registro. Es conservar el límite entre un hecho verificado por el sistema y una declaración del host. Durante un incidente, esa diferencia determina si los investigadores pueden rastrear una acción o solo repetir una etiqueta.

También importa que existan pruebas de manipulación. Un registro local que un proceso comprometido pueda reescribir es una evidencia débil de su propio comportamiento. Sallyport proyecta las vistas de sesiones y actividades desde un registro de auditoría cifrado y encadenado mediante hashes, y sp audit verify puede verificar la cadena sin conexión y sin una clave de la bóveda. Esto no resuelve la atribución de extensiones, pero impide que una edición posterior mejore discretamente la historia.

Aísla la operación cuando la atribución debe ser exacta

Algunas acciones necesitan una respuesta más sólida de la que puede ofrecer un host compartido. Si una credencial puede mover dinero, modificar el acceso a producción, borrar datos o ejecutar comandos remotos sin restricciones, enruta la operación a través de un componente con su propia identidad ejecutable y una interfaz limitada. Así, el intermediario puede verificar ese asistente en lugar de inferir la intención a partir de un host lleno de extensiones.

El asistente debe aceptar un esquema de solicitud explícito, rechazar parámetros adicionales y mantener una autoridad reducida. Por ejemplo, un asistente de versiones puede aceptar un nombre de servicio de una lista permitida y un resumen de versión, mientras rechaza URL arbitrarias y fragmentos de shell. El editor principal aún puede iniciar el trabajo, pero no puede convertir al asistente en un cliente de red general.

La separación de procesos no es magia. Si el host puede enviar solicitudes arbitrarias al asistente, solo has trasladado la misma ambigüedad a un proceso nuevo. La interfaz debe eliminar las opciones que el host no debería tener. Un asistente firmado separado junto con una solicitud abierta de «ejecutar cualquier cosa» es puro teatro.

Cuando el aislamiento cuesta demasiado, recurre a la aprobación específica de la acción y a credenciales limitadas. Esa combinación da a una persona la oportunidad de detectar la consecuencia aunque el origen dentro del editor siga sin estar claro. No afirmes que tienes certeza a nivel de plugin si el diseño no puede mostrar de dónde procede.

Trata el texto de aprobación como parte del límite de acceso

Un aviso de aprobación cambia el comportamiento, así que su redacción necesita el mismo cuidado que el código que lo aplica. Si dice «Permitir que el editor acceda al despliegue», los usuarios aprenderán a aprobar una categoría. Si dice «Permitir que este host de extensiones firmado haga un POST de esta versión a este destino usando esta credencial», los usuarios pueden evaluar la acción que están autorizando.

Mantén visible el firmante del proceso, porque ayuda a detectar la aplicación equivocada. Mantén visible el nombre de la extensión si el host lo proporciona, porque ayuda a reconocer el trabajo esperado. Etiquétalo como contexto declarado cuando el intermediario no pueda verificarlo. Las personas gestionan mejor la incertidumbre cuando la interfaz la muestra claramente que cuando una etiqueta pulida sugiere una garantía.

Empieza por inventariar todas las credenciales a las que puede llegar un host de IDE. Para cada una, anota qué aprobación a nivel de host puede heredar de forma segura, qué forma de acción exige una decisión nueva y qué evidencia exacta conserva el registro de auditoría. Si la respuesta a «¿qué extensión hizo esto?» es una suposición, no concedas autoridad como si fuera un hecho.