Actions Object Structure
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
Example
allowedDomains
Key:
| Key | Type | Description | Example |
|---|---|---|---|
| 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 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:
-
Domain only - Allows all protocols and ports:
-
With protocol - Restricts to specific protocol:
-
With protocol and port - Restricts to specific protocol and port:
-
Internal addresses (must be explicitly allowed):
Example:
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.
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.
How is this guide?