Salvaguardas

Las Salvaguardas son el control del lado del anfitrión de Bromure Agentic Coding sobre cómo pueden usarse las credenciales de un espacio de trabajo. Como lo expresa el propio panel: las salvaguardas rigen cómo se usan las credenciales configuradas de este espacio de trabajo. Preguntar antes de usar muestra una confirmación del lado del anfitrión la primera vez que se usa una credencial en una sesión. Una política de escritura elimina o bloquea las operaciones destructivas en la red — aplicada en el proxy, de modo que un agente comprometido dentro de la VM no puede eludirla. Aquí solo aparecen las credenciales que has configurado.

El panel muestra una fila por cada credencial configurada, en el mismo orden en que las lista el panel Credenciales. Cada fila muestra el título de la credencial y su(s) anfitrión(es) y lleva dos controles:

• Una casilla Preguntar antes de usar (etiquetada Requerir aprobación para usar en el propio control) — la puerta de consentimiento por credencial, trasladada aquí desde el panel Credenciales.
• Un selector de política de escritura en línea, mostrado solo cuando el servicio de la credencial admite uno.

Si el espacio de trabajo no tiene credenciales, el panel muestra un estado vacío — No hay credenciales que proteger — que te remite de nuevo al panel Credenciales. Los detalles de aplicación, los formatos de error y los registros de auditoría se cubren en el análisis detallado de inyección de prompts y salvaguardas.

Preguntar antes de usar

Cada fila tiene una casilla Preguntar antes de usar, desactivada de forma predeterminada. Cuando está activada, la primera vez que se usa esa credencial en una sesión el proxy se detiene y muestra un diálogo de consentimiento que ofrece concesiones limitadas en el tiempo — 5 minutos, 1 hora o el resto de la sesión — o No permitir. Las concesiones existen solo en memoria y se borran cuando se cierra la ventana de sesión, y cada decisión activa aparece en Ventana → Aprobaciones de credenciales…. El modelo de consentimiento, la fusión de prompts concurrentes y la ventana de aprobaciones se cubren en Credenciales y el límite de red.

Esta casilla se aplica a cualquier credencial, incluidas las claves de API simples, las claves SSH y los tokens manuales — las filas que no tienen política de escritura muestran solo este control.

Política de escritura

Cuando el servicio de una credencial puede clasificar su propio tráfico, la fila también muestra un selector de política de escritura. Aparece para:

• Forjas de Git — tokens de GitHub, GitLab, Bitbucket.
• Credenciales de AWS.
• Tokens de DigitalOcean.
• Registros de contenedores (Docker Hub, ghcr.io y otros).
• Contextos de Kubernetes.
• Endpoints de bases de datos (MongoDB, ClickHouse, Elasticsearch).

Cada política de escritura ofrece los mismos cuatro modos:

Los espacios de trabajo nuevos usan de forma predeterminada Preguntar antes de escribir en todos los servicios que admiten una política (mediante la plantilla de preferencias). Los espacios de trabajo creados antes de que existieran las Salvaguardas — o los perfiles cuyo JSON omite el campo — se decodifican como Desactivado.

Nota: La política de escritura es por servicio, no por credencial. Dos credenciales para el mismo servicio — por ejemplo, dos tokens de GitHub — comparten una sola política, de modo que cambiar el selector en cualquiera de las filas lo cambia para ambas.

Nota: Las salvaguardas clasifican las operaciones; no ocultan las credenciales. La credencial en sí sigue siendo inyectada e intercambiada por el proxy tal como se configura en Credenciales. Combina una política de escritura Solo lectura con la casilla Preguntar antes de usar de la misma fila para obtener defensa en profundidad.

Cómo clasifica cada servicio las llamadas

Los endpoints de bases de datos se clasifican por motor:

Aparece una advertencia naranja en línea cuando se establece una política pero no hay nada a lo que aplicarla — no hay kubeconfigs para un contexto de Kubernetes, no hay anfitrión definido para un endpoint de base de datos — ya que entonces la salvaguarda no tiene anfitriones a los que aplicarse.

