¿Cómo deben obtener aprobación los builds locales sin firma?

Un build local sin firma no es automáticamente sospechoso. Tampoco tiene una identidad reconocible. Ambos hechos deben convivir. Si no, el flujo de aprobación acaba en uno de dos malos hábitos: las personas desarrolladoras aprueban cualquier proceso anónimo porque necesitan trabajar, o se rinden y ejecutan los agentes con credenciales directas.

La pregunta útil es más concreta: ¿qué pruebas permiten aprobar esta ejecución concreta de un agente compilado localmente sin fingir que todos los procesos de una carpeta conocida merecen la misma confianza? La respuesta es un flujo basado en límites de sesión, procedencia del lanzamiento, alcance de las credenciales y disposición a rechazar solicitudes que no pueden explicarse por sí mismas.

«Sin firma» significa que falta una afirmación, no que exista una calificación de riesgo

El código sin firma no ha hecho una afirmación de identidad respaldada por un editor que puedas verificar mediante una cadena de certificados. Eso no dice por sí solo si el código es malicioso, si fue revisado, si se modificó localmente o si se compiló hace poco a partir del repositorio que tienes abierto. Solo elimina un tipo de evidencia.

Los equipos suelen equivocarse en ambas direcciones. Un grupo trata cualquier ejecutable sin firma como hostil, lo que empuja el desarrollo normal hacia canales paralelos y claves de API personales. Otro usa «sin firma» como sinónimo de «mi código local», creando una categoría de aprobación amplia que un proceso ajeno puede aprovechar.

Mantén separadas estas distinciones:

• Identidad del editor responde a quién firmó un build distribuido.
• Procedencia del build responde qué código fuente, revisión, máquina y comando produjeron el ejecutable.
• Procedencia de ejecución responde qué lanzó ahora el proceso que solicita acceso.
• Autoridad de la acción responde qué credencial o acceso remoto puede utilizar ese proceso.

Una firma puede ayudar con la primera pregunta. Un flujo local limpio debe responder las otras tres. Si una persona desarrolladora compila un cliente de agente desde un worktree, su confianza suele proceder del estado del repositorio y del comando que acaba de ejecutar, no de un certificado público. La experiencia de aprobación debe mostrar esas pruebas en lugar de convertir la ausencia de certificado en un veredicto.

La documentación de firma de código de Apple marca el mismo límite de una forma más formal. Un requisito designado identifica una instancia de código firmado según la política que lo comprueba; no demuestra que el código sea adecuado para todos los recursos o acciones futuras. Apple también señala que cada subsistema de macOS aplica su propia política de confianza. Por eso, una pasarela de acciones no debe convertir el estado de firma en una decisión universal de permisos.

Un canal para builds locales necesita pruebas que otro proceso no pueda tomar prestadas

Crea un canal de aprobación propio para los clientes de agentes compilados localmente. No los mezcles en una categoría llamada «sin firma», «desarrollo» o «terminal». Esas etiquetas abarcan demasiados procesos para resultar útiles.

Antes de aprobar una sesión, el canal debe solicitar cuatro pruebas:

1. La ruta del ejecutable debe estar dentro de un checkout o directorio de salida controlado por la persona desarrolladora.
2. El proceso padre debe ser un lanzador esperado, normalmente una terminal, una tarea del IDE o un script envoltorio propiedad del equipo.
3. El estado del repositorio y el comando de build deben poder inspeccionarse fácilmente, sin reconstruir el día de memoria.
4. El destino y la credencial solicitados deben corresponder al trabajo en curso.

Ninguna de estas señales es perfecta por sí sola. Juntas dificultan que una descarga aleatoria, un proceso auxiliar en segundo plano o una dependencia comprometida se hagan pasar por una ejecución local rutinaria.

Aquí es donde los equipos suelen recurrir a un motor de políticas: permitir rutas bajo un directorio, aceptar comandos cuyo nombre empiece por agent o excluir cualquier cosa lanzada por un IDE concreto. No lo hagas. Una regla estática resulta atractiva porque elimina interrupciones, pero convierte una decisión fácil de revisar en una excepción duradera. Cualquier proceso que pueda preparar la ruta o la cadena de padres adecuada hereda la excepción.

