Policy-Controlled Proxy#
Access any system with an HTTP/HTTPS endpoint — CRM, ticketing systems, databases, internal APIs, SaaS services — through the policy-controlled proxy.
How It Works#
Every outbound request from an agent passes through the sandbox proxy. The proxy evaluates each request against the agent's policy rules and either allows or blocks it.
Step by step:
- Agent makes an outbound HTTPS request to a target system (e.g.,
api.jira.example.com) - Proxy intercepts the request and matches the destination domain against policy rules
- If the domain is allowed: the request proceeds. If credential bindings are configured for this domain, the proxy injects authentication headers before forwarding.
- If the domain is denied (or not listed): the request is blocked. All policies use default-deny — domains not explicitly allowed are blocked.
- The response is returned to the agent
- The request is recorded in the audit trail with the destination, method, path, and status
The agent never sees raw credentials. Authentication happens at the proxy level, outside the agent's environment.
What You Can Connect#
Any system with an HTTP or HTTPS API:
| Category | Examples |
|---|---|
| CRM | Salesforce, HubSpot, Pipedrive |
| Ticketing | Jira, ServiceNow, Zendesk, Linear |
| Monitoring | PagerDuty, Datadog, Grafana |
| Databases | Any database with a REST API or HTTP proxy |
| Internal APIs | Custom microservices, internal dashboards |
| SaaS platforms | Slack API, Notion, Confluence, Google Workspace |
| Cloud services | Any cloud provider API beyond the native integrations |
If it has an HTTP endpoint and your agent has a reason to call it, the proxy can govern the connection.
Configuring domain policies#
Add allowed domains to your team's policy. Each domain rule specifies a pattern and an action:
allowedDomains:
- pattern: "api.jira.example.com"
action: "allow"
- pattern: "*.servicenow.com"
action: "allow"
Wildcard patterns (*.example.com) match any subdomain.
HTTP-level restrictions#
For fine-grained control, restrict which HTTP methods and URL paths are allowed on a domain:
allowedDomains:
- pattern: "api.jira.example.com"
action: "allow"
httpRestrictions:
- method: "GET"
path: "/rest/api/2/issue/*"
- method: "POST"
path: "/rest/api/2/issue"
- method: "GET"
path: "/rest/api/2/search"
This allows the agent to read issues, create new issues, and search — but not delete issues or access other API endpoints.
Credential Injection#
Credentials are injected at the proxy level using credential bindings. Configure a binding to specify which header to inject and in what format:
credentials:
- name: "jira-token"
envVarKey: "JIRA_API_TOKEN"
injections:
- domain: "api.jira.example.com"
headerName: "Authorization"
headerFormat: "Basic {base64:user@example.com:{value}}"
Supported injection formats:
| Format | Result |
|---|---|
{value} |
Raw credential value |
Bearer {value} |
Standard Bearer token |
Basic {base64:prefix{value}} |
Base64-encoded Basic auth |
The agent makes a plain HTTP request. The proxy adds the authentication header before forwarding. The credential never enters the agent's memory or context.
Audit Trail#
Every proxied request is recorded:
- Destination domain and full URL path
- HTTP method (GET, POST, PUT, DELETE, etc.)
- Response status code
- Timestamp
- Agent identity — which agent made the request
This gives security teams full visibility into what external systems agents are accessing and what actions they are taking.
Example: Connecting to PagerDuty#
-
Add the domain to your policy:
allowedDomains: - pattern: "api.pagerduty.com" action: "allow" -
Add a credential binding:
credentials: - name: "pagerduty-token" envVarKey: "PAGERDUTY_API_KEY" injections: - domain: "api.pagerduty.com" headerName: "Authorization" headerFormat: "Token token={value}" -
The agent can now query PagerDuty for incidents, acknowledge alerts, and check on-call schedules — all governed by policy and recorded in the audit trail.
Related#
- Connections overview — all connection types
- Policies — domain rules and HTTP restrictions
- Credential bindings — server-side credential injection
- Credential injection concept — how credentials stay out of the agent's environment