Credenciales

El panel de Credenciales es donde le das a un espacio de trabajo los secretos que necesita su agente — tokens de git, claves SSH, credenciales de nube, contraseñas de bases de datos — sin que ninguno de esos secretos entre jamás en la VM. Cada valor que escribes aquí se almacena cifrado en tu Mac. Dentro del sandbox el agente solo ve un falso que preserva la estructura (por ejemplo brm_…); cuando una solicitud realmente sale de tu Mac, el proxy del lado del anfitrión intercambia el falso por el valor real, acotado al anfitrión de destino.

Esta página es la referencia campo por campo del panel. El mecanismo que hay detrás — el límite de red, los falsos deterministas, el acotamiento por anfitrión, el resignador de AWS de cierre seguro y el detector de compromisos — está documentado por completo en Credenciales y el límite de red. Lee ese capítulo para conocer el modelo de seguridad; lee esta página para rellenar los campos. Los controles de aprobación y política de escritura por credencial ahora residen en el panel de Salvaguardas, no aquí.

Nota: La captura anterior es previa al rediseño y puede mostrar la antigua pila de secciones plegables. El panel actual muestra solo las credenciales que has configurado, agrupadas bajo encabezados de categoría, más los dos botones que se describen a continuación.

El panel se abre con Identidad de Git fijada en la parte superior, seguida de una lista de las credenciales que ya has configurado — nada más. Cada credencial configurada es una fila; las familias vacías que solían aparecer plegadas en el panel han desaparecido. Dos botones en la parte inferior, Añadir credencial e Importar archivo env…, son la forma de añadir más. Nada se aplica hasta que haces clic en Guardar.

Identidad de Git

Los dos campos de la parte superior establecen la identidad de autor de git escrita en ~/.gitconfig dentro de la VM:

• user.name — texto de ejemplo Tu Nombre.
• user.email — texto de ejemplo [email protected].

El pie de texto dice: Escrito en ~/.gitconfig en la VM. Deja ambos en blanco para conservar los valores predeterminados de git. Estos no son secretos y no se intercambian — son configuración simple para que los commits que hace el agente se atribuyan correctamente. Dejar un campo en blanco deja intacto ese valor predeterminado de git.

La lista de credenciales configuradas

Debajo de Identidad de Git, el panel enumera solo las credenciales que realmente producen un intercambio al iniciar la sesión, agrupadas bajo encabezados de categoría:

Cada fila muestra un icono, un título y el anfitrión o los anfitriones a los que está acotada la credencial (para un token de git, user@host; para una base de datos o un registro, su anfitrión; para AWS, amazonaws.com; y así sucesivamente). Un menú ⋯ a la derecha — también accesible haciendo clic en la fila — ofrece Editar… y Quitar:

• Editar… reabre el editor de esa credencial para que puedas cambiar o revelar sus campos.
• Quitar elimina la credencial del espacio de trabajo. (No hay más deshacer que volver a añadirla; no se elimina nada del disco hasta que Guardas.)

Las filas bajo AGENTES son la única excepción: su menú dice Editar en Agentes… y no tiene Quitar, porque las claves de agentes pertenecen al panel de Agentes. Al elegirlo se cambia el editor a ese panel.

Cuando un espacio de trabajo no tiene ninguna credencial, la lista se sustituye por un estado vacío — Aún no hay credenciales — que te recuerda que los valores reales permanecen en tu Mac y que la VM solo contiene un falso.

Añadir una credencial

Haz clic en Añadir credencial para abrir la hoja de selección. Enumera todos los tipos de credencial que la app puede añadir; cada entrada abre el editor de ese tipo:

Las claves de API de agentes deliberadamente no están en este selector; una nota al pie te recuerda que las claves de Anthropic, OpenAI y xAI se configuran en el panel de Agentes. Cada editor es una hoja con un botón Hecho; los campos de cada tipo se describen en las secciones siguientes.

Importar un archivo env

