For AI agents: the complete documentation index is available at https://docs.flezise.com/llms.txt, the full documentation bundle is available at https://docs.flezise.com/llms-full.txt, and this page is available as Markdown at https://docs.flezise.com/sandboxes/network-access.md.
Docs
  • 26.11

    • Network access and secrets

    Every project has one shared shell sandbox where agents and automations run commands. On Kubernetes deployments it blocks all outbound traffic except to trusted domains, and it can attach a project's API keys to requests without the commands ever seeing them.

    Note

    Read this if you administer the platform or a project. The rules apply on Kubernetes (OpenSandbox). Docker installs show a notice on the settings page and don't enforce them.

    What the shell can reach

    A command in the shell can open a connection only to:

    • the built-in domains: GitHub, the npm, PyPI, Go, crates.io, Maven and RubyGems registries, JSR, and the OSV and NVD vulnerability databases, plus the deployment's preview environments
    • the organization's trusted domains
    • the project's trusted domains
    • the hosts of the project's secrets

    Platform services and private networks are always blocked. The shell cannot reach the backend, the AI gateway or any cluster-internal name, and the settings refuse IP addresses, URLs, ports and names such as .svc, .cluster.local, .internal or .local. A domain can start with *. to cover its subdomains: *.sentry.io.

    The agents themselves keep working: their tools, the platform CLI and MCP servers run outside this sandbox.

    1. Trust domains for every project

    Open Settings → Trusted Domains, type a domain and press Add. Every project's shell can reach it. The built-in domains are listed below your own.

    Changing the platform setting requires the general settings permission.

    2. Trust domains for one project

    Open the project's Settings → Trusted Domains and add the domain. The page lists the organization's and built-in domains, which the project inherits and cannot remove.

    3. Add a secret

    Open the project's Settings → Secrets, press Add secret, and pick a Kind:

    KindYou enterSent on each matching request
    API tokenthe tokenAuthorization: Bearer <token>
    API key in headersone to five header names, each with its own valueeach header, e.g. X-Api-Key, or a client ID and secret as two headers
    Username and passwordusername and passwordAuthorization: Basic
    OAuth client credentialsclient ID and client secretAuthorization: Basic on requests to the token endpoint
    Value in requeststhe valuethe value, where a command wrote the secret's placeholder in the URL, a header or the body

    Every kind also needs a Name (lowercase letters, digits, - or _) and Hosts: the hosts that receive it, separated by commas or spaces. They become trusted for this project. For OAuth client credentials, use the token endpoint's host. The access token it returns is visible to commands like any other response, so prefer short-lived tokens.

    A Value in requests secret named db-token has the placeholder __SECRET_DB-TOKEN__, shown in the list. A command writes it where the API expects the value, for example curl "https://api.example.com/v1/items?key=__SECRET_DB-TOKEN__", and the proxy replaces it on the way out.

    Press Save secret. The values go to the platform's secret store and cannot be viewed again; to change one, remove the secret and add it again.

    When a command sends an HTTPS request to one of the hosts, the sandbox's network proxy adds the credential. The values never enter the sandbox: they are not environment variables, not files, and not printed by any command. Requests to every other host leave without them.

    Secrets work only for HTTPS APIs. A database password, an SSH key or any value a program reads from a file or variable would have to enter the sandbox, so it can't be stored here.

    Warning

    Bind a secret only to the API host that needs it. A host that echoes request headers back, such as a debugging service, would show the secret to whoever reads the response.

    When a change applies

    Changes reach running shells within seconds, without restarting them: commands already running keep going, and the next connection follows the new rules. The one exception is a project's first secret while its shell is running: that shell restarts once to start the network proxy that adds secrets. Files in the project are kept.

    Next steps