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 subdomain wildcards (e.g., *.amazonaws.com) and a catch-all * that matches any host.
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

If no rule matches, the request is denied — every policy is default-deny at the fall-through. An explicit * rule is the way to opt into broader access patterns; combined with HTTP-method restrictions (e.g., GET/HEAD/OPTIONS only), * expresses "read-only internet" without abandoning the rest of the policy's controls.

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

Policy templates#

To avoid re-typing the same well-known domains into every new policy, the platform offers a built-in catalog of starting-point templates. Each template pre-fills an editable policy with a curated bundle of domains for a common need:

  • Package managers — npm, PyPI, RubyGems, Maven, etc.
  • Git hosting — GitHub, GitLab, Bitbucket
  • Container registries — Docker Hub, ghcr, gcr, quay
  • AI providers — Anthropic, OpenAI, AWS Bedrock, etc.
  • Developer SaaS — observability, error tracking, CI providers
  • Project management — Jira, Linear, Asana
  • Messaging — Slack, Microsoft Teams
  • Read-only internet — * with HTTPS + GET/HEAD/OPTIONS only

Templates are starting points — admins edit the resulting policy before using it, so customers stay in control of exactly which hosts and methods are reachable. Custom templates can be scoped during evaluation engagement.

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.