Haz clic en Importar archivo env… para extraer credenciales de un archivo .env existente — o de un ~/.bashrc. El analizador lee asignaciones simples KEY=VALUE y export KEY=VALUE, elimina las comillas circundantes y los # comentarios finales, y toma la última asignación cuando un nombre se repite. Nunca ejecuta un shell: cualquier valor que necesitaría interpolación (una referencia $VAR o una sustitución de comando $(…)) se omite en lugar de importarse mal, de modo que apuntarlo a un .bashrc real es seguro.

Las variables del archivo se muestran entonces en una hoja de revisión titulada Importar desde <filename>, dividida en dos grupos. Todos los valores están enmascarados en esta hoja.

Las variables Reconocidas se asignan automáticamente a su tipo de credencial:

Cada fila reconocida tiene una casilla de verificación. Un token de git pide además un Nombre de usuario de Git (texto de ejemplo you) para que la credencial esté completa. Si una variable se asigna a algo que el espacio de trabajo ya tiene configurado, su fila se marca como Ya configurada — marca para sobrescribir. y se deja sin marcar, de modo que una reimportación nunca sobrescribe silenciosamente un secreto existente.

Las variables No reconocidas se pueden importar como tokens genéricos de Otra clave de API. Cada fila lleva un campo Anfitrión(es) — una lista separada por comas de nombres de anfitrión en los que debe intercambiarse el falso (se permiten varios anfitriones; en blanco significa cualquier anfitrión). El nombre de la variable de entorno se reutiliza como el nombre del token y como la variable bajo la que se exporta el falso.

El botón dice Importar N credenciales y refleja solo las filas que dejaste marcadas. La importación fusiona las selecciones en el panel; aún debes hacer clic en Guardar para conservarlas.

Claves SSH

El editor de Clave SSH gestiona las claves con las que el espacio de trabajo puede autenticarse por SSH. Los bytes de la clave privada nunca entran en la VM: la firma se sirve a través de un puente ssh-agent en el mismo proceso sobre vsock, de modo que el invitado puede solicitar firmas pero nunca puede leer la clave.

Hay dos fuentes de claves:

• El propio par de claves ed25519 del espacio de trabajo. Los espacios de trabajo nuevos llevan un conmutador Generar un par de claves ed25519 premarcado (a menos que tu plantilla de preferencias ya proporcione una clave). Una vez que existe una clave, el editor muestra su clave pública con los botones Copiar y Abrir página de claves de GitHub (para pegarla en github.com/settings/keys) y un conmutador Regenerar.
• Claves SSH importadas. Bajo Claves SSH importadas, haz clic en Importar… para abrir un selector de archivos; una hoja pide entonces una Etiqueta y, si la clave está cifrada, una Frase de contraseña. Las frases de contraseña se almacenan en el Llavero de macOS, y las claves importadas se cargan en el ssh-agent por espacio de trabajo en cada inicio de sesión. Se admiten claves RSA, ed25519 y ecdsa.

Tokens de Git (GitHub, GitLab, Bitbucket)

El editor de Token de Git contiene tokens de acceso personal para git sobre HTTPS, divididos en los grupos GitHub, GitLab y Bitbucket. Como dice su pie de texto: los tokens de acceso personal se almacenan cifrados en el anfitrión, y el proxy los intercambia en las solicitudes salientes de modo que la VM solo contiene el falso. gh y glab recogen GH_TOKEN / GITLAB_TOKEN automáticamente.

Haz clic en Añadir token en un grupo para añadir una fila. Cada fila toma un Anfitrión, un Nombre de usuario y un Token de acceso personal (con un botón de ojo para revelar y un enlace a la página de tokens de ese forge). El falso se escribe en ~/.git-credentials y en las configuraciones de las CLI gh / glab dentro de la VM. El campo de anfitrión te permite apuntar una entrada a github.com, gitlab.com o una instancia autoalojada de GitLab/Gitea/Bitbucket.

Linear

