execute_code tool. This provides a security boundary that prevents agents from making requests to unauthorized endpoints.
How It Works
- Add domains at the organization level (e.g.
api.example.com,data.internal.corp) - Configure access — domains are available to all agents by default, or can be restricted to specific agents
- When an agent runs
execute_codewithawait fetch(), only allowed domains are permitted
Managing Domains
Navigate to your organization’s Settings page to manage allowed domains.Adding a Domain
Click Add Domain and enter the hostname. Accepted formats:| Format | Example |
|---|---|
| Standard hostname | api.example.com |
| Subdomain | data.internal.example.com |
| Single-label hostname | localhost |
| IPv4 address | 192.168.1.100 |
| IPv6 address | ::1 |
Headers and Query Parameters
Each domain can have HTTP headers and query parameters that are automatically injected into all requests at runtime. This is useful for authentication. Use{{SECRET_NAME}} placeholders to reference encrypted secrets (created via Settings > Secrets) — they are resolved at runtime so plaintext values are never stored in domain config.
Example: To authenticate with an API key header:
Agent Access
By default, every agent in the organization can use a domain. If you need to restrict a domain to specific agents, you can set per-agent access via the API or MCP tools (set_collection_agents pattern).
Deleting a Domain
Deleting a domain removes it from the allowlist immediately. Agents will no longer be able to fetch from that domain.Fallback Behavior
When no org-level domains are configured, agents fall back to the system-wideCUSTOM_SKILL_ALLOWED_DOMAINS environment variable (a comma-separated list of domains). Once your organization has at least one domain configured, the fallback is not used.
Permissions
| Action | Required Permission |
|---|---|
| View domains | org:read |
| Add / update / delete domains | org:update |