# Actions Object Structure (https://www.librechat.ai/docs/configuration/librechat_yaml/object_structure/actions)

Actions can be used to dynamically create tools from OpenAPI specs. The `actions` object structure allows you to specify allowed domains for agent/assistant actions.

More info: [Agents - Actions](/docs/features/agents#actions)

## Example

```yaml filename="Actions Object Structure"
# Example Actions Object Structure
actions:
  # Strict whitelist mode:
  # allowedDomains:
  #   - "swapi.dev"
  #   - "librechat.ai"
  #   - "google.com"
  #   - "https://api.example.com:8443"  # With protocol and port

  # Default SSRF mode with private service exemptions:
  allowedAddresses:
    - "host.docker.internal:11434"    # Permit one private host on one port
    - "10.0.0.5:8080"                 # Permit one private IP on one port
```

## allowedDomains

**Key:**
<OptionTable
  options={[
    ['allowedDomains', 'Array of Strings', 'A list specifying allowed domains for agent/assistant actions.', 'When configured, only listed domains are allowed. When not configured, SSRF targets are blocked but all other domains are allowed.'],
  ]}
/>

**Optional**

### Security Context (SSRF Protection)

LibreChat includes SSRF (Server-Side Request Forgery) protection with the following behavior:

When an Action is created from OpenAPI metadata, LibreChat also verifies that the submitted Action domain matches the spec's server URL. If the submitted domain includes an explicit port, it must match the server URL's effective port (`443` for HTTPS or `80` for HTTP when the URL omits one).

**When `allowedDomains` is NOT configured:**
- SSRF-prone targets are **blocked by default**
- All other external domains are **allowed**

**When `allowedDomains` IS configured:**
- **Only** domains on the list are allowed
- Internal/SSRF targets can be allowed by explicitly adding them to the list

**Blocked SSRF targets include:**
- **Localhost** addresses (`localhost`, `127.0.0.1`, `::1`)
- **Private IP ranges** (`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`)
- **Link-local addresses** (`169.254.0.0/16`, includes cloud metadata IPs)
- **Internal TLDs** (`.internal`, `.local`, `.localhost`)
- **Common internal service names** (`redis`, `mongodb`, `postgres`, `api`, etc.)

If your actions need to access internal services, either add them to the strict `allowedDomains` whitelist, or leave `allowedDomains` unset and add the exact private service to `allowedAddresses`.

### Pattern Formats

The `allowedDomains` array supports several formats:

1. **Domain only** - Allows all protocols and ports:
   ```yaml
   allowedDomains:
     - "api.example.com"
   ```

2. **With protocol** - Restricts to specific protocol:
   ```yaml
   allowedDomains:
     - "https://api.example.com"
   ```

3. **With protocol and port** - Restricts to specific protocol and port:
   ```yaml
   allowedDomains:
     - "https://api.example.com:8443"
   ```

4. **Internal addresses** (must be explicitly allowed):
   ```yaml
   allowedDomains:
     - "192.168.1.100"
     - "internal-api.local"
   ```

**Example:**
```yaml filename="actions / allowedDomains"
allowedDomains:
  - "swapi.dev"
  - "librechat.ai"
  - "google.com"
  - "https://secure-api.example.com:443"
  - "192.168.1.50"  # Internal service (explicitly allowed)
```

## allowedAddresses

`allowedAddresses` is an **exemption list** for the SSRF private-IP block — not a domain whitelist. It is the right tool when you want to permit one or two specific private/internal services without restricting what your Actions can reach in the public internet.

### When to use it instead of `allowedDomains`

`allowedDomains` is a strict whitelist: when it is set, **only** listed entries are reachable. Adding a private IP there to permit, say, a self-hosted internal API also blocks every public action endpoint that you didn't also list.

`allowedAddresses` is used only when `allowedDomains` is not configured. It permits specific private `host:port` targets while leaving the rest of the public internet reachable through the default SSRF policy.

```yaml filename="default SSRF + permitted private host"
actions:
  allowedAddresses:
    - "host.docker.internal:11434"
    - "10.0.0.5:8080"
  # allowedDomains is intentionally not set — public destinations
  # remain reachable, only listed private host:port services are exempted.
```

If `allowedDomains` is configured, it is authoritative: private services must be listed there instead of relying on `allowedAddresses`.

### Acceptable entries

- **Hostnames with port**: `host.docker.internal:11434`, `ollama.internal:8080`, `localhost:11434`
- **Private IPv4 literals with port**: `10.0.0.5:8080`, `127.0.0.1:11434`, `192.168.1.10:443`, `169.254.169.254:80`
- **Bracketed private IPv6 literals with port**: `[::1]:11434`, `[fc00::1]:8080`, `[fe80::1]:8080`

### Rejected entries (validated at config load)

- **URLs / paths / CIDR ranges**: `http://10.0.0.5`, `10.0.0.0/24`, `/path`
- **Bare hostnames or IPs**: `localhost`, `10.0.0.5`, `::1`, `[::1]` — every entry must include a port
- **Invalid ports**: `localhost:0`, `localhost:65536`, `localhost:http`
- **Public IP literals**: `8.8.8.8:53`, `1.1.1.1:53`, `[2001:4860::8888]:443` — the field is scoped to private IP space; public IPs are not SSRF targets and a public-IP exemption has no defensive purpose

### Hostname trust

A hostname entry trusts whatever IP that hostname resolves to at runtime on the listed port. If the DNS for a listed hostname is rotated or hijacked to point at a different private IP, the exemption follows. Only list hostnames whose DNS you control. **Prefer literal IPs when you can.**