Security & network

Cloud agents run in isolated environments in the cloud — not on your laptop. Your organization decides which repositories, secrets, and network destinations each run can use.

Think of it like CI with an agent inside: same mindset as Cursor's isolated cloud VMs, Devin's per-session sandbox, or Factory's allowlisted network — minimum access, review before merge, secrets managed by admins — not pasted into chat.

See also Agent security for approvals and controls that apply to local and cloud runs.

Why this matters

Security is layers: isolation, least privilege, secret hygiene, and human review — not one setting alone.

In practice

Isolation

Each cloud run gets its own sandbox. Runs do not share filesystem or process state with your machine or with each other.

Secrets

1. Use org secrets — never prompts

   Store API keys and tokens in your organization's secret or environment settings. Never paste credentials into task descriptions — they can appear in logs or exports.

2. Keep secrets out of git

   Keep .env, key files, and credential paths in .gitignore. Cloud agents respect the same ignore rules as local agents.

3. Rotate when access changes

   When someone with secret access leaves, rotate affected keys and review recent cloud activity in Sentinel.

Network access

By default, treat outbound access as restricted. Allow only the hosts your setup and tasks need — package registries, GitHub, internal APIs — rather than unrestricted internet access.

Admins configure egress in the dashboard. Developers feel it as "install works" or "API call blocked" — fix allowlists once, then reuse across runs and automations.

Who controls what

Members pick repo and task in the Agents workspace within those bounds.

Corporate networks

If traffic is filtered or proxied, the desktop app, CLI, browser, and cloud runs all need to reach X4RGE auth and agent services — not just the sandbox.

1. Allow X4RGE and auth

   Permit HTTPS to X4RGE product domains and your org's auth provider (see Troubleshooting if sign-in fails).

2. Allow GitHub if integrated

   Permit GitHub for OAuth and the GitHub App when you use GitHub integration.

3. Trust the proxy certificate

   If HTTPS is inspected, ensure the desktop and CLI trust your corporate root CA.

4. Verify each surface

   Test sign-in, a local agent run, and a cloud run from the same network segment.

Share the detailed domain list in the operator section below with your network team if they need an explicit allowlist.

Before you enable cloud agents

Use this checklist for a production repository:

• Only required repositories are allowed
• Network allowlist covers registries and APIs your setup commands need
• Secrets are in platform settings — none in prompts or committed files
• Budget policy and alerts are configured
• New automations are tested manually before going live
• Pull requests from cloud agents require human review before merge

For admins

Treat cloud agents like automation with code access:

1. Start strict — allowlist egress and repos; widen only when a smoke run proves a need.
2. Align with CI — if npm ci works in pipeline but fails in cloud, compare network and secrets.
3. Monitor — use Sentinel for failures and volume spikes.
4. Audit policy changes — model, budget, and network changes should be traceable to an owner.