Cursor self-hosted machines: where a Sume API key can live

Cursor's self-hosted machines run agents on hosts you pick. Sume's key rule is short: trusted servers, CI secret stores or your own machine, never chat.

4 min readSume
All posts

Put a Sume API key where Sume's docs say keys belong: on trusted servers, in CI secret stores, or on local developer machines, exported as SUME_API_KEY. A self-hosted Cursor machine can be any of those, but the key should still stay out of prompts, chat history, screenshots and frontend code.

Cursor announced Self-hosted Machines on Sep 2, with My Machines and Team pools and providers including AWS Lambda, Coder, Cloudflare, Daytona, Modal, Namespace, Vercel and E2B (changelog read 2026-09-29). The changelog line does not describe secret handling, so use Cursor's documentation for where its secrets are configured; the Sume rules follow.

What does Sume say about where keys live?

Sume's Authentication page lists the safety rules. Use a server-side environment variable, export SUME_API_KEY="sume_live_...", and send it as Bearer auth or the API key header.

Sume API key placement rules, from the Authentication docs read 2026-09-29.
PlaceAllowed?
Trusted serverYes
CI secret storeYes
Local developer machineYes
Frontend JavaScript or a mobile appNo
Support tickets or screenshotsNo

Does a self-hosted machine count as trusted?

That is your call, and the docs give no list of hosts. Treat the sentence as a test: is this machine one you control, with secrets stored the way a CI secret store would hold them? A machine other people can read from is closer to a shared screen than a server.

The list of providers is wide, so the answer can differ between a personal machine and a team pool that several people can start agents on.

What about the MCP connection?

There are two credentials, and they are not interchangeable. An MCP OAuth token is not a Sume API key. Do not store OAuth tokens in CLI config, paste them into prompts, or forward them to third-party providers, and do not mint API keys for hosted OAuth clients as a workaround. API-key remote MCP remains available for automation that does not speak OAuth.

What if a key ends up in a log?

Rotate it. Create a replacement key, deploy it, verify GET /v1/me, then revoke the old key from the dashboard. Sume gives the same instruction for keys that appear in chat history. Also give agents read-only commands first and require explicit confirmation before write or paid generation commands.

How do I check a key works without printing it?

Send it from the environment variable, not from a pasted string. A request to GET /v1/me confirms the key authenticates and shows key metadata such as id, name, prefix, scopes and last-used time, but never the full secret.

Scopes are fixed when a key is created and cannot be added later, so if a machine's job needs a scope the key lacks, create a new key rather than editing the old one.

curl https://api.sume.com/v1/me \
  -H "Authorization: Bearer $SUME_API_KEY"

Sources

Related posts

More in Developers

All Developers posts

Written by Sume