As Cursor Cloud Agents become a core part of how engineering teams ship software—offloading tasks from Slack, GitHub, Linear, and the IDE itself—they're quietly becoming a significant point of credential exposure. Each agent boots a fresh Ubuntu VM, clones your repo, and starts running. If it needs to talk to a database, hit an internal API, or install a private package, it needs secrets. The question is: how do those secrets get there safely?
At Infisical, we've been thinking about this a lot. The patterns we're seeing in MCP servers and CI/CD pipelines are showing up in Cloud Agents too—hardcoded credentials, .env files committed alongside environment configs, and secrets baked into snapshots that outlive their usefulness. Here's a better way.
Quick Recap: How Cursor Cloud Agents Work
When you kick off a Cursor Cloud Agent task - whether from the IDE, Slack, or a GitHub webhook - Cursor spins up an isolated Ubuntu VM for that specific task. It restores from a snapshot, clones your repo at the relevant branch, and then runs your environment lifecycle in order:
install - runs once after the snapshot, gets cached. Think npm install or pip sync . start - runs on every boot, before the agent begins working. The right place to fetch secrets.
This lifecycle is configured in .cursor/environment.json at the root of your project. Cursor also has a Secrets UI (Settings → Background Agents → Secrets) that injects key-value pairs as encrypted environment variables at runtime.
The problem: the Secrets UI only goes so far. It works for a handful of static values, but it doesn't handle rotation, audit trails, access isolation between team members, or any of the other things you'd expect from a real secrets management workflow. As soon as your agent needs to do anything meaningful (like connect to a database, hit an internal service, install a private registry package), you're going to want something more robust.
The Challenge with Secrets in Cursor Agents
Cursor's cloud agent environment introduces a few specific problems that aren't always obvious:
Secrets baked into snapshots: If you run npm install with an .npmrc containing an auth token, and then snapshot the disk, that token is now frozen into the image. Hardcoded values in environment.json : This file is meant to be committed to your repo, so anything sensitive you put directly in the env field is a liability. No rotation or audit trail: The built-in Secrets UI stores values, but there's no visibility into when they were accessed, by which agent run, or whether they've been rotated recently. Long-lived credentials: A token you set in the Secrets UI six months ago is still the same token.
... continue reading