Usa la aprobación humana en el límite de la sesión. La tarjeta de aprobación debe mostrar la autoridad de firma del proceso cuando exista, pero un build sin firma necesita más contexto junto a ese campo: ruta del ejecutable, comando padre, directorio de trabajo cuando esté disponible y destino al que pretende llegar. Así la persona desarrolladora puede responder una pregunta real: «¿Es este el cliente que acabo de compilar para esta tarea?»

La autorización por sesión de Sallyport encaja en este canal porque solicita aprobación una vez para un proceso de agente nuevo y la conserva solo hasta que el proceso termina. La unidad de decisión es la identidad del proceso, no una clase imprecisa de software sin firma.

Una ruta conocida es una prueba, no una identidad

Una ruta como ~/src/agent-client/dist/agent transmite una historia plausible y por eso tranquiliza. No es un límite de identidad. Un proceso malicioso puede ejecutarse desde allí si puede escribir en esa ubicación, reemplazar una salida, cambiar un enlace simbólico o convencer a un lanzador de resolver otro ejecutable.

Empieza por hacer que la historia legítima sea sencilla y repetible. Cada persona desarrolladora debería tener una ubicación normal para sus checkouts. La salida del build debe permanecer dentro de ese checkout o en un directorio predecible donde solo pueda escribir la cuenta de esa persona. Evita carpetas de build compartidas, Descargas, directorios temporales, carpetas sincronizadas y raíces de proyectos donde los scripts de paquetes reescriban ejecutables habitualmente.

Un contrato de lanzamiento práctico puede ser tan pequeño como este:

#!/bin/zsh
set -eu

repo="$HOME/src/agent-client"
cd "$repo"

git status --short
git rev-parse --short HEAD
exec ./build/agent-client --mcp

Lo importante no es la sintaxis del shell, sino las pruebas que deja. El shell padre tiene una ruta de script conocida, el directorio de trabajo apunta a un checkout, la revisión de Git se muestra antes de que empiece el cliente y exec sustituye el shell por el programa esperado en lugar de dejar una cadena de procesos confusa.

No permitas que este script descargue una versión, elija una rama desde una variable de entorno, ejecute un hook del gestor de paquetes o consulte un archivo de configuración mutable fuera del checkout. Esas comodidades hacen menos útil el contrato de lanzamiento porque quien revisa la aprobación ya no puede saber qué seleccionó realmente el script.

Si el cliente del agente necesita código generado, genéralo como parte del comando de build explícito. Si necesita un archivo de configuración local, pasa la ruta de forma visible y mantenlo fuera del repositorio solo cuando contenga ajustes específicos de la máquina. No introduzcas credenciales en él. La pasarela existe para que el cliente no las necesite.

Inspecciona el proceso antes de aprobar la sesión

Una buena decisión de aprobación lleva segundos, pero no debe depender de la memoria. Cuando un proceso local nuevo solicite llamar a una API o abrir SSH, inspecciona su ejecutable y su cadena de padres antes de hacer clic en aprobar.

En macOS, estos comandos ofrecen una primera revisión útil. Sustituye el PID de ejemplo por el que muestre el visor de procesos o la terminal:

pid=48271

ps -o pid=,ppid=,user=,lstart=,command= -p "$pid"
ps -o pid=,ppid=,command= -p "$(ps -o ppid= -p "$pid" | tr -d ' ')"
lsof -a -p "$pid" -d cwd -Fn

El formato de salida debería parecerse a este:

48271 47990 alex Tue Jul 22 10:14:03 2026 /Users/alex/src/agent-client/build/agent-client --mcp
47990 23112 /bin/zsh /Users/alex/src/agent-client/scripts/run-local-agent
n/Users/alex/src/agent-client

Estás comprobando una cadena, no recopilando curiosidades. El binario debe estar en la ubicación de build esperada. El padre debe ser tu lanzador conocido. El directorio actual debe corresponder al checkout. Un proceso que proceda de /private/var/folders, ~/Downloads, una caché de paquetes desconocida o un envoltorio inesperado no supera la revisión aunque su nombre de comando parezca correcto.

Después, inspecciona el ejecutable:

client="$HOME/src/agent-client/build/agent-client"
file "$client"
codesign --display --verbose=4 "$client" 2>&1 | sed -n '1,18p'
shasum -a 256 "$client"