El editor de Clave de API de Linear toma una única clave de API personal (texto de ejemplo con forma lin_api_…, con un enlace Abrir ajustes de API de Linear). Se inyecta en la VM como LINEAR_API_KEY, que el SDK de Linear, los servidores MCP y las herramientas de CLI recogen automáticamente, y se intercambia de falso a real solo en las solicitudes a linear.app (incluidos api.linear.app y mcp.linear.app). Una clave de Linear en el espacio de trabajo es también el requisito previo para los desencadenantes de automatización programada de incidencias de Linear.

Kubernetes

El editor de Kubernetes contiene una fila por contexto de clúster. Bromure Agentic Coding construye un ~/.kube/config sintético dentro de la VM para que kubectl hable con el proxy, nunca directamente con el servidor de API; la identidad real permanece en el anfitrión.

Cada contexto tiene un nombre, una URL del servidor, un certificado CA opcional (PEM, usado para que el proxy pueda verificar el servidor de API upstream), un Espacio de nombres y un método de autenticación elegido con un control segmentado:

• Token bearer — un token estático, intercambiado por el valor real en la red.
• Certificado de cliente — el certificado y la clave reales se registran en el anfitrión para el TLS mutuo upstream; la VM obtiene un certificado autofirmado desechable.
• Plugin exec — un Comando, unos Args y un selector de Actualización (1–60 minutos). El plugin se ejecuta en el anfitrión en cada intervalo de actualización y el token nuevo se introduce en el mapa de intercambio; el kubectl de la VM nunca ejecuta el plugin.

Una insignia en cada fila muestra de qué tipo (token / certificado / exec) es. Usa Importar archivo… para analizar un kubeconfig existente en una fila por contexto, o Añadir contexto para añadir uno a mano. La política de escritura por contexto correspondiente se establece en el panel de Salvaguardas.

DigitalOcean

El editor de Token de DigitalOcean toma un único token de acceso personal (texto de ejemplo con forma dop_v1_…, con un enlace a la página de tokens de DigitalOcean). Se inyecta como DIGITALOCEAN_ACCESS_TOKEN y se escribe en ~/.config/doctl/config.yaml, de modo que doctl auth init es innecesario. El token se intercambia de falso a real en las solicitudes a digitalocean.com, y una segunda entrada de intercambio cubre la forma Basic-auth en base64 que se usa cuando docker login o doctl registry login se autentican contra registry.digitalocean.com.

AWS

El editor de Credenciales de AWS configura credenciales para la CLI aws, los SDK, terraform y el modo de autenticación Bedrock de Claude Code. El secreto real nunca llega a la VM — el anfitrión vuelve a firmar las solicitudes SigV4 con el material real, y una solicitud que evita el proxy obtiene una InvalidSignatureException de AWS. Un control segmentado de Método de autenticación selecciona entre:

• Claves estáticas — ID de clave de acceso, Clave de acceso secreta, un Token de sesión opcional (solo STS) y una Región predeterminada, más un enlace Abrir página de credenciales de IAM.
• SSO / Identity Center — un selector de carpeta Conceder acceso a ~/.aws, y luego un selector de Perfil SSO rellenado a partir de los perfiles descubiertos en tu ~/.aws/config (con un botón de actualización). Las credenciales de rol temporales se resuelven en el anfitrión, desencadenando aws sso login en tu navegador cuando el token en caché ha expirado.

El manejo completo de AWS — el ayudante credential_process, el resignador y sus límites — está en Credenciales y el límite de red.

Registros de contenedores

El editor de Registro de contenedores contiene la autenticación HTTP Basic por registro para docker pull / docker push. Como explica el pie de texto, la contraseña real nunca se escribe en la VM — bromure coloca un falso base64("<user>:<derived>") en ~/.docker/config.json, y el proxy sustituye el valor real en la red cuando la solicitud llega al anfitrión de registro correspondiente.

El menú Añadir ofrece preajustes — Docker Hub (docker.io), GitHub Container Registry (ghcr.io), GitLab Container Registry (registry.gitlab.com), Quay (quay.io) y Otro anfitrión… — más Importar config.json…, que extrae entradas de un ~/.docker/config.json existente. La importación omite las entradas credsStore / credHelpers (sus contraseñas residen en el llavero del SO en lugar de en el archivo) e informa de cuántas se omitieron. Cada fila de registro toma un Anfitrión, un Nombre de usuario y una Contraseña o token. La política de escritura de push/pull/delete correspondiente se establece en el panel de Salvaguardas.

