Skip to content

Policies#

Policies define what each agent can access — before it does it. Every agent action passes through the policy engine, which checks domain access, HTTP restrictions, and credential bindings.

How policies work#

When an agent makes an outbound request, the sandbox proxy evaluates it against the policy:

  1. Match the destination domain against the policy's domain rules (first-match-wins)
  2. If the domain is allowed, check HTTP method and URL path restrictions
  3. If credentials are bound to the domain, inject them server-side
  4. If no rule matches, the request is denied (default-deny)

Agents can only reach systems explicitly approved in their policy.

Domain rules#

Domain rules define which external systems an agent can access.

Field Description
Domain pattern The domain to match (e.g., api.github.com). Supports wildcards (e.g., *.amazonaws.com).
Action allow (route through platform), direct (allow without interception), or deny (block)

Examples:

api.github.com       → allow
*.eks.amazonaws.com  → allow
api.anthropic.com    → direct
*                    → deny (default)

HTTP-level restrictions#

Individual domains can be restricted to specific HTTP methods and URL paths:

api.example.com
  GET  /v1/tickets/*     → allow
  POST /v1/tickets       → allow
  DELETE                  → deny

This gives fine-grained control — an agent could read and create tickets but not delete them.

Credential bindings#

Credentials can be attached to policies. When an agent's request matches a domain with bound credentials, the platform injects the credentials server-side via the proxy. The agent never sees the raw secret.

How credential injection works:

  1. Admin binds a credential to a policy (e.g., an API key for api.github.com)
  2. When the agent makes a request to api.github.com, the proxy intercepts it
  3. The proxy injects the credential as an HTTP header (e.g., Authorization: Bearer <token>)
  4. The request reaches GitHub with valid credentials
  5. The agent receives the response — but never sees the credentials

Injection formats:

  • Authorization: Bearer <token> — OAuth/Bearer tokens
  • x-api-key: <key> — API keys
  • Custom header formats

See Credential Bindings for detailed configuration.

Integration controls#

Policies can enable or disable specific infrastructure connections per agent:

  • Kubernetes clusters — which clusters the agent can access
  • AWS accounts — which AWS connections are available
  • GitHub connections — which GitHub integrations are accessible
  • MCP servers — which registered MCP servers the agent can use

Example policies#

The following examples show common policy configurations. Policies are managed per team.

SRE agent with K8s + GitHub access#

allowedDomains:
  - pattern: "*.eks.amazonaws.com"
    action: allow
  - pattern: "api.github.com"
    action: allow
credentials:
  - name: github-token
    injections:
      - domain: api.github.com
        headerName: Authorization
        headerFormat: "Bearer {value}"

Support agent with CRM + ticketing (read-only)#

allowedDomains:
  - pattern: "api.zendesk.com"
    action: allow
    httpRestrictions:
      - method: GET
        path: "/api/v2/tickets/*"
      - method: GET
        path: "/api/v2/users/*"
  - pattern: "api.salesforce.com"
    action: allow
    httpRestrictions:
      - method: GET
        path: "/services/data/*"

Restricted agent — single API endpoint only#

allowedDomains:
  - pattern: "api.internal.example.com"
    action: allow
    httpRestrictions:
      - method: GET
        path: "/v1/status"
      - method: POST
        path: "/v1/reports"

Policy scope#

Policies apply at the team level. All agents in a team share the team's policy configuration. This means:

  • Admins define policies per team
  • All agents in the team get the same access rules
  • Adding a new agent to a team automatically applies the team's policies
  • Changes to a team's policy affect all its agents

Default-deny networking#

The sandbox starts with all outbound traffic blocked. Only domains explicitly listed in the policy are reachable. This is enforced at the kernel level (iptables) — not just at the application level. See Sandbox Isolation.

Error responses#

When a policy denies an agent's request, the platform returns a structured error following the RFC 7807 Problem Details format. The response includes the error type (authentication failed, authorization failed, policy denied, budget exceeded, token revoked), a human-readable message, and the matched policy rule — enough for the agent and the audit trail to reason about why the request was blocked.