Un binario sin firma puede hacer que codesign informe de que no está firmado. Un binario firmado ad hoc muestra una firma sin una autoridad pública de firma. Sigue siendo información útil, pero no la interpretes como una identidad del equipo. Apple describe la firma ad hoc como «Sign to Run Locally» y explica que su requisito designado está vinculado a esa versión concreta del código. Un rebuild cambia las pruebas, precisamente por eso la aprobación de sesión no debe sobrevivir al reemplazo del proceso.

El hash sirve para comparar, no es una señal de confianza. Ayuda cuando dos personas necesitan comprobar que ejecutaron la misma salida a partir de la misma revisión. No hace seguro un binario solo porque tenga 64 caracteres hexadecimales junto a él.

La persona desarrolladora debe rechazar la solicitud si cualquier parte de la cadena resulta sorprendente. No apruebes primero para investigar después de la llamada a la API. El momento de la aprobación es cuando la incertidumbre debe costar unos minutos, no una investigación de incidente.

Usa la sesión como límite entre un build y el siguiente

El límite de sesión resuelve un problema que las listas de rutas permitidas no pueden resolver: el código local cambia constantemente. Una persona puede recompilar el cliente diez veces en una hora. Cada salida puede tener un grafo de dependencias diferente, otro manejo de comandos o una rama temporal de depuración que envíe solicitudes a un lugar inesperado.

Haz que el proceso de lanzamiento sea desechable. Inicia el cliente para una tarea, aprueba ese proceso tras revisarlo y deja que la aprobación expire cuando termine. Cuando la persona recompila, cambia de rama, modifica el envoltorio o reinicia el cliente, obtiene un proceso nuevo y una decisión nueva.

Esto solo parece incómodo cuando la sesión está mal definida. Si el cliente se inicia y se detiene para cada llamada de herramienta, corrige su ciclo de vida o utiliza un supervisor local intencionado que siga siendo transparente en el árbol de procesos. No resuelvas la rotación haciendo permanente la aprobación. Un proceso de vida corta debe seguir siendo de vida corta.

Este flujo funciona bien para una persona que ejecuta un agente de programación compilado localmente contra un entorno de pruebas:

1. Compila desde el checkout y muestra la revisión y cualquier cambio sin confirmar.
2. Lanza el cliente mediante el script envoltorio incluido en el repositorio.
3. En la primera solicitud de autorización, confirma la ruta del proceso, el comando padre y el servicio de destino.
4. Aprueba la sesión si esos datos coinciden con la tarea.
5. Cierra el cliente al terminar la tarea y recompila o vuelve a lanzarlo para la siguiente tarea distinta.

Este flujo ofrece una recuperación clara. Si un build resulta dudoso, detenlo. No hay un permiso oculto que desenredar ni un archivo de reglas que haya acumulado silenciosamente excepciones para medio equipo.

No confundas la aprobación de una sesión con la aprobación de un repositorio. Un repositorio puede estar limpio mientras el comando de lanzamiento es incorrecto. Un comando puede ser correcto mientras la rama es experimental. Una decisión de sesión dice que este proceso, con este contexto, puede realizar llamadas ordinarias durante la ejecución actual.

Reserva la aprobación por llamada para las consecuencias irreversibles

La aprobación de sesión es el valor predeterminado adecuado para el tráfico de desarrollo repetible: leer metadatos de incidencias, consultar una API de pruebas, obtener un repositorio por SSH o actualizar un registro de prueba desechable. Exigir un gesto humano en cada llamada enseña a aprobar sin leer.

Algunas credenciales deben seguir requiriendo aprobación en cada uso. Elígelas según las consecuencias de la acción remota, no según el dramatismo asociado al secreto.

Usa aprobación por llamada para credenciales que puedan:

• escribir en un entorno de producción;
• publicar un paquete, una versión o un artefacto de despliegue;
• acceder a una exportación de datos de clientes u otro conjunto concentrado de información sensible;
• modificar miembros de la organización, ajustes de autenticación o controles de recuperación;
• llegar a un host SSH de producción.

No marques así todos los tokens de API de desarrollo. Eso provoca fatiga de aprobación, y la fatiga convierte a quien revisa con cuidado en alguien que pulsa botones. La pasarela debe hacer que los momentos peligrosos destaquen lo suficiente para que se noten.