Bases de datos (MongoDB, ClickHouse, Elasticsearch)

El editor de Base de datos contiene una fila por endpoint HTTPS, agrupadas por motor. El falso se exporta bajo los nombres de variable de entorno que enumeres y se intercambia por el valor real dondequiera que aparezca — encabezado, parámetro de consulta o cuerpo de la solicitud.

Cada fila de endpoint tiene:

• Nombre — nombre para mostrar opcional.
• Anfitrión — el nombre de anfitrión desnudo; acota tanto el intercambio como la salvaguarda del endpoint.
• Autenticación — un control segmentado: Nombre de usuario + contraseña, Clave de API o Token bearer. MongoDB usa por defecto Clave de API; ClickHouse y Elasticsearch usan por defecto Nombre de usuario + contraseña.
• Nombre de usuario — solo para Basic auth.
• Secreto — con un botón de ojo para revelar.
• Variable(s) de entorno — una lista separada por comas de los nombres bajo los que debe exportarse el falso.

Los endpoints de base de datos nuevos establecen por defecto su política de escritura por endpoint en Preguntar antes de escribir, definida en el panel de Salvaguardas — la clasificación específica de cada motor (qué acciones de Mongo, qué palabras clave de SQL, qué rutas de Elasticsearch cuentan como escrituras) reside allí.

Otras claves de API

El editor de Otra clave de API es la vía de escape para cualquier servicio que Bromure Agentic Coding no maneje automáticamente. Cada entrada es una regla de intercambio manual:

• Nombre — una etiqueta para la entrada.
• Secreto real — enmascarado (texto de ejemplo con forma sk_live_…).
• Variable de entorno — el nombre bajo el que se exporta el falso dentro de la VM. Dejar esto en blanco no exporta nada; entonces copiarías el falso del banner de bienvenida de la sesión.
• Anfitrión de API (opcional) — el anfitrión o los anfitriones a los que se acota el intercambio (exacto o subdominio, separados por comas). En blanco significa "inyectar en cualquier anfitrión".

La VM ve un falso brm_… acuñado y el proxy lo intercambia de vuelta en la red.

Advertencia: Un Anfitrión de API en blanco deliberadamente nunca está protegido por el detector de compromisos — es una elección explícita de "inyectar en cualquier anfitrión". Para mantener bajo control un secreto sin acotar, dale un anfitrión o activa Preguntar antes de usar para él en el panel de Salvaguardas.

Las políticas de aprobación y escritura residen en Salvaguardas

Ya no hay casillas de verificación Requerir aprobación para usar en el panel de Credenciales. La puerta de consentimiento por credencial — ahora presentada como Preguntar antes de usar — y la política de escritura de cada servicio residen ambas en el panel de Salvaguardas, que enumera una fila por credencial configurada. Configura el secreto aquí; decide cómo se le permite al agente usarlo allí.

Cómo se almacena el panel

Todo en este panel es un secreto, así que al guardar se separa del profile.json en texto plano y se coloca en el secrets.enc cifrado del espacio de trabajo (AES-GCM, con clave del Llavero de macOS, permisos 600). Los proveedores manejados automáticamente — Anthropic, OpenAI, GitHub, GitLab, DigitalOcean, Kubernetes — no necesitan ninguna entrada manual más allá de lo que configures aquí; la propia clave de API del agente principal se establece en el panel de Agentes.

Referencia de ajustes

Las políticas Preguntar antes de usar y de escritura por credencial se establecen en el panel de Salvaguardas.

Capítulos relacionados

• Credenciales y el límite de red — el modelo de seguridad completo que hay detrás de este panel.
• Agentes — la clave de API del agente principal y los modos de autenticación por suscripción/Bedrock.
• Salvaguardas — aprobación por credencial y políticas de escritura por servicio para estos mismos secretos.
• Referencia de ajustes — todos los paneles de un vistazo.