opensource/coder
3
0
Fork 0
mirror of https://github.com/coder/coder.git synced 2026-09-24 15:04:27 +08:00
Code Issues Packages Projects Releases Wiki Activity

docs: rename AI Bridge to AI Gateway and Agent Boundaries to Agent Firewall (#24094)

Browse Source 
*Disclaimer: implemented by a Coder Agent using Claude Opus 4.6*

## Summary

Renames product references across documentation:

| Old Name | New Name |
|----------|----------|
| AI Bridge | AI Gateway |
| AI Bridge Proxy | AI Gateway Proxy |
| Agent Boundaries | Agent Firewall |

## What changed

- Prose text, headings, titles, and descriptions updated across all docs
- Directories renamed:
  - `docs/ai-coder/ai-bridge/` → `docs/ai-coder/ai-gateway/`
- `docs/ai-coder/ai-bridge/ai-bridge-proxy/` →
`docs/ai-coder/ai-gateway/ai-gateway-proxy/`
  - `docs/ai-coder/agent-boundaries/` → `docs/ai-coder/agent-firewall/`
- All internal markdown links updated to new paths
- `manifest.json` route paths updated
- Rename notice added to AI Gateway and Agent Firewall entrypoint pages

## Companion PR

URL redirects (old paths → new paths):
[coder/coder.com#700](https://github.com/coder/coder.com/pull/700)

## What is intentionally NOT changed

- **Env vars**: `CODER_AIBRIDGE_*`
- **CLI flags**: `--aibridge-*`
- **API paths**: `/api/v2/aibridge/*`
- **Config keys**: `aibridge:` YAML blocks
- **Terraform variables**: `enable_aibridge`, `boundary_version`,
`use_boundary_directly`
- **Process names**: `aibridged`, `aibridgeproxyd`
- **Prometheus metrics**: `coder_aibridged_*`, `coder_aibridgeproxyd_*`
- **SDK types**: `codersdk.AIBridge*`
- **GitHub URLs**: `github.com/coder/aibridge`
- **Image paths**: `images/aibridge/`
- **Auto-generated reference docs**: `docs/reference/cli/aibridge*.md`,
`docs/reference/api/aibridge.md`, `docs/reference/api/schemas.md`
- **Frontend code**: `site/src/` references (separate PR)

Code-level renames (env vars, configs, frontend) are planned for a
follow-up PR.
This commit is contained in:
Danny Kopping
2026-04-09 10:07:50 +00:00
committed by GitHub
parent 2e6fdf2344
commit 7a94a683c4
39 changed files with 340 additions and 330 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/ai-coder/agent-firewall/index.md
+225
View File
@@ -0,0 +1,225 @@
# Agent Firewall
Agent Firewall is a process-level firewall that restricts and audits what
autonomous programs, such as AI agents, can access and use.
![Screenshot of Agent Firewall blocking a process](../../images/guides/ai-agents/boundary.png)Example
of Agent Firewall blocking a process.
> [!NOTE]
> Agent Firewall was previously known as "Agent Boundaries". Some
> configuration options and internal references still use the old name
> and will be updated in a future release.
## Supported Agents
Agent Firewall supports the securing of any terminal-based agent, including
your own custom agents.
## Features
Agent Firewall offers network policy enforcement, which blocks domains and HTTP
verbs to prevent exfiltration, and writes logs to the workspace.
Agent Firewall also streams audit logs to Coder's control plane for centralized
monitoring of HTTP requests.
## Getting Started with Agent Firewall
The easiest way to use Agent Firewall is through existing Coder modules, such
as the
[Claude Code module](https://registry.coder.com/modules/coder/claude-code). It
can also be ran directly in the terminal by installing the
[CLI](https://github.com/coder/boundary).
## Configuration
> [!NOTE]
> For information about version requirements and compatibility, see the [Version Requirements](./version.md) documentation.
Agent Firewall is configured using a `config.yaml` file. This allows you to
maintain allow lists and share detailed policies with teammates.
In your Terraform module, enable Agent Firewall with minimal configuration:
```tf
module "claude-code" {
source = "dev.registry.coder.com/coder/claude-code/coder"
version = "4.7.0"
enable_boundary = true
}
```
Create a `config.yaml` file in your template directory with your policy. For the
Claude Code module, use the following minimal configuration:
```yaml
allowlist:
- "domain=dev.coder.com" # Required - use your Coder deployment domain
- "domain=api.anthropic.com" # Required - API endpoint for Claude
- "domain=statsig.anthropic.com" # Required - Feature flags and analytics
- "domain=claude.ai" # Recommended - WebFetch/WebSearch features
- "domain=*.sentry.io" # Recommended - Error tracking (helps Anthropic fix bugs)
jail_type: nsjail
log_dir: /tmp/boundary_logs
proxy_port: 8087
log_level: warn
```
For a basic recommendation of what to allow for agents, see the
[Anthropic documentation on default allowed domains](https://code.claude.com/docs/en/claude-code-on-the-web#default-allowed-domains).
For a comprehensive example of a production Agent Firewall configuration, see
the
[Coder dogfood policy example](https://github.com/coder/coder/blob/main/dogfood/coder/boundary-config.yaml).
Add a `coder_script` resource to mount the configuration file into the workspace
filesystem:
```tf
resource "coder_script" "boundary_config_setup" {
agent_id = coder_agent.dev.id
display_name = "Boundary Setup Configuration"
run_on_start = true
script = <<-EOF
#!/bin/sh
mkdir -p ~/.config/coder_boundary
echo '${base64encode(file("${path.module}/config.yaml"))}' | base64 -d > ~/.config/coder_boundary/config.yaml
chmod 600 ~/.config/coder_boundary/config.yaml
EOF
}
```
Agent Firewall automatically reads `config.yaml` from
`~/.config/coder_boundary/` when it starts, so everyone who launches Agent
Firewall manually inside the workspace picks up the same configuration without
extra flags. This is especially convenient for managing extensive allow lists in
version control.
### Configuration Parameters
- `allowlist` defines the URLs that the agent can access, in addition to the
default URLs required for the agent to work. Rules use the format
`"key=value [key=value ...]"`:
- `domain=github.com` - allows the domain and all its subdomains
- `domain=*.github.com` - allows only subdomains (the specific domain is
excluded)
- `method=GET,HEAD domain=api.github.com` - allows specific HTTP methods for a
domain
- `method=POST domain=api.example.com path=/users,/posts` - allows specific
methods, domain, and paths
- `path=/api/v1/*,/api/v2/*` - allows specific URL paths
- `jail_type` selects the isolation backend. Valid values: `nsjail` (default),
`landjail`. See [Jail Types](#jail-types) for a detailed comparison.
- `log_dir` defines where boundary writes log files.
- `log_level` defines the verbosity at which requests are logged. Agent
Firewall uses the following verbosity levels:
- `WARN`: logs only requests that have been blocked by Agent Firewall
- `INFO`: logs all requests at a high level
- `DEBUG`: logs all requests in detail
- `no_user_namespace` disables creation of a user namespace inside the jail.
Enable this in restricted environments that disallow user namespaces, such
as Bottlerocket nodes in EKS auto-mode. Only applies to the `nsjail` jail
type.
- `proxy_port` defines the port used by the HTTP proxy. Default: `8080`.
- `use_real_dns` uses the host's real DNS resolver inside the jail instead of
the built-in dummy DNS server. This allows DNS resolution for non-proxied
traffic but permits DNS-based data exfiltration. Default: `false`.
For detailed information about the rules engine and how to construct allowlist
rules, see the [rules engine documentation](./rules-engine.md).
You can also run Agent Firewall directly in your workspace and configure it
per template. You can do so by installing the
[binary](https://github.com/coder/boundary) into the workspace image or at
start-up. You can do so with the following command:
```bash
curl -fsSL https://raw.githubusercontent.com/coder/boundary/main/install.sh | bash
```
## Jail Types
Agent Firewall supports two different jail types for process isolation, each
with different characteristics and requirements:
1. **nsjail** - Uses Linux namespaces for isolation. This is the default jail
type and provides network namespace isolation. See
[nsjail documentation](./nsjail/index.md) for detailed information about runtime
requirements and Docker configuration.
2. **landjail** - Uses Landlock V4 for network isolation. This provides network
isolation through the Landlock Linux Security Module (LSM) without requiring
network namespace capabilities. See [landjail documentation](./landjail.md)
for implementation details.
The choice of jail type depends on your security requirements, available Linux
capabilities, and runtime environment. Both nsjail and landjail provide network
isolation, but they use different underlying mechanisms. nsjail uses Linux
namespaces, while landjail uses Landlock V4. Landjail may be preferred in
environments where namespace capabilities are limited or unavailable.
## Implementation Comparison: Namespaces+iptables vs Landlock V4
| Aspect | Namespace Jail (Namespaces + veth-pair + iptables) | Landlock V4 Jail |
|-------------------------------|-----------------------------------------------------------------------------------|-------------------------------------------------------------------------|
| **Privileges** | Requires `CAP_NET_ADMIN` | ✅ No special capabilities required |
| **Docker seccomp** | ❌ Requires seccomp profile modifications or sysbox-runc | ✅ Works without seccomp changes |
| **Kernel requirements** | Linux 3.8+ (widely available) | ❌ Linux 6.7+ (very new, limited adoption) |
| **Bypass resistance** | ✅ Strong - transparent interception prevents bypass | ❌ **Medium - can bypass by connecting to `evil.com:<HTTP_PROXY_PORT>`** |
| **Process isolation** | ✅ PID namespace (processes can't see/kill others); **implementation in-progress** | ❌ No PID namespace (agent can kill other processes) |
| **Non-TCP traffic control** | ✅ Can block/control UDP via iptables; **implementation in-progress** | ❌ No control over UDP (data can leak via UDP) |
| **Application compatibility** | ✅ Works with ANY application (transparent interception) | ❌ Tools without `HTTP_PROXY` support will be blocked |
## Audit Logs
Agent Firewall streams audit logs to the Coder control plane, providing
centralized visibility into HTTP requests made within workspaces—whether from AI
agents or ad-hoc commands run with `boundary`.
Audit logs are independent of application logs:
- **Audit logs** record Agent Firewall's policy decisions: whether each HTTP
request was allowed or denied based on the allowlist rules. These are always
sent to the control plane regardless of Agent Firewall's configured log
level.
- **Application logs** are Agent Firewall's operational logs written locally to
the workspace. These include startup messages, internal errors, and debugging
information controlled by the `log_level` setting.
For example, if a request to `api.example.com` is allowed by Agent Firewall
but the remote server returns a 500 error, the audit log records
`decision=allow` because Agent Firewall permitted the request. The HTTP
response status is not tracked in audit logs.
> [!NOTE]
> Requires Coder v2.30+ and Agent Firewall v0.5.2+.
### Audit Log Contents
Each Agent Firewall audit log entry includes:
| Field | Description |
|-----------------------|-----------------------------------------------------------------------------------------|
| `decision` | Whether the request was allowed (`allow`) or blocked (`deny`) |
| `workspace_id` | The UUID of the workspace where the request originated |
| `workspace_name` | The name of the workspace where the request originated |
| `owner` | The owner of the workspace where the request originated |
| `template_id` | The UUID of the template that the workspace was created from |
| `template_version_id` | The UUID of the template version used by the current workspace build |
| `http_method` | The HTTP method used (GET, POST, PUT, DELETE, etc.) |
| `http_url` | The fully qualified URL that was requested |
| `event_time` | Timestamp when boundary processed the request (RFC3339 format) |
| `matched_rule` | The allowlist rule that permitted the request (only present when `decision` is `allow`) |
### Viewing Audit Logs
Agent Firewall audit logs are emitted as structured log entries from the Coder
server. You can collect and analyze these logs using any log aggregation system
such as Grafana Loki.
Example of an allowed request (assuming stderr):
```console
2026-01-16 00:11:40.564 [info] coderd.agentrpc: boundary_request owner=joe workspace_name=some-task-c88d agent_name=dev decision=allow workspace_id=f2bd4e9f-7e27-49fc-961e-be4d1c2aa987 http_method=GET http_url=https://dev.coder.com event_time=2026-01-16T00:11:39.388607657Z matched_rule=domain=dev.coder.com request_id=9f30d667-1fc9-47ba-b9e5-8eac46e0abef trace=478b2b45577307c4fd1bcfc64fad6ffb span=9ece4bc70c311edb
```
docs/ai-coder/agent-firewall/landjail.md
+15
View File
@@ -0,0 +1,15 @@
# landjail Jail Type
landjail is Agent Firewall's alternative jail type that uses Landlock V4 for
network isolation.
## Overview
Agent Firewall uses Landlock V4 to enforce network restrictions:
- All `bind` syscalls are forbidden
- All `connect` syscalls are forbidden except to the port that is used by http
proxy
This provides network isolation without requiring network namespace capabilities
or special Docker permissions.
docs/ai-coder/agent-firewall/nsjail/docker.md
+99
View File
@@ -0,0 +1,99 @@
# nsjail on Docker
This page describes the runtime and permission requirements for running Agent
Firewall with the **nsjail** jail type on **Docker**.
For an overview of nsjail, see [nsjail](./index.md).
## Runtime & Permission Requirements for Running Boundary in Docker
This section describes the Linux capabilities and runtime configurations
required to run Agent Firewall with nsjail inside a Docker container.
Requirements vary depending on the OCI runtime and the seccomp profile in use.
### 1. Default `runc` runtime with `CAP_NET_ADMIN`
When using Docker's default `runc` runtime, Agent Firewall requires the
container to have `CAP_NET_ADMIN`. This is the minimal capability needed for
configuring virtual networking inside the container.
Docker's default seccomp profile may also block certain syscalls (such as
`clone`) required for creating unprivileged network namespaces. If you encounter
these restrictions, you may need to update or override the seccomp profile to
allow these syscalls.
[see Docker Seccomp Profile Considerations](#docker-seccomp-profile-considerations)
### 2. Default `runc` runtime with `CAP_SYS_ADMIN` (testing only)
For development or testing environments, you may grant the container
`CAP_SYS_ADMIN`, which implicitly bypasses many of the restrictions in Docker's
default seccomp profile.
- Agent Firewall does not require `CAP_SYS_ADMIN` itself.
- However, Docker's default seccomp policy commonly blocks namespace-related
syscalls unless `CAP_SYS_ADMIN` is present.
- Granting `CAP_SYS_ADMIN` enables Agent Firewall to run without modifying the
seccomp profile.
⚠️ Warning: `CAP_SYS_ADMIN` is extremely powerful and should not be used in
production unless absolutely necessary.
### 3. `sysbox-runc` runtime with `CAP_NET_ADMIN`
When using the `sysbox-runc` runtime (from Nestybox), Agent Firewall can run
with only:
- `CAP_NET_ADMIN`
The sysbox-runc runtime provides more complete support for unprivileged user
namespaces and nested containerization, which typically eliminates the need for
seccomp profile modifications.
## Docker Seccomp Profile Considerations
Docker's default seccomp profile frequently blocks the `clone` syscall, which is
required by Agent Firewall when creating unprivileged network namespaces. If
the `clone` syscall is denied, Agent Firewall will fail to start.
To address this, you may need to modify or override the seccomp profile used by
your container to explicitly allow the required `clone` variants.
You can find the default Docker seccomp profile for your Docker version here
(specify your docker version):
https://github.com/moby/moby/blob/v25.0.13/profiles/seccomp/default.json#L628-L635
If the profile blocks the necessary `clone` syscall arguments, you can provide a
custom seccomp profile that adds an allow rule like the following:
```json
{
"names": ["clone"],
"action": "SCMP_ACT_ALLOW"
}
```
This example unblocks the clone syscall entirely.
### Example: Overriding the Docker Seccomp Profile
To use a custom seccomp profile, start by downloading the default profile for
your Docker version:
https://github.com/moby/moby/blob/v25.0.13/profiles/seccomp/default.json#L628-L635
Save it locally as seccomp-v25.0.13.json, then insert the clone allow rule shown
above (or add "clone" to the list of allowed syscalls).
Once updated, you can run the container with the custom seccomp profile:
```bash
docker run -it \
--cap-add=NET_ADMIN \
--security-opt seccomp=seccomp-v25.0.13.json \
test bash
```
This instructs Docker to load your modified seccomp profile while granting only
the minimal required capability (`CAP_NET_ADMIN`).
docs/ai-coder/agent-firewall/nsjail/ecs.md
+38
View File
@@ -0,0 +1,38 @@
# nsjail on ECS
This page describes the runtime and permission requirements for running Agent
Firewall with the **nsjail** jail type on **Amazon ECS**.
## Runtime & Permission Requirements for Running Agent Firewall in ECS
The setup for ECS is similar to [nsjail on Kubernetes](./k8s.md); that environment
is better explored and tested, so the Kubernetes page is a useful reference. On
ECS, requirements depend on the node OS and how ECS runs your tasks. The
following examples use **ECS with Self Managed Node Groups** (EC2 launch type).
---
### Example 1: ECS + Self Managed Node Groups + Amazon Linux
On **Amazon Linux** nodes with ECS, the default Docker seccomp profile enforced
by ECS blocks the syscalls needed for Agent Firewall. Because it is difficult to
disable or modify the seccomp profile on ECS, you must grant `SYS_ADMIN` (along
with `NET_ADMIN`) so that Agent Firewall can create namespaces and run nsjail.
**Task definition (Terraform) — `linuxParameters`:**
```hcl
container_definitions = jsonencode([{
name = "coder-agent"
image = "your-coder-agent-image"
linuxParameters = {
capabilities = {
add = ["NET_ADMIN", "SYS_ADMIN"]
}
}
}])
```
This gives the container the capabilities required for nsjail when ECS uses the
default Docker seccomp profile.
docs/ai-coder/agent-firewall/nsjail/index.md
+27
View File
@@ -0,0 +1,27 @@
# nsjail Jail Type
nsjail is Agent Firewall's default jail type that uses Linux namespaces to
provide process isolation. It creates unprivileged network namespaces to control
and monitor network access for processes running under Boundary.
**Running on Docker, Kubernetes, or ECS?** See the relevant page for runtime
and permission requirements:
- [nsjail on Docker](./docker.md)
- [nsjail on Kubernetes](./k8s.md)
- [nsjail on ECS](./ecs.md)
## Overview
nsjail leverages Linux namespace technology to isolate processes at the network
level. When Agent Firewall runs with nsjail, it creates a separate network
namespace for the isolated process, allowing Agent Firewall to intercept and
filter all network traffic according to the configured policy.
This jail type requires Linux capabilities to create and manage network
namespaces, which means it has specific runtime requirements when running in
containerized environments like Docker and Kubernetes.
## Architecture
<img width="1228" height="604" alt="Boundary" src="https://github.com/user-attachments/assets/1b7c8c5b-7b8f-4adf-8795-325bd28715c6" />
docs/ai-coder/agent-firewall/nsjail/k8s.md
+129
View File
@@ -0,0 +1,129 @@
# nsjail on Kubernetes
This page describes the runtime and permission requirements for running Agent
Firewall with the **nsjail** jail type on **Kubernetes**.
## Runtime & Permission Requirements for Running Boundary in Kubernetes
Requirements depend on the node OS and the container runtime. The following
examples use **EKS with Managed Node Groups** for two common node AMIs.
---
### Example 1: EKS + Managed Node Groups + Amazon Linux
On **Amazon Linux** nodes, the default seccomp and runtime behavior typically
allow the syscalls needed for Boundary. You only need to
grant `NET_ADMIN`.
**Container `securityContext`:**
```yaml
apiVersion: v1
kind: Pod
metadata:
name: coder-agent
spec:
containers:
- name: coder-agent
image: your-coder-agent-image
securityContext:
capabilities:
add:
- NET_ADMIN
# ... rest of container spec
```
---
### Example 2: EKS + Managed Node Groups + Bottlerocket
On **Bottlerocket** nodes, the default seccomp profile often blocks the `clone`
syscalls required for unprivileged user namespaces. You must either disable or
modify seccomp for the pod (see [Docker Seccomp Profile Considerations](./docker.md#docker-seccomp-profile-considerations)) or grant `SYS_ADMIN`.
**Option A: `NET_ADMIN` + disable seccomp**
Disabling the seccomp profile allows the container to create namespaces
without granting `SYS_ADMIN` capabilities.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: coder-agent
spec:
containers:
- name: coder-agent
image: your-coder-agent-image
securityContext:
capabilities:
add:
- NET_ADMIN
seccompProfile:
type: Unconfined
# ... rest of container spec
```
**Option B: `NET_ADMIN` + `SYS_ADMIN`**
Granting `SYS_ADMIN` bypasses many seccomp restrictions and allows namespace
creation.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: coder-agent
spec:
containers:
- name: coder-agent
image: your-coder-agent-image
securityContext:
capabilities:
add:
- NET_ADMIN
- SYS_ADMIN
# ... rest of container spec
```
### User namespaces on Bottlerocket
User namespaces are often disabled (`user.max_user_namespaces=0`) on Bottlerocket
nodes. Check and enable user namespaces:
```bash
# Check current value
sysctl user.max_user_namespaces
# If it returns 0, enable user namespaces
sysctl -w user.max_user_namespaces=65536
```
If `sysctl -w` is not allowed, configure it via Bottlerocket bootstrap settings
when creating the node group (e.g., in Terraform):
```hcl
bootstrap_extra_args = <<-EOT
[settings.kernel.sysctl]
"user.max_user_namespaces" = "65536"
EOT
```
This ensures Boundary can create user namespaces with nsjail.
### Running without user namespaces
If the environment is restricted and you cannot enable user namespaces (e.g.
Bottlerocket in EKS auto-mode), you can run Boundary with the
`--no-user-namespace` flag. Use this when you have no way to allow user namespace creation.
---
### Example 3: EKS + Fargate (Firecracker VMs)
nsjail is not currently supported on **EKS Fargate** (Firecracker-based VMs), which
blocks the capabilities needed for nsjail.
If you run on Fargate, we recommend using [landjail](../landjail.md) instead,
provided kernel version supports it (Linux 6.7+).
docs/ai-coder/agent-firewall/rules-engine.md
+107
View File
@@ -0,0 +1,107 @@
# Rules Engine Documentation
## Overview
The `rulesengine` package provides a flexible rule-based filtering system for
HTTP/HTTPS requests. Rules use a simple key-value syntax with support for
wildcards and multiple values.
### Basic Syntax
Rules follow the format: `key=value [key=value ...]` with three supported keys:
- **`method`**: HTTP method(s) - Any HTTP method (e.g., `GET`, `POST`, `PUT`,
`DELETE`), `*` (all methods), or comma-separated list
- **`domain`**: Domain/hostname pattern - `github.com`, `*.example.com`, `*`
(all domains)
- **`path`**: URL path pattern - `/api/users`, `/api/*/users`, `*` (all paths),
or comma-separated list
**Key behavior**:
- If a key is omitted, it matches all values
- Multiple key-value pairs in one rule are separated by whitespace
- Multiple rules in the allowlist are OR'd together (OR logic)
- Default deny: if no rule matches, the request is denied
**Examples**:
```yaml
allowlist:
- domain=github.com # All methods, all paths for github.com (exact match)
- domain=*.github.com # All subdomains of github.com
- method=GET,POST domain=api.example.com # GET/POST to api.example.com (exact match)
- domain=api.example.com path=/users,/posts # Multiple paths
- method=GET domain=github.com path=/api/* # All three keys
```
---
## Wildcard Symbol for Domains
The `*` wildcard matches domain labels (parts separated by dots).
| Pattern | Matches | Does NOT Match |
|----------------|-------------------------------------------------------------|--------------------------------------------------------------------------|
| `*` | All domains | - |
| `github.com` | `github.com` (exact match only) | `api.github.com`, `v1.api.github.com` (subdomains), `github.io` |
| `*.github.com` | `api.github.com`, `v1.api.github.com` (1+ subdomain levels) | `github.com` (base domain) |
| `api.*.com` | `api.github.com`, `api.google.com` | `api.v1.github.com` (`*` in the middle matches exactly one domain label) |
| `*.*.com` | `api.example.com`, `api.v1.github.com` | - |
| `api.*` | ❌ **ERROR** - Cannot end with `*` | - |
**Important**:
- Patterns without `*` match **exactly** (no automatic subdomain matching)
- `*.example.com` matches one or more subdomain levels
- To match both base domain and subdomains, use separate rules:
`domain=github.com` and `domain=*.github.com`
- Domain patterns **cannot end with asterisk**
---
## Wildcard Symbol for Paths
The `*` wildcard matches path segments (parts separated by slashes).
| Pattern | Matches | Does NOT Match |
|----------------|------------------------------------------------------------|-----------------------------------------|
| `*` | All paths | - |
| `/api/users` | `/api/users` | `/api/users/123` (subpaths don't match) |
| `/api/*` | `/api/users`, `/api/posts` | `/api` |
| `/api/*/users` | `/api/v1/users`, `/api/v2/users` | `/api/users`, `/api/v1/v2/users` |
| `/*/users` | `/api/users`, `/v1/users` | `/api/v1/users` |
| `/api/v1/*` | `/api/v1/users`, `/api/v1/users/123/details` (1+ segments) | `/api/v1` |
**Important**:
- `*` matches **exactly one segment** (except at the end)
- `*` at the **end** matches **one or more segments** (special behavior)
- `*` must match an entire segment (cannot be part of a segment like
`/api/user*`)
---
## Special Meaning of Wildcard at Beginning and End
| Position | Domain | Path |
|------------|---------------------|-----------------------|
| Beginning | 1+ subdomain levels | Exactly 1 segment |
| Middle | Exactly 1 label | Exactly 1 segment |
| End | ❌ Not allowed | 1+ segments (special) |
| Standalone | All domains | All paths |
---
## Multipath
Specify multiple paths in a single rule by separating them with commas:
```yaml
allowlist:
- domain=api.example.com path=/users,/posts,/comments
- domain=api.example.com path=/api,/api/*
```
`NOTE`: The pattern `/api/*` does not include the base path `/api`. To match
both, use `path=/api,/api/*`.
docs/ai-coder/agent-firewall/version.md
+65
View File
@@ -0,0 +1,65 @@
# Version Requirements
## Recommended Versions
It's recommended to use **Coder v2.30.0 or newer** and **Claude Code module
v4.7.0 or newer**.
### Coder v2.30.0+
Since Coder v2.30.0, Agent Firewall is embedded inside the Coder binary, and
you don't need to install it separately. The `coder boundary` subcommand is
available directly from the Coder CLI.
### Claude Code Module v4.7.0+
Since Claude Code module v4.7.0, the embedded `coder boundary` subcommand is
used by default. This means you don't need to set `boundary_version`; the
boundary version is tied to your Coder version.
## Compatibility with Older Versions
### Using Coder Before v2.30.0 with Claude Code Module v4.7.0+
If you're using Coder before v2.30.0 with Claude Code module v4.7.0 or newer,
the `coder boundary` subcommand isn't available in your Coder installation. In
this case, you need to:
1. Set `use_boundary_directly = true` in your Terraform module configuration
2. Explicitly set `boundary_version` to specify which Agent Firewall version
to install
Example configuration:
```tf
module "claude-code" {
source = "dev.registry.coder.com/coder/claude-code/coder"
version = "4.7.0"
enable_boundary = true
use_boundary_directly = true
boundary_version = "0.6.0"
}
```
### Using Claude Code Module Before v4.7.0
If you're using Claude Code module before v4.7.0, the module expects to use
Agent Firewall directly. You need to explicitly set `boundary_version` in your
Terraform configuration:
```tf
module "claude-code" {
source = "dev.registry.coder.com/coder/claude-code/coder"
version = "4.6.0"
enable_boundary = true
boundary_version = "0.6.0"
}
```
## Summary
| Coder Version | Claude Code Module Version | Configuration Required |
|---------------|----------------------------|-------------------------------------------------------|
| v2.30.0+ | v4.7.0+ | No additional configuration needed |
| < v2.30.0 | v4.7.0+ | `use_boundary_directly = true` and `boundary_version` |
| Any | < v4.7.0 | `boundary_version` |