El detalle de la solicitud importa tanto como el segundo aviso. En HTTP, muestra el método y el destino, además de la parte suficiente de la ruta para identificar la acción sin volcar contenido sensible en la superficie de aprobación. GET /v1/test-runs/123 y DELETE /v1/projects/123 nunca deberían parecer intercambiables. En SSH, muestra el host y la cuenta, y pide confirmar por qué ese host pertenece a la tarea actual.

Una exigencia por llamada también frena a un cliente modificado localmente. Puedes sentirte cómodo aprobando una sesión de un build experimental nuevo que lee de un servicio de staging. Aun así, deberías detenerte antes de permitir que ese mismo build publique una versión en producción. Esa pausa es precisamente el objetivo.

Trata los rebuilds, cambios de rama y envoltorios como pruebas nuevas

Las personas desarrolladoras suelen tomar una decisión de aprobación por la mañana y cambiar los hechos durante todo el día. Actualizan una rama, ejecutan un generador de código, actualizan dependencias, modifican un archivo de prompts, añaden un alias de shell o sustituyen un script envoltorio. El binario puede conservar el mismo nombre y ruta mientras su comportamiento cambia de forma importante.

Adopta una regla sencilla: si cambia el ejecutable, su lanzador o el entorno previsto, termina la sesión y vuelve a lanzarlo. No necesitas una ceremonia formal para cada edición. Sí necesitas la disciplina de no trasladar el contexto de ayer a un build nuevo.

Hay tres eventos que merecen una pausa automática en tu flujo:

• Cambiaste la rama, el commit, el archivo de bloqueo de dependencias o la salida generada.
• Cambiaste el script que lanza el cliente o las variables de entorno que determinan su comportamiento.
• El agente ahora quiere otro host de API, otro host SSH o una credencial con consecuencias más amplias.

Un cambio de rama se subestima porque el nombre del binario permanece estable. Sin embargo, una rama de funcionalidad puede contener una integración experimental, un manifiesto de herramientas modificado o un endpoint de depuración. La respuesta no es prohibir las ramas, sino hacer visible y revisable la primera solicitud de la nueva ejecución.

Las variables de entorno merecen la misma cautela que los argumentos del ejecutable. Un cliente iniciado con API_BASE_URL, SSH_AUTH_SOCK, PATH, DYLD_* o una ubicación de configuración personalizada puede comportarse de forma distinta al código fuente que inspeccionaste. El envoltorio debe configurar solo las variables que el cliente necesita, mostrar los valores no secretos que afectan al enrutamiento y rechazar los valores ausentes en lugar de cargar un perfil de shell enorme.

Por ejemplo, esto se puede revisar:

export AGENT_ENVIRONMENT=staging
export AGENT_API_ORIGIN=https://staging.example.internal
exec ./build/agent-client --mcp

Esto no:

source "$HOME/.agent-env"
eval "$(tooling configure-agent)"
exec "$AGENT_BIN" "$@"

La segunda forma puede ser cómoda, pero oculta el ejecutable, el origen de la configuración, los argumentos y los efectos secundarios. Obliga a quien aprueba el proceso a confiar en una pila de indirecciones. El desarrollo local ya tiene suficientes piezas móviles.

Mantén las credenciales fuera del cliente, incluso si el cliente es tuyo

Un cliente compilado localmente es más fácil de confiar cuando nunca recibe la credencial que quiere utilizar. Si el cliente lee un token de API de una variable de entorno o una clave SSH de un archivo, puede imprimirlo, reenviarlo, guardarlo en caché, incluirlo en un informe de error o entregarlo a un subproceso. La confianza de la persona desarrolladora en su propio build no cambia esa exposición.

Coloca el secreto en la pasarela de acciones y permite que el cliente solicite una acción por referencia. El cliente debe proporcionar el contexto de la solicitud HTTP o del comando SSH necesario para trabajar. La pasarela inyecta la credencial, ejecuta la llamada y devuelve el resultado. Así la decisión de aprobación se concentra en la acción, no en si el cliente puede poseer indefinidamente un token portador.

Para HTTP, crea credenciales separadas para entornos y propósitos distintos. Un token de staging no debe llegar a producción solo porque el cliente haya indicado otro host. En SSH, usa entradas de host o registros de credenciales diferentes para roles distintos. No dependas de una única clave con todos los privilegios y de la promesa de que alguien elegirá el destino correcto.

