> 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-sandbox/understanding-bluerock-sandbox-policies.md).

# Understanding BlueRock Sandbox Policies

The BlueRock Sandbox operates based on a structured JSON policy file. This configuration file acts as the central source of truth for the sandbox environment, dictating exactly what applications can execute, how file systems are mounted, what privileges are granted, and how network traffic is routed.

The policy template file resides at `/opt/bluerock/trex` with filename `bru_policy.json.template`. Rename or copy it with filename `bru_policy.json` and make the relevant changes.

#### Policy Structure Overview

A standard sandbox policy is divided into three primary blocks:

1. [`options`](#runtime-options-options): Defines runtime environments, user privileges, and namespace isolation.
2. [`network`](#network-configuration-network): Governs internal routing and firewall configurations.

Below is a reference template of a foundational policy configuration:

{% code title="bru\_policy.json" overflow="wrap" lineNumbers="true" %}

```json
"brace": {
                "options": {
                    "bind_mount": {
                        "mount_proc": true,
                        "mounts": []
                    },
                    "pid_ns": true,
                    "user_ns": false
                },
                "network": {
                    "enable": false,
                    "general": {
                        "bridge": "bru0",
                        "gateway": "10.0.0.1"
                    },
                    "firewall": null
                },
}
```

{% endcode %}

#### Runtime Options (`options`)

The `options` block manages system-level isolation, file system access, and user privileges.

| **Parameter**           | **Type** | **Description**                                                                                                                                                                             |
| ----------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `bind_mount.mount_proc` | Boolean  | Procfs Mount Control: Automatically mounts a separate, isolated `/proc` filesystem inside the sandbox container for process status tracing. *(Defaults to `true`)*.                         |
| `bind_mount.mounts`     | Array    | Host Volume Mappings: An array defining directories or files mapped from the host filesystem into the sandbox. *(Empty `[]` in this profile)*.                                              |
| `pid_ns`                | Boolean  | PID Namespace Isolation: Restricts process visibility. When enabled, processes running inside the sandbox cannot see or interact with processes on the host system. *(Defaults to `true`)*. |
| `user_ns`               | Boolean  | User Namespace Mapping: Determines if root operations are mapped to an unprivileged host user. *(Defaults to `false`)*.                                                                     |

#### Network Configuration (`network`)

The `network` block defines how the sandbox interacts with internal and external networks.

| **Parameter**     | **Type**      | **Description**                                                                                                                                                                               |
| ----------------- | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `enable`          | Boolean       | Network Sandbox Enforcement: When disabled, the network namespace isolation layer is bypassed, blocking or overriding dynamic interface generation for the instance. *(Defaults to `false`)*. |
| `general.bridge`  | String        | Virtual Bridge Interface: The designated virtual network bridge identifier used for container network binding when networking is active. *(Defaults to `"bru0"`)*.                            |
| `general.gateway` | String        | Default Gateway: The IPv4 target destination routing address for network packets escaping the sandbox interface. *(Defaults to `"10.0.0.1"`)*.                                                |
| `firewall`        | Null / Object | Firewall Access Control List: Granular firewall filters, iptables, or routing rules applied to this specific profile. *(Defaults to `null`)*.                                                 |

### Policy-Driven Configuration Examples

Centralizing security logic within the policy file reduces manual input errors and ensures consistent enforcement across environments.

#### Running Python MCP Server and MCP Client

To run Python MCP Server and MCP Client in BlueRock Sandbox, an MCP setup is required:

1\. Install `uv` :

```shellscript
$ curl -LsSf https://astral.sh/uv/install.sh | sh
```

2\. Create Project Directory \
Create a new project directory for the MCP applications and navigate into it:

```shellscript
$ cd ~
$ uv init mcp-observability
$ cd mcp-observability
```

3\. Install Required Dependencies \
Create an isolated Python environment using `uv`, then install the MCP framework, BlueRock sensor, and BlueRock runtime required for generating and exporting telemetry:

```shellscript
# Create virtual environment
$ uv venv --python python3.12

# Activate virtual environment
$ source .venv/bin/activate

# Install MCP framework
$ uv pip install fastmcp

# Install BlueRock runtime
$ uv pip install /opt/bluerock/python-dist/bluerock-0.0.1-py3-none-any.whl

# Initialize BlueRock sensor
$ python -m bluerock --install
```

4\. Add MCP Application Files \
Create the MCP client and server scripts in the project directory using the sample code provided in the [Appendix section](/glossary/appendix.md). Ensure the following files are present in the `mcp-observability` directory:

* [`mcp_client.py`](/glossary/appendix.md#mcp-client-script-python)
* [`mcp_fileserver.py`](/glossary/appendix.md#mcp-file-server-http-python)
* [`mcp_fileserver_stdio.py`](/glossary/appendix.md#mcp-file-server-stdio-python)

**Defining Mounts to run the MCP Server and Client**

Defining mount points directly within the `bru_policy.json` file under the `options.bind_mount` block eliminates the requirement for extensive `-v` arguments in the Command Line Interface (CLI).

{% code title="bru\_policy.json" overflow="wrap" lineNumbers="true" %}

```json
{
  "brace": {
    "options": {
      "bind_mount": {
        "enable": true,
        "mounts": [
          {"host": "/usr", "sandbox": "/usr", "read_only": true},
          {"host": "/lib", "sandbox": "/lib", "read_only": true},
          {"host": "/lib64", "sandbox": "/lib64", "read_only": true},
          {"host": "/etc/resolv.conf", "sandbox": "/etc/resolv.conf", "read_only": true},
          {"host": "/dev", "sandbox": "/dev", "read_only": false},
          {"host": "/home/ubuntu", "sandbox": "/home/ubuntu", "read_only": false}
        ]
      }
    }
  }
}
```

{% endcode %}

{% hint style="success" icon="lightbulb-exclamation-on" %}
**Important:**&#x20;

Modifications to `bru_policy.json` require a complete policy update to take effect. This process involves extracting the tarball, generating a new signature via `trex.py`, and uploading the repackaged files. Refer to the [BlueRock Policy Builder](/policy-configuration/policy-builder.md#step-1-create-signing-key-and-certificate) for detailed instructions.
{% endhint %}

With file mounts pre-configured in the policy, the system allows for the direct execution of the MCP client or server without additional volume flags.

**Terminal 1:**&#x20;

Starting the MCP Server Launch the sandbox and execute the Python server script:

{% code overflow="wrap" %}

```shellscript
$ brace --name mcp_server -- /home/ubuntu/.local/bin/uv run mcp_fileserver.py
```

{% endcode %}

Expected Output:

```shellscript
╭──────────────────────────────────────────────────────────────────────────────╮
│                                                                              │
│                                                                              │
│                         ▄▀▀ ▄▀█ █▀▀ ▀█▀ █▀▄▀█ █▀▀ █▀█                        │
│                         █▀  █▀█ ▄▄█  █  █ ▀ █ █▄▄ █▀▀                        │
│                                                                              │
│                                                                              │
│                                FastMCP 3.1.0                                 │
│                            https://gofastmcp.com                             │
│                                                                              │
│                   🖥  Server:      Linux File Server, 3.1.0                   │
│                   🚀 Deploy free: https://fastmcp.cloud                      │
│                                                                              │
╰──────────────────────────────────────────────────────────────────────────────╯
[03/12/26 04:42:11] INFO     Starting MCP server 'Linux File    transport.py:273
                             Server' with transport 'http' on                   
                             http://0.0.0.0:8001/mcp                            
INFO:     Started server process [9]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://0.0.0.0:8001 (Press CTRL+C to quit)
```

**Terminal 2:**&#x20;

Starting the MCP Client. Open a separate terminal and launch a second sandbox to execute the client script:

{% code overflow="wrap" %}

```shellscript
$ brace --name mcp_client -- /home/ubuntu/.local/bin/uv run mcp_client.py --mcp_server http://0.0.0.0:8001/mcp --mcp_auth_token dev-test-token tools --list
```

{% endcode %}

### **Network Firewall Configuration**

Network profile defines how a program running inside the sandbox connects to external network services.

{% hint style="info" icon="notes-sticky" %}
Only one network firewall can be configured for the Sandbox policy.
{% endhint %}

* **Egress (*****Outbound*****)**: Allows programs in the sandbox to reach external network services.

  Parameters -  IP, port, protocol

  *For example*: An agent program running inside the sandbox is restricted to access a specific LLM provider.
* **Ingress (*****Inbound*****)**: Allows inbound connections from a specific host to the server program running inside the sandbox on a specific port and protocol

  *For example:* Allows an MCP client  program from a specific source address  to connect to the MCP server program running on a specific port

{% code title="bru\_policy.json" lineNumbers="true" %}

```json
"network": {
                "enable": true,
                "general": {
                        "bridge": "bru0",
                        "gateway": "10.0.0.1"
                    },
                    "firewall": {"options": {"allow_icmp": true, "log_drops": true},
                                 "ingress": {"published_ports": [{"container_port":8001, "host_bindings": [{"host_ip": "0.0.0.0", "host_port": 8001}]}]},
                                 "egress": {"allow_to": [{"addr": "8.8.8.8", "ports": [], "proto": ["tcp", "udp"]},
                                                         {"addr": "api.openai.com", "ports": [], "proto": ["tcp", "udp"]},
                                                         {"addr": "api.<domain>.com", "ports": [], "proto": ["tcp", "udp"]}]}}
}
```

{% endcode %}

| **Parameter**                              | **Type**          | **Description**                                                                                                                                            |
| ------------------------------------------ | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `network.enable`                           | Boolean           | Master toggle to enable (`true`) or disable (`false`) the network configuration.                                                                           |
| `network.general.bridge`                   | String            | The name of the virtual bridge interface designated for this network (e.g., `bru0`).                                                                       |
| `network.general.gateway`                  | String            | The IPv4 address assigned as the network gateway (e.g., `10.0.0.1`).                                                                                       |
| `network.firewall.options.allow_icmp`      | Boolean           | Determines whether ICMP traffic (such as ping requests) is permitted through the firewall.                                                                 |
| `network.firewall.options.log_drops`       | Boolean           | When enabled, logs all network packets that are dropped by the firewall rules.                                                                             |
| `network.firewall.ingress.published_ports` | Array of Objects  | A list of port mapping definitions for inbound traffic to the container.                                                                                   |
| `...published_ports[].container_port`      | Integer           | The specific port number inside the container that will receive the routed traffic.                                                                        |
| `...published_ports[].host_bindings`       | Array of Objects  | Specifies how the internal `container_port` maps to the host's external network interfaces.                                                                |
| `...host_bindings[].host_ip`               | String            | The host IP address to bind the port to. Use `0.0.0.0` to bind to all available IPv4 interfaces.                                                           |
| `...host_bindings[].host_port`             | Integer           | The external port number exposed on the host machine.                                                                                                      |
| `network.firewall.egress.allow_to`         | Array of Objects  | A list of strict outbound rules defining permitted external destinations for container traffic.                                                            |
| `...allow_to[].addr`                       | String            | The destination IPv4 address (e.g., `8.8.8.8`) or Fully Qualified Domain Name (FQDN) (e.g., `api.openai.com`) permitted for egress.                        |
| `...allow_to[].ports`                      | Array of Integers | An array of specific destination ports allowed for the defined address. An empty array typically implies no port restrictions for the specified protocols. |
| `...allow_to[].proto`                      | Array of Strings  | The network protocols permitted for this egress rule (e.g., `["tcp", "udp"]`).                                                                             |

{% hint style="success" icon="lightbulb-exclamation-on" %}
**Important:**&#x20;

Modifications to `bru_policy.json` require a complete policy update to take effect. This process involves extracting the tarball, generating a new signature using `trex.py`, and uploading the repackaged files. Refer to the [BlueRock Policy Builder](/policy-configuration/policy-builder.md#step-1-create-signing-key-and-certificate) for detailed instructions.
{% endhint %}

### Seccomp Interception Rules & Monitor Constraints

When `syscalls.enable = true` is set in your configuration profile, the engine actively injects custom seccomp filters into the container sandbox initialization routine using `SCMP_ACT_NOTIFY` vectors. The parent engine runs an isolated asynchronous loop that monitors matching system hooks, intercepts process namespaces, reads the context block, and emits the structured telemetry.

**Policy Reference Configurations**

Use these minimal structures to enforce active tracking for audited domains:

**Suspicious Syscalls Tracker (**`suspicious_syscalls`**)**\
Intercepts unauthorized privilege escalation or host namespace jailbreak vectors.

```json
"suspicious_syscalls": {
  "enable": true,
  "remediate": false,
  "allow_unshare": false,
  "allow_ptrace": false
}
```

| **Parameter**                       | **Type** | **Description**                                                                                                                                                    |
| ----------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `suspicious_syscalls.enable`        | Boolean  | Master toggle to enable (`true`) or disable (`false`) the monitoring and evaluation of suspicious system calls.                                                    |
| `suspicious_syscalls.remediate`     | Boolean  | Determines whether the system should take automatic enforcement action (such as blocking or terminating the process) when a suspicious syscall is detected.        |
| `suspicious_syscalls.allow_unshare` | Boolean  | Controls whether the `unshare` system call is permitted. When disabled, it prevents processes from detaching namespaces (often restricted for security isolation). |
| `suspicious_syscalls.allow_ptrace`  | Boolean  | Controls whether the `ptrace` system call is permitted. When disabled, it prevents unauthorized process tracing, debugging, or memory inspection.                  |

**Process Execution (**`execve` or `execveat`**)**

Generates telemetry indicators whenever `execve` or `execveat` are handled inside the container.

```json
"exec": {
  "enable": true,
  "track_clone": false
}
```

| **Parameter**      | **Type** | **Description**                                                                                                                      |
| ------------------ | -------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| `exec.enable`      | Boolean  | Master toggle to enable (`true`) or disable (`false`) execution monitoring and related policies.                                     |
| `exec.track_clone` | Boolean  | Controls whether the system tracks process creation events (such as `clone` or `fork` system calls) as part of the execution policy. |

**Filesystem Interface Tracker (**`allow_read_only`**)**

Tracks namespace interactions. Toggling `"allow_read_only": true` reduces metric noise by omitting read operations.

```json
"open": {
  "enable": true,
  "remediate": false,
  "allow_read_only": true
}
```

| **Parameter**          | **Type** | **Description**                                                                                                                                                                         |
| ---------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `open.enable`          | Boolean  | Master toggle to enable (`true`) or disable (`false`) monitoring and policy evaluation for file open operations.                                                                        |
| `open.remediate`       | Boolean  | Determines whether the system should take automatic enforcement action (such as blocking the operation) when an unauthorized file open request is detected.                             |
| `open.allow_read_only` | Boolean  | Controls whether read-only file access is permitted by default. When enabled, it allows processes to open files strictly for reading, even if broader access restrictions are in place. |

**Staging Memory Execution Tracker (`mmap_exec`)**\
Tracks fileless execution strategies and dynamic memory allocations inside the container sandbox space.

```json
"mmap_exec": {
  "enable": true,
  "remediate": false
}
```

| **Parameter**         | **Type** | **Description**                                                                                                                                                           |
| --------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `mmap_exec.enable`    | Boolean  | Master toggle to enable (`true`) or disable (`false`) the monitoring and policy evaluation of memory regions mapped with execution permissions (e.g., `PROT_EXEC`).       |
| `mmap_exec.remediate` | Boolean  | Determines whether the system should take automatic enforcement action (such as blocking the mapping request) when an unauthorized executable memory mapping is detected. |

1. **Operational Impact:** \
   Generates a `brace_mmap_exec` telemetry signature whenever a process requests an `mmap` allocation flagged with `PROT_EXEC` modifications, or attempts to `execve` target an anonymous memory descriptor (`/memfd:`).
2. **Enforcement Behavior:** \
   Structural prevention blocks are unique to high-risk traps. If a fileless execution mechanism violates the staging policy, remediation flags can be enabled to block the memory allocation lifecycle.

**Network Socket Tracking Interface (`socket`)**\
Captures raw endpoint instantiation handles at the container namespace boundary.

```json
"socket": {
  "enable": true,
  "remediate": false
}
```

| **Parameter**      | **Type** | **Description**                                                                                                                                          |
| ------------------ | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `socket.enable`    | Boolean  | Master toggle to enable (`true`) or disable (`false`) monitoring and policy evaluation for network socket creation and operations.                       |
| `socket.remediate` | Boolean  | Determines whether the system should take automatic enforcement action (such as blocking the operation) when an unauthorized socket request is detected. |

1. **Operational Impact:** \
   Dispatches a `brace_socket` data block immediately when the `socket()` system call is processed inside the sandbox.
2. **Observe-Only Baseline:** \
   This hook functions in an observe-only validation scope. The configuration captures the underlying protocol arrays (such as `AF_INET` or `SOCK_STREAM`) for audit baselines without introducing runtime structural latency.

**Network Connection Tracker (`connect`)**\
Monitors bi-directional outbound connectivity and tracking state handshakes.

```json
"connect": {
  "enable": true,
  "remediate": false
}
```

| **Parameter**       | **Type** | **Description**                                                                                                                                                       |
| ------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `connect.enable`    | Boolean  | Master toggle to enable (`true`) or disable (`false`) monitoring and policy evaluation for outbound network connection attempts (e.g., the `connect` system call).    |
| `connect.remediate` | Boolean  | Determines whether the system should take automatic enforcement action (such as blocking the connection attempt) when an unauthorized network connection is detected. |

1. **Operational Impact:** \
   Evaluates the container's raw process memory directly on a `connect()` execution request. The interface translates destination headers into human-readable IP or Unix socket address strings (such as `1.2.3.4:port` or `unix:/path/to/sock`) inside the `brace_connect` log output.
2. **Observe-Only Baseline:** \
   Operates under an observe-only posture. This hook does not drop traffic directly; enforcement is entirely delegated to host-level egress network firewall rules to minimize path friction.

**Filesystem Deletion Tracker (`delete`)**\
Maintains an accurate audit trail of structural file and directory purging actions.

```json
"delete": {
  "enable": true
}
```

| **Parameter**   | **Type** | **Description**                                                                                                                                                           |
| --------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `delete.enable` | Boolean  | Master toggle to enable (`true`) or disable (`false`) monitoring and policy evaluation for file or resource deletion operations (e.g., `unlink` or `rmdir` system calls). |

1. **Operational Impact:** \
   Triggers a `brace_delete` tracking log upon any valid call to `unlink`, `unlinkat`, or `rmdir` system commands.
2. **Metadata Structure:** \
   Emits absolute resolved paths along with a boolean `is_dir` flag to distinguish regular file drops from full directory removals within the security metrics stream. This trap is always permitted through for observation.

### Sensitive File Access (`sensitive_file_access`)

Monitors real-time interactions with critical system configurations, credential storage locations, and environmental identity blocks.

```json
"sensitive_file_access": {
  "enable": true,
  "remediate": false,
  "paths": [
    { "path": "/etc/shadow", "write_only": false },
    { "path": "/etc/sudoers", "write_only": false },
    { "path": "/etc/passwd", "write_only": true }
  ],
  "exceptions": [
    { "program": "/usr/sbin/sshd", "file": "**/*" }
  ]
}
```

| **Parameter**                      | **Type**         | **Description**                                                                                                                                                                                           |
| ---------------------------------- | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `sensitive_file_access.enable`     | Boolean          | Master toggle to enable (`true`) or disable (`false`) monitoring and policy evaluation for interactions with designated sensitive files.                                                                  |
| `sensitive_file_access.remediate`  | Boolean          | Determines whether the system should take automatic enforcement action (such as blocking the access attempt) when an unauthorized interaction with a sensitive file is detected.                          |
| `sensitive_file_access.paths`      | Array of Objects | A list of specific file paths designated as sensitive, along with their access evaluation criteria.                                                                                                       |
| `...paths[].path`                  | String           | The absolute directory or file path to be monitored (e.g., `/etc/shadow`).                                                                                                                                |
| `...paths[].write_only`            | Boolean          | Controls the scope of monitoring for the specific path. When `true`, alerts or remediation only trigger upon modification (write) attempts. When `false`, any access (read or write) triggers the policy. |
| `sensitive_file_access.exceptions` | Array of Objects | A list of rules defining trusted processes permitted to bypass the sensitive file access restrictions.                                                                                                    |
| `...exceptions[].program`          | String           | The absolute path to the executable program authorized for the exception (e.g., `/usr/sbin/sshd`).                                                                                                        |
| `...exceptions[].file`             | String           | The specific file path or glob pattern (e.g., `**/*`) that the authorized program is permitted to access without triggering a violation.                                                                  |

1. **Operational Impact:** \
   Evaluates standard file open requests against a predefined file-path array to detect unauthorized access to system configurations, tracking operations through the `sensitive_file_access_violation` observability signature.
2. **Granular Read/Write Mechanics:** \
   Adjusts alert tracking structures by matching paths with a declarative boolean flag. Setting `write_only: false` enables bi-directional audit logging to catch both read actions (such as a `cat` command) and write modifications on target paths. Setting `write_only: true` suppresses read notifications to isolate alerts strictly to modification attempts on asset stores (such as user group files or network resolution configurations).
3. **Automated Exceptions Mapping:** \
   Processes fine-grained exemptions to eliminate false positive noise from validated system utilities. Whitelisted operations (such as authentication lookups from the `sshd` daemon or privilege changes via `sudo`) bypass violation filters, matching entries without dispatching security logging events.

### Process Guard (`process_guard`)

Manages binary execution parameters inside the container space to prevent post-exploit tool execution and remote script injections.

```shellscript
"process_guard": {
  "enable": true,
  "remediate": false,
  "allow": [
    "/bin/**",
    "/usr/bin/**"
  ],
  "deny": [
    "**/nc",
    "**/wget",
    "**/curl"
  ],
  "deny_exceptions": [
    { "path_pattern": "**/bin/bash", "comm_list": ["setup-policy-ro"] }
  ]
}
```

| **Parameter**                       | **Type**         | **Description**                                                                                                                                                                |
| ----------------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `process_guard.enable`              | Boolean          | Master toggle to enable (`true`) or disable (`false`) monitoring and policy evaluation for process execution based on allow/deny lists.                                        |
| `process_guard.remediate`           | Boolean          | Determines whether the system should take automatic enforcement action (such as blocking the process creation) when an unauthorized process execution is detected.             |
| `process_guard.allow`               | Array of Strings | A list of explicit file paths or glob patterns (e.g., `/bin/**`) designating executables that are permitted to run.                                                            |
| `process_guard.deny`                | Array of Strings | A list of explicit file paths or glob patterns (e.g., `**/wget`) designating executables that are strictly prohibited from running.                                            |
| `process_guard.deny_exceptions`     | Array of Objects | A list of granular rules defining specific exceptions to the broader deny list.                                                                                                |
| `...deny_exceptions[].path_pattern` | String           | The path or glob pattern of the executable (e.g., `**/bin/bash`) that is granted an exception under specific conditions.                                                       |
| `...deny_exceptions[].comm_list`    | Array of Strings | A list of permitted command names (typically mapped to the Linux `comm` value) that are authorized to execute the file matched by the `path_pattern`, bypassing the deny rule. |

1. **Operational Impact:** \
   Validates process execution calls (`execve`, `execveat`) against declarative directories, triggering an automated `process_guard_violation` event whenever a disallowed binary or unlisted path structure matches active block restrictions.
2. **Intrusion Isolation Blocklists:** \
   Enforces a persistent deny matrix to target binaries frequently abused during payload deployment stages. Execution attempts matching ingestion or scripting tools (such as `curl`, `wget`, or Netcat) are systematically blocked and reported to telemetry pools.
3. **Contextual Deny Overrides:** \
   Evaluates targeted exceptions based on explicit execution contexts to permit safe administration actions. Regulated binaries (such as a standard `bash` shell) are permitted to run only if the execution sequence maps directly to a trusted system initialization wrapper (such as `setup-policy-ro`).


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.bluerock.io/bluerock-sandbox/understanding-bluerock-sandbox-policies.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.
