Cursor Enterprise Service Accounts for API, CLI & Cloud Agents

A developer API key ties an automation to one person. When that person changes roles or leaves, the automation breaks. A service account is a non-human identity that the whole admin team can see and rotate, and it bills from the team pool without taking a seat. Four reasons to prefer one:

• Survives org changes: automations keep running when people rotate roles.
• Central credential control: rotate API keys without tying them to one engineer's account.
• Audit trail: cloud agent runs initiated by service accounts appear to all admins.
• No seat license: included with Enterprise; usage bills like any other member.

The comparison worth making is not service account against personal key in the abstract. It is against the specific personal key running your automation today, which usually belongs to whoever built it. That key is tied to one account, so the automation inherits whatever happens to that account, and the rest of the list above follows from moving that dependency somewhere the admin team can see it.

Service accounts do not consume a seat, which is the detail people expect to go the other way. They are included with Enterprise and draw usage from the team pool like any member, so an automation shows up as usage rather than as a licence line, and it lands in the same analytics as everybody else's work.

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

1. 1Go to Dashboard → Settings → Service Accounts (Enterprise admin).
2. 2Click New Service Account, name it (for example linear-ticket-agent) and add a description.
3. 3Copy the API key immediately; Cursor shows it once.
4. 4Store the key in your secrets manager; rotate from the dashboard if compromised.

That single-view key is the part people mishandle, usually in a small and human way: somebody creates the account during a meeting and pastes the key into the chat so it does not get lost. Create it from the machine that will store it, put it straight into the secrets manager, and treat rotation as the recovery path when it goes missing anyway.

Rotation invalidates the old key immediately, so every consumer has to be updated inside the same window. That is manageable when one account serves one workflow and unpleasant when one account has quietly come to serve six. Separate accounts per workflow reads like housekeeping advice; it is really a decision about that window, so group by the set of consumers you can update in one sitting.

Archiving is the other end of the lifecycle, and it is not a delete. It revokes every key on the account and keeps the record, so the audit history stays intact and Show Archived is where a retired automation goes on being explainable. Anything still calling those keys breaks at that moment, which is the reason to find out what consumes an account before you archive it and not after.

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 under Dashboard → Settings → Integrations, install the app on the org and select allowed repositories.

This is probably the failure that wastes the most time, because it arrives at run time rather than at setup. Your personal connection covers cloud agents you start yourself, so a run you trigger by hand can succeed while the identical run from a service account fails, and the difference looks like a flaky pipeline rather than a missing integration.

Repository access follows the permissions on the team's GitHub app installation, which means the allowlist is decided in GitHub and not in Cursor. When a service account cannot see a repository, look there before anything in the dashboard.

Pass the API key as a Bearer token to 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 CLI and headless jobs, set CURSOR_API_KEY in the environment so pipelines authenticate without browser login. Usage appears in team analytics and billing like human members.

The CLI path is the one that 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 the same variable works locally, which is handy for testing 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, so the review gate matters more here than in an interactive session where somebody is already reading the diff.

Service accounts fit anything event-driven or scheduled that should run without a person in the loop. The common shape is a webhook or cron that kicks off a cloud agent run. Four patterns teams reach for:

Those four share a shape: something happens, a run starts, and nobody is watching the terminal. That shape suits investigation and scoped fixes, and it gets uncomfortable in proportion to how much the agent is allowed to touch, so pick the first automation for how easily you can review its output rather than for how impressive it sounds in a demo.

Name the account after the system it serves rather than the person who built it. Six months on, sentry-remediation explains itself in a log line and test-account-2 needs somebody who remembers 2026.