Sallyport guarda las credenciales de API y SSH en un almacén cifrado y ejecuta la acción directamente, de modo que el agente recibe resultados y no secretos en texto plano. Este diseño es especialmente importante para los builds locales, donde los cambios en el código son esperables y una variable de entorno filtrada queda a un simple print de depuración.

La separación también mejora la respuesta ante incidentes. Si un cliente se comporta de forma extraña, puedes detener o revocar su sesión sin rotar todos los secretos que quizá cargó en memoria. La barrera del almacén sigue siendo absoluta mientras está bloqueado, y un almacén bloqueado rechaza acciones en lugar de intentar adivinar la intención de la persona desarrolladora.

El registro de auditoría debe resolver desacuerdos, no limitarse a acumular eventos

Cuando un flujo de aprobación para builds locales funciona, de vez en cuando alguien preguntará por qué un agente accedió a un servicio o si un proceso seguía activo después de una transferencia. La respuesta debe salir de un registro de eventos, no de conjeturas, del historial de la terminal o de un mensaje escrito después de los hechos.

Registra dos perspectivas de la misma actividad subyacente. Una debe mostrar las ejecuciones de los agentes y permitir la revocación inmediata. La otra debe mostrar las acciones HTTP y SSH individuales. Mantén la relación entre ambas para que quien revisa pueda pasar de una solicitud sospechosa a la sesión que la autorizó y después al contexto del proceso que originó la decisión.

Un registro resistente a manipulaciones resulta especialmente útil porque los mismos usuarios que revisan los builds locales pueden modificarlos. Sallyport proyecta sus diarios de Sessions y Activity desde un único registro de auditoría cifrado y encadenado mediante hashes. sp audit verify comprueba esa cadena sin conexión sobre el texto cifrado y sin requerir una clave del almacén. Así el equipo puede verificar la integridad sin dar a quien revisa acceso a los secretos detrás de las acciones.

Ejecuta la verificación como parte de una revisión o simulacro de incidente:

sp audit verify

El resultado esperado es una confirmación clara o un informe que identifique un problema en la cadena. Trata un fallo de verificación como un problema operativo hasta entenderlo. No borres el diario, reinstales la aplicación ni aceptes una línea base nueva antes de conservar los registros afectados.

El diario no sustituye la revisión en el momento de aprobar. Te permite comprobar si el proceso produce pruebas realmente útiles. Si el registro solo dice que «un cliente sin firma» hizo una llamada, mejora el contrato de lanzamiento y el contexto de aprobación. Si muestra el proceso, la sesión, el destino, la hora y la acción, el equipo puede investigar sin convertir cada ordenador de desarrollo en un proyecto forense.

Las convenciones del equipo evitan que los avisos de aprobación se conviertan en ruido de fondo

La parte más difícil de un flujo de aprobación para builds locales no es la línea de comandos. Es conservar el significado humano de una aprobación después de meses de trabajo normal.

Escribe una convención breve para agentes locales y mantenla cerca del repositorio, no enterrada en un manual de seguridad. Debe indicar dónde viven los checkouts admitidos, cómo son los scripts de lanzamiento, qué entornos cuentan como desarrollo normal, qué credenciales requieren aprobación por llamada y qué hacer cuando el aviso muestra un proceso inesperado.

Normaliza el rechazo. Una persona que pulsa «Rechazar» porque el proceso padre parece extraño no debería sentir que ha bloqueado el progreso. Debe detener el proceso, inspeccionarlo, volver a lanzarlo mediante el envoltorio conocido y aprobar la ejecución limpia. Es más rápido que normalizar un proceso misterioso e intentar explicarlo después.

Revisa la convención después de una sorpresa real: un script de paquetes reescribió una salida, un IDE lanzó un auxiliar inesperado, una rama apuntó al entorno equivocado o un agente pidió una credencial ajena a su tarea. Estos fallos son útiles porque muestran qué prueba faltaba. No respondas añadiendo una regla permanente de permiso. Refuerza el contrato de lanzamiento, mejora lo que muestra la superficie de aprobación o reduce el alcance de la credencial.

Una persona que compila su propio agente no debería tener que elegir entre teatro de seguridad e interrupciones constantes. Ofrécele una aprobación de sesión específica para un proceso visible, mantén las llamadas con consecuencias detrás de una decisión separada y exige una revisión nueva cada vez que cambie la historia del build local. Es suficientemente estricto para detectar el proceso equivocado y suficientemente práctico para que la gente siga utilizándolo.