Nota: Para ClickHouse, si no hay texto SQL visible en la petición, Solo lectura bloquea la petición (Bromure no puede demostrar que sea una lectura) mientras que Bloquear destructivas la deja pasar (falla en modo abierto).

El diálogo de consentimiento (Preguntar antes de escribir)

En el modo Preguntar antes de escribir, las lecturas pasan en silencio y cada escritura se detiene para mostrar un diálogo del anfitrión titulado Allow write on "<scope>" from workspace "<name>"?. El cuerpo del diálogo muestra la operación exacta de forma literal — la sentencia SQL literal para una base de datos, o METHOD /path para una llamada REST — de modo que apruebas lo que realmente se ejecutará, no un resumen. Los botones son:

• Permitir durante 15 minutos (el botón predeterminado)
• Permitir una vez — deliberadamente no crea ninguna concesión, de modo que la siguiente escritura vuelve a solicitar confirmación. Útil para auditar escritura por escritura a un agente parlanchín.
• Permitir durante el resto de la sesión
• No permitir — el agente recibe el mismo error grave que producen los modos de bloqueo. El rechazo se recuerda durante 60 segundos, de modo que un agente que reintenta la misma escritura en bucle no vuelve a solicitar confirmación cada segundo.

Las concesiones se limitan por espacio de trabajo y por alcance de protocolo: un anfitrión de la API de Kubernetes, AWS en su conjunto, un registro de contenedores, cada forja de git en su conjunto o un anfitrión de base de datos. Permitir escrituras de ClickHouse en un anfitrión no concede nada en ningún otro lugar. Las escrituras idénticas concurrentes se fusionan en un solo diálogo, y todas las decisiones existen solo en memoria — las concesiones limitadas a la sesión se borran al desmontar la sesión.

Cuando el espacio de trabajo se controla sin interfaz gráfica a través de SSH o la CLI, se ofrecen las mismas cuatro opciones como un prompt de texto dentro del tmux del espacio de trabajo; la ausencia de respuesta significa denegar.

Nota: Las concesiones de escritura de las Salvaguardas no aparecen en ninguna ventana. La ventana Aprobaciones de credenciales (menú Ventana → Aprobaciones de credenciales…) muestra únicamente las decisiones de consentimiento de credenciales — las concesiones de Preguntar antes de usar; una concesión de política de escritura caduca según su propio reloj o al desmontar la sesión.

Qué ve el agente cuando se bloquea una llamada

Las llamadas bloqueadas devuelven un cuerpo de error de estilo 403 apropiado para el protocolo — un JSON de Status de Kubernetes, un AccessDeniedException de AWS, una carga DENIED de registro — cuyo mensaje termina con "blocked by Bromure Guardrails". El agente ve un fallo de API limpio y corriente que puede informar, en lugar de una conexión colgada. (Los bloqueos de la cadena de suministro usan HTTP 451 en su lugar, precisamente para que ambos se distingan de un vistazo — ver Cadena de suministro.)

Limitaciones

• El push forzado de Git no puede distinguirse de un push normal en la red, por lo que Bloquear destructivas no lo bloquea — solo Solo lectura y Preguntar antes de escribir controlan los pushes. Las eliminaciones explícitas a través de las API REST de la forja se siguen detectando.
• Las políticas de Kubernetes y de registros de contenedores solo se aplican a los anfitriones derivados de los kubeconfigs y los registros configurados del espacio de trabajo; las políticas de bases de datos necesitan que el anfitrión del endpoint esté definido en Credenciales. Una salvaguarda que no tiene nada a lo que aplicarse no filtra nada (el panel te lo advierte en línea).
• Las Salvaguardas cubren los servicios enumerados arriba. El tráfico HTTPS arbitrario hacia otros anfitriones no se clasifica — para las descargas de paquetes ver Cadena de suministro, y para el tráfico de IA del agente ver Inyección de prompts.