Cursor Enterprise Service Accounts for API, CLI & Cloud Agents

A developer API key ties an automation to one person, so the automation breaks when that person changes roles or leaves. A service account is a non-human identity that the whole admin team can see and manage, and it differs from a personal key in four ways:

Compare a service account with the specific personal key that runs your automation today, often the key of whoever built it. That key is tied to one account, so the automation inherits whatever happens to that account. Each row above follows from moving that dependency to an identity the admin team can see.

Because a service account doesn't take a seat, an automation costs only the usage it consumes. That usage lands in the same analytics and billing as everyone else's work, so its cost sits next to the team's.

Creating one is a short dashboard flow, and the security work is in handling the key. Cursor shows the API key once, so copy it straight into your secrets manager.

1. 1Go to Dashboard → Settings → API Keys → Service Accounts (Enterprise admins).
2. 2Click New Service Account, enter a name (for example linear-ticket-agent) and an optional description, then click Create.
3. 3Copy the API key immediately. Cursor shows it once and can't show it again.
4. 4Store the key in your secrets manager. If you lose it, rotate it to get a new one.

The show-once key is the easiest part to mishandle, and usually in a small, human way: someone creates the account during a meeting and pastes the key into the chat so it doesn't get lost. Create the account when you can paste the key straight into the secrets manager.

Rotation invalidates the old key immediately, so every consumer has to be updated in the same window. That is manageable when one account serves one workflow and painful when one account has come to serve six. Cursor recommends separate accounts for different workflows, and the rotation window is a practical reason to follow that advice. Group consumers so you can update all of them in one sitting.

To pause an automation without losing its keys, suspend the account. Its keys stop working, and resuming the account restores them with no rotation.

Archiving is permanent for the keys: it revokes every key on the account but keeps the record, so the audit history stays under Show Archived. Anything still calling those keys breaks at that moment, so find out what uses an account before you archive it.

Service accounts can start cloud agent runs only on repositories authorized through the team-level Cursor GitHub app. A personal GitHub connection is not enough. Admins connect it under Dashboard → Settings → Integrations: connect the Cursor GitHub app to your organization, then authorize the repositories service accounts may use. Repository access follows the permissions on that installation, so GitHub decides the allowlist.

This failure wastes time because nothing flags it at setup; it shows up when a run starts. Your personal connection covers cloud agents you start yourself, so a run you trigger by hand can succeed while the same run from a service account fails. The difference looks like a flaky pipeline when it is a missing integration.

When a service account can't see a repository, check the team's GitHub app installation before anything in the Cursor dashboard.

Pass the API key as a Bearer token in the authorization header when you call the Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. API. For the CLI and headless jobs, set CURSOR_API_KEY in the environment, so pipelines authenticate without a browser login.

The CLI path pays off quickest. CURSOR_API_KEY in the environment is what makes agent -p --force "..." usable in CI, in cron and anywhere a browser login is impossible, and Cursor recommends it for those cases. The same variable works locally, so you can test a pipeline prompt before you commit it to a workflow file.

Settle two things before this reaches CI: which prompt the job runs, and what happens when the change it produces is wrong. A service account run is a real change from a real identity. The review gate matters more here than in an interactive session, where somebody is already reading the diff.

Give unattended jobs a spending ceiling too.

Admins can set a limit per service account for each billing period, and new accounts start with no limit. An account that reaches its limit gets a "Service account spend limit reached" error for the rest of the period, unless an admin raises or removes the limit. Spend limits never block BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. service accounts, because Bugbot bills through its own subscription.

Service accounts fit anything event-driven or scheduled that should run without a person in the loop. The common shape is a webhook or a cron job that starts a cloud agent run, as in these four patterns:

All four start a run on an event or a schedule, with nobody watching the terminal. That suits investigation and scoped fixes, and it gets riskier the more the agent is allowed to touch. Pick the first automation for how easy its output is to review.