The short version
An allowlist answers one question: which upstream hostname may this workspace reach? Keep the answer as narrow as possible.
01
Use host patterns—not URLs
Safe entries look like api.openai.com, api.stripe.com, or *.salesforce.com. Do not include https://, a port, path, query string, username, password, or fragment.
Plain host entries match that exact host only. They do not automatically approve the parent or any child hostname.
02
Understand one-level wildcards
*.example.com approves api.example.com but not example.com and not v1.api.example.com. Deeper wildcard behavior is intentionally unavailable.
Public suffixes and hosted-platform suffixes are rejected so a workspace cannot approve an entire TLD or broad shared hosting surface.
- Prefer api.example.com over *.example.com.
- Review every wildcard as a broader trust decision.
- Remove a host when the application no longer needs it.
03
Private and unsafe targets remain blocked
Localhost, private and reserved IPv4/IPv6 ranges, cloud metadata targets, local names, unsafe protocols, credentials in URLs, and unsafe ports are rejected.
Hostnames are resolved server-side. Any private or reserved DNS answer rejects the request, and outbound connections use the validated result while TLS verifies the intended hostname.
04
Custom domains are a separate concern
A custom domain gives your workspace a branded hostname and DNS verification workflow. It does not broaden which upstream hosts may be contacted.
Treat DNS record values as operational configuration. Confirm the intended hostname and workspace before publishing records.
Before you move on
- Entry contains a hostname only
- Exact host is used unless one varying subdomain level is required
- No public suffix, localhost, private address, or metadata target is used
- Custom domain and upstream authorization are treated separately
- Configuration is re-synchronized after reviewed changes