Cloud agents and sandboxes

Every cloud environment falls into one of three groups. Work down this list and stop at the first row your platform supports:

• Your platform mints a verifiable OIDC identity token (Fly.io, Modal, Amp, Cursor cloud agents, E2B workload identity, Copilot via GitHub Actions OIDC): federate it. An Organization Admin adds an OIDC access rule — issuer, audience, and the platform-assigned tenant claim — and every workload exchanges its identity for a short-lived Token. No secret is stored anywhere.
• Your platform injects credentials at its egress proxy (Cloudflare Sandboxes, Daytona, Blaxel, Vercel Sandbox, E2B transforms): mint a short-lived Token from your backend and hand it to the proxy rule. The workload never sees it.
• Everything else: put a Token in the platform's secret or environment-variable store and write configuration that references it. This works on every platform we surveyed.

This shape works everywhere because it relies only on the two things every platform provides: environment variables and a setup phase. The committed configuration references MAZE_TOKEN; the value lives in your platform's secret store.

The per-client recipes are the same ones as on Set up npm and pnpm and Set up pip, uv, and Poetry. Two rules matter more in cloud environments than anywhere else:

• Never persist a credential where a snapshot outlives it. Most platforms snapshot the environment after setup and reuse it — for hours or days. Config that references an environment variable is safe; a token pasted into .npmrc travels into every reused environment.
• Scope credentials by Feed URL, never by hostname. Every Feed shares pkg.packagemaze.com, so a host-wide credential silently becomes the default for a restricted sibling Feed. The recipes above are already URL-scoped.

If your platform mints OIDC identity tokens, no PackageMaze secret needs to exist at all. An Organization Admin configures an access rule with the platform's issuer URL and at least one exact match on a platform-assigned tenant claim (a project, workspace, or team ID copied from the platform's dashboard — never a name you chose, and never an email). The workload then exchanges its identity token:

curl -sS https://api.packagemaze.com/v1/auth/workload-token \
  -H 'Content-Type: application/json' \
  -d '{
    "provider": "oidc",
    "feed": "<organization>/<feed>",
    "purpose": "install",
    "audience": "https://api.packagemaze.com",
    "oidc_token": "'"$PLATFORM_ID_TOKEN"'"
  }'

The response contains a short-lived Token scoped to the one Feed and purpose the rule allows; wire it into the client exactly like MAZE_TOKEN above. Platforms that inject headers at their egress proxy can attach the identity token to the exchange request itself as Authorization: Bearer — the identity token is then never readable inside the workload. The first exchange from a not-yet-configured platform records a proposal an Admin can approve with the observed identity, so nobody hand-copies IDs.

For platforms that inject credentials at an egress proxy — and for any setup where you would rather hand out per-run Tokens than store a durable one — your backend can mint them on demand. Create an Autonomous Agent in Organization Settings, keep its credential on your backend (never inside a workload), and call:

curl -sS https://api.packagemaze.com/v1/auth/ephemeral-token \
  -H 'Content-Type: application/json' \
  -H "Authorization: Bearer $MAZE_AGENT_CREDENTIAL" \
  -d '{
    "access": "read",
    "feeds": ["<organization>/<feed>"],
    "ttl_seconds": 900,
    "run_id": "<your run or session id>"
  }'

The response's token is an ordinary Feed-scoped Token that expires after ttl_seconds (60–3600, default 900): hand it to the platform's proxy rule or secret store like MAZE_TOKEN above. What a mint can do is capped by the Agent itself — access is read or read_publish (the latter only from an Agent granted read and publish), and every Feed must be in the Agent's own Feed selection. The optional run_id lands in the Token's name, so activity views attribute installs to the run that performed them. Minted Tokens never appear in your durable credential list; they expire instead of accumulating.

If your platform restricts outbound traffic, allow exactly one host:

pkg.packagemaze.com

Every package-client request — metadata and artifact bytes — stays on your Feed Base URL's host. PackageMaze never redirects a package client to a storage or CDN domain, so the one entry is the entire network story. Add the exact host, not a wildcard: a broad wildcard reopens egress an agent could misuse. If your workload also exchanges OIDC identity or talks to the API, allow api.packagemaze.com too.

Several platforms re-terminate HTTPS at a proxy with an injected certificate authority (Claude Code on the web always; Cloudflare Sandboxes by default; Vercel Sandbox for transformed domains). The platform pre-trusts its CA in the system store and usually sets the standard CA environment variables (NODE_EXTRA_CA_CERTS, PIP_CERT, SSL_CERT_FILE). Two rules keep that working:

• Never set cafile in .npmrc or cert in pip config. Client config silently overrides the platform's CA environment variables and breaks TLS with errors that look like PackageMaze failures.
• PackageMaze never asks you to pin certificates, so the platform's proxy CA works as long as the system trust store is used.

Short, current-as-of-August-2026 notes on the wrinkle each platform adds to the universal pattern. Always check your platform's own documentation for the mechanism's current state.

• Claude Code on the web: no dedicated secrets store yet — anyone using the environment can read its variables, so prefer a short-lived Token and a tight Feed scope. Add your Feed host under Custom network access. All traffic crosses its TLS-intercepting proxy; the CA rules above apply.
• OpenAI Codex (cloud): secrets are removed before the agent phase — only environment variables survive into it. Put the Token in an environment variable (or write the config file during setup) if the agent must install mid-task, and add your Feed host to the domain allowlist for the agent phase.
• GitHub Copilot coding agent: use an "Agents" secret (repository or organization level) — Actions secrets are not passed. Setup steps bypass its firewall; agent-phase installs need the allowlist entry, which can be a path-scoped URL. The environment is a GitHub Actions job, so your existing GitHub Actions OIDC access works in setup steps with id-token: write.
• Cursor cloud agents: use a Runtime Secret (it is redacted from transcripts) or mint an OIDC identity token from the local agent socket and federate — both work in install scripts and the agent phase. Allowlist entries are exact hosts.
• Devin: write registry configuration in the maintenance blueprint phase, not initialize — secrets are scrubbed from snapshots, so credentials written during initialize are gone when a session starts.
• Amp: commit the setup to .agents/setup, keep the Token in Amp's secrets, and remember the post-setup snapshot can be reused for new Orbs — or skip secrets entirely and federate amp orb id-token.
• Google Jules: repository-level environment variables are enabled per task at task start; the universal pattern applies unchanged.
• E2B: the universal pattern works today (write config at runtime or in a template build; note build-time setEnvs values appear in build logs — use a short-lived Token there). E2B's workload identity and per-host header transforms are in private beta; once enabled for your team they federate with an OIDC access rule, with the identity token injected at E2B's proxy.
• Modal: attach a Modal Secret carrying the Token, or federate MODAL_IDENTITY_TOKEN — note Modal's audience is fixed, so the access rule carries a standing warning and strict tenant matchers matter.
• Fly.io Machines: federate — a Machine pulls its own identity token from the local socket with your chosen audience; or use Fly secrets with the universal pattern.
• Vercel Sandbox: use the firewall's header transform to inject a short-lived Token toward your Feed host, or the universal pattern; snapshots persist config across sessions, so keep secrets in environment variables only.
• Cloudflare Sandboxes: hold the Token in the Worker and inject it with an outbound handler — Cloudflare's own guidance is to keep credentials out of the sandbox. HTTPS is intercepted by default; containers inside the sandbox do not inherit the CA.
• Daytona: store the Token as a Daytona secret and let the outbound proxy substitute the placeholder — substitution works only in HTTPS request headers, so store Basic credentials pre-encoded. Lower tiers cannot open custom egress holes.
• Blaxel: use {{SECRET:…}} proxy injection toward your Feed host, or .env.build for build-phase installs.

• All package-client traffic for a Feed stays on the Feed Base URL host — no redirects to storage or CDN domains, ever.
• Both Authorization: Bearer and Basic credentials work on every protocol route, so npm's native auth, pip's URL-embedded credentials, and proxy-injected headers all compose.
• Response caching never keys on your credential, so short-lived per-run Tokens do not cost you cache hits.
• No certificate pinning, so TLS-intercepting platform proxies work with the system trust store.