> For the complete documentation index, see [llms.txt](https://docs.bluerock.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bluerock.io/bluerock-documentation-2.7.0-beta/release-notes/bluerock-2.7.0-26.38.0.md).
# BlueRock 2.7.0 (26.38.0)
### Purpose of this Document
This document provides information about the features, enhancements, and known issues in BlueRock Release 2.7.0 (26.38.0). It applies to both new deployments and upgrades from earlier versions.
This release introduces robust Policy Enhancements, including human-in-the-loop approval and the BlueWarden egress security proxy; expanded BlueRock Connector capabilities, such as remote file share mounting; and secure Okta SSO integration via the BlueDev Identity Deployment Kit.
***
### Revision History
| **Release Version** | **Release Date** |
| ------------------- | ---------------- |
| v2.7.0 (26.38.0) | |
***
## Supported Platforms / Distributions
BlueRock Release v2.7.0 (26.38.0) supports deployment across major public cloud providers.
The following operating systems have been validated for this release.
### AWS
| **Distribution** | **Kernel** |
| ----------------- | ---------- |
| Amazon Linux 2023 | 6.12.112 |
### GCP
| **Distribution** | **Kernel** |
| ---------------- | ---------- |
| Ubuntu 24.04 | 6.12.112 |
### Azure
| **Distribution** | **Kernel** |
| ---------------- | ---------- |
| Ubuntu 24.04 | 6.12.112 |
***
## New Features and Enhancements
This release introduces robust Policy Enhancements including human-in-the-loop approval and the BlueWarden egress security proxy, expanded BlueRock Connector capabilities such as remote file share mounting, and secure Okta SSO integration via the BlueRock Identity Kit.
### Policy Enhancements
#### Human in the Loop Approval
In this release, BlueRock provides policy rules that gate coding agents (Claude Code, Cursor, Codex, Antigravity). These rules require human approval before executing specific tools or commands, rather than relying solely on simple logging or blocking remediations. When a command or tool execution matches a configured policy, BlueRock presents the agent's permission prompt to the operator, and the pending tool call waits for an answer. This feature is supported only for coding agents running inside the BlueRock Sandbox container.
```json
{
"version": "26.38_bru-release-26-38-0",
"app_policies": {
"default": {
"claude_sensor": {
"tool_guard": {
"enable": true,
"remediate": "approval",
"denied": [ "WebFetch" ]
},
"command_guard": {
"enable": true,
"remediate": "approval",
"patterns": [ "git push -f", "git push --force" ]
}
}
}
}
}
```
\
**Limitations**
* **Codex:** \
Codex does not enforce the approval block; the agent logs the prompt but allows the execution of the action.
* **Cursor:** \
Cursor enforces the approval block on a best-effort basis. The agent only accepts an approval request for `beforeShellExecution` and `beforeMCPExecution`, and its upstream handling of these requests remains unreliable as of version 2.6.19.
* **Out-of-path execution:** \
When the BlueRock Host cannot show the approval prompt due to an action happening outside the inspection path, the server logs the action, and the BlueRock Host/VM allows the execution to proceed.
{% hint style="success" icon="lightbulb-exclamation-on" %}
**Important:** \
Configure a `remediate: true` policy on the BlueRock Server to strictly block an action happening outside the inspection path.
{% endhint %}
#### Per User Policy
Administrators can configure runtime Sandbox policies and apply the policies directly to the BlueRock Sandbox created and accessed by specific user principals. The system authenticates these user principals via Google, Entra, Okta Single Sign-On (SSO), or SSH key authentication.
#### Sandbox Policies
In this release, BlueRock introduces granular observability configurations, enabling the following controls:
* Emit observability events for all file operations, or restrict the events strictly to file write operations to avoid event flooding.
* Observe specific file deletion operations inside the sandbox container.
* Restrict coding agent execution strictly to explicit file paths.
* Limit `io_uring` usage inside the sandbox.
{% hint style="info" icon="notes" %}
**Note:**
BlueRock denies any system call failing policy evaluation by default.
{% endhint %}
#### BlueWarden (Egress Security)
BlueWarden operates as an optional, per-container egress HTTPS proxy for coding agents running inside the BlueRock Sandbox container. The proxy transparently intercepts outbound requests from coding agents and applies configured policies on each request before the traffic leaves the BlueRock Host/VM.
**Enablement and Configuration:**
Administrators enable and configure BlueWarden by defining the `warden` block within the Sandbox application policy. A minimal structural example is provided below:
```json
{
"warden": {
"options": {
"remediate": false,
"fail_closed": false
},
"egress": {
"block_quic": true,
"destinations": {
"allow_to": [],
"deny_to": []
}
}
// Additional configurations for tls, http, dns, llm, and mcp are defined here.
}
}
```
Supported egress policies include:
* **HTTP/HTTPS Endpoint Filtering:** \
Controls which upstream hosts and URL paths the agent's requests allow.
* **Model Pinning:** \
Governs which LLM IDs the agent may call.
* **MCP Filtering:** \
Inspects the agent's MCP JSON-RPC traffic, including tool-call and prompt arguments, as well as tool and prompt descriptions and responses.
* **DNS Control:** \
Inspects DNS lookups and responses, governing DNS-over-HTTPS and DNS-over-TLS.
* **LLM Response Observation:** \
Decodes the model's reply stream to emit telemetry regarding responses and tool-call intent.
* **L4 Egress Control:** \
Denies all non-web TCP and UDP traffic by default unless explicitly allowed by destination IP and port. BlueWarden automatically drops QUIC connections to force clients to fall back to inspectable TCP.
* **Anti-SSRF Invariants:** \
Re-resolves the request Host and inherently denies connections to private and cloud-metadata addresses. BlueRock strictly enforces the metadata address range and never relaxes the range.
#### Bouncer Policy
The Bouncer policy allows administrators to govern the specific bouncer operations users can perform on remote development workspaces (such as creating, starting, or destroying environments). The policy also enforces caps on the maximum number of remote sandbox containers a single user principal can create.
The policy requires two configurations:
* **`bouncer_contract`:** \
A named contract defining policy options.
* **`bouncer_contract_mapping`:** \
A mapping of the bouncer contract to a user principal ID.
```json
{
"bouncer_contracts": {
"default": {
"capabilities": { "destroy": { "enabled": false } },
"limits": { "max_containers_per_principal": 3 }
},
"admin": {
"limits": { "max_containers_per_principal": 0 }
},
"attach-only": {
"capabilities": {
"up": { "enabled": false },
"start": { "enabled": false },
"stop": { "enabled": false },
"destroy": { "enabled": false },
"rename": { "enabled": false }
}
},
"catalog-only": {
"capabilities": { "up": { "url_source": false, "shares": false } }
}
},
"bouncer_contract_mapping": {
"rules": [
{ "principal": "admin.mail@domain.com", "contract": "admin" },
{ "principal": "*@contractor.domain.com", "contract": "attach-only" },
{ "principal": "key:SHA256:*", "contract": "catalog-only" }
],
"default": "default"
}
}
```
| **User** | **Contract** | **Effect** |
| ------------------------------------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------ |
| | admin | Every action is allowed, and there is no container limit. |
| Anyone at contractor.domain.com | attach-only | Can attach to existing containers but cannot create, start, stop, destroy, or rename them. The limit is 5 (the default). |
| Any user authenticated with a plain SSH key | catalog-only | The `up` command works only from catalog templates; no git URLs or remote shares are permitted. |
| Everyone else | default | Cannot destroy containers, and the limit is a maximum of 3 containers. |
***
### BlueRock Connector
#### Sandbox Idle Timeout Control
The BlueRock Connector extension/application introduces configurable options on the client side to maintain the running state of the remote sandbox container on the BlueRock Host/VM, or automatically stop the container after a disconnection.
The extension includes an Autostop configuration section with the following controls:
* Keep running (never autostop): Keeps the sandbox running on the BlueRock Host/VM after the client side disconnects. The user must stop the container manually.
* Grace after normal disconnection (minutes): Configures the waiting period after the client side editor closes.
* Grace after dropped connection (minutes): Configures the waiting period after a client side connection drops unexpectedly.
#### **Mount Remote File Share**
The BlueRock Connector extension/application supports mounting external file storage directly onto the BlueRock Sandbox container running on the BlueRock Host/VM. Supported external file storage includes:
* AWS EFS and AWS FSx
* Azure Files
#### Port Forwarding
The BlueRock Connector extension/application securely exposes server applications running inside the remote BlueRock Sandbox directly to the local client-side desktop browser. This functionality allows developers to access remote applications running on the BlueRock Host/VM seamlessly from the local client-side environment.
***
### BlueDev Identity Deployment Kit
#### **Okta SSO Support**
The Identity Kit integrates with Okta OpenID Connect (OIDC) applications to permit secure remote workspace logins. This integration allows users to seamlessly authenticate and access the remote BlueRock Sandbox using their Okta account ID.
#### Auto-Renewal of Host Certificate
For the BlueDev container deployment using SSO, the BlueRock Host receives a host certificate with a fixed lifetime at the time of host enrollment with StepCA. BlueRock automatically renews these host certificates to prevent service disruption, eliminating the need for manual administrative intervention to maintain host connectivity.
***
## Fixed Issues
### BA-2927 SSH connection failure on macOS Monterey
SSH connections to BlueRock hosts using the Bluedev VSCode Extension or the Cobalt application may fail on **macOS Monterey** because of domain socket path length limitations.
***
## Known Issues
### BC-3432: Unexpected brace\_connect events when Warden is disabled on the host
When Warden is disabled on the host (in `/etc/bluedev/bouncer.toml`), but any Warden policy rules (`warden.http.endpoint`, `warden.llm`, or `warden.mcp`) remain enabled in the TREX policy, `brace_connect` events are still generated even if `brace.syscalls.connect` is set to `minimal`.
**Workaround**
To stop these unmatched events, explicitly disable `warden.http.endpoint`, `warden.llm`, and `warden.mcp` in your policy. With those disabled, `brace.syscalls.connect=minimal` will behave as expected and suppress the events.
***
### BC-3371 Restarting bluerockd disrupts existing sensor connections
Restarting the BlueRock Control Plane service disconnects existing BlueRock sensor connections, interrclient-sideve AI agent and MCP applications.
**Workaround**
Restart all affected AI agent and MCP applications after restarting the `bluerockd` service.
***
### BC-3381 Source-address ingress firewall rules not enforced
Source-address-based ingress firewall rules are not correctly enforced for BlueRock Sandbox containers.
**Workaround**
No workaround is currently available.
***
### CP-1333 Tooltip overlaps page content and renders outside the visible window
On the Home page, tooltips for alert or trigger data in the Flagged Alerts section expand over the underlying UI and extend beyond the visible viewport when they contain a large amount of data.
**Workaround**
No workaround is currently available.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.bluerock.io/bluerock-documentation-2.7.0-beta/release-notes/bluerock-2.7.0-26.38.0.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.