Quick answer: Instead of putting raw API keys in your .env or Cursor config, connect your services to Gazebo once, create a Cursor access profile with exactly the services it needs, and paste one MCP endpoint URL into Cursor settings. Your agent retrieves credentials on demand — scoped, logged, and revocable.
Why not just put API keys in the .env file?
The .env file approach works for a single developer with a single agent, but it breaks down quickly. Raw API keys in .env grant full account access — Cursor can do anything your Stripe key allows. There's no audit trail of what the agent actually called. And when you add another agent, or another developer, the credential management becomes a spreadsheet problem.
Step 1 — Connect your services to Gazebo
Sign in to Gazebo and navigate to Services. Connect the services your Cursor agent uses: Stripe, GitHub, Vercel, Cloudflare, Supabase — whatever your project needs. Each service is connected once and stored encrypted in Gazebo's vault.
Step 2 — Create a Cursor access profile
In Gazebo, go to Agents → New. Name the profile after your Cursor agent (e.g. cursor-work or cursor-project-name). Select the services it's allowed to access — only the ones it actually needs for the current project. Gazebo generates an MCP endpoint URL and a bearer token.
Step 3 — Add the MCP server to Cursor
Open Cursor Settings → MCP. Add a new MCP server with the endpoint URL and bearer token from your Gazebo access profile. That's the only configuration change needed — no raw API keys in your config, no .env modifications.
Step 4 — Use get_credential in your agent workflows
When your Cursor agent needs a service credential, it calls get_credential via MCP. Gazebo validates the access profile, logs the retrieval, and returns the scoped credential. The raw key goes directly to the tool response — in Cursor's current implementation, tool responses are handled separately from the conversation transcript.
What the agent actually sees
When Cursor calls get_credential, the tool response contains the credential for that specific service. In Cursor's current implementation, tool responses are handled at a layer separate from the user-visible conversation text — the credential is used to construct API calls rather than being displayed in the chat interface. This reduces the risk of a credential appearing in an export, a screenshot, or a session that gets synced across devices, compared to pasting a key directly into a prompt or system instruction.
Verify Cursor's current session logging and tool response handling against their documentation, as behavior may evolve across versions.
Setting up for a team
Individual access profiles are the right model even for teams. When multiple developers work on the same project:
- Create one Gazebo access profile per developer per project context — not one shared profile for the whole team
- Name them specifically:
cursor-alice-billing,cursor-bob-billing, not justcursor-billing - Each developer adds their own MCP token to their Cursor settings — the endpoint URL is the same, the bearer token is unique per profile
Why individual profiles rather than a shared one? Because when something unexpected happens — an API call you didn't expect, a billing anomaly, access to a resource outside the task scope — you need to know which developer's Cursor session was involved. A shared profile makes that impossible.
Individual profiles also let you revoke selectively. If a developer leaves the team or rotates off a project, you revoke their profile without affecting anyone else's active sessions.
Switching between projects quickly
Cursor lets you define multiple MCP server configurations. One practical approach: define a separate entry for each project context rather than swapping a single entry.
{
"mcpServers": {
"gazebo-project-a": {
"url": "https://app.gazebohq.com/api/mcp",
"headers": { "Authorization": "Bearer ag_project_a_token" }
},
"gazebo-project-b": {
"url": "https://app.gazebohq.com/api/mcp",
"headers": { "Authorization": "Bearer ag_project_b_token" }
}
}
}
You can instruct Cursor at the start of a session — "use the gazebo-project-a profile for credentials" — or scope each profile so narrowly that only the relevant services are accessible, and Cursor naturally routes to the right one.
Troubleshooting common issues
Cursor shows "MCP server disconnected." Check the endpoint URL and bearer token. The most common cause is a typo in the URL or using the wrong endpoint format. Copy the URL directly from the Gazebo agent profile page rather than typing it manually.
get_credential returns "permission denied" for a service you've connected. The access profile may not include that service. Open the profile in Gazebo, confirm the service is listed under allowed services, and save. Changes take effect immediately — no need to restart Cursor.
The agent reads credentials from the environment instead of calling get_credential.
If STRIPE_SECRET_KEY or another service key is still in your shell session or .env file, Cursor will read it directly — bypassing the MCP layer entirely. Remove raw service credentials from the environment for sessions where you're using the MCP profile. The credentials live in Gazebo's vault; the agent should fetch them through get_credential.
Audit log shows no entries after running a task. Confirm that the agent is actually calling get_credential and not reading from the environment. Run a test task that requires a credential and check the access log in Gazebo. If nothing appears, the agent found the raw key elsewhere and the environment cleanup from the step above applies.
How do you scope access for different projects?
Create a separate Gazebo access profile for each project your Cursor agent works on. Profile A has Stripe + Vercel access for Project A. Profile B has GitHub + Supabase access for Project B. Swap the MCP endpoint in Cursor settings when you switch projects, or run multiple Cursor instances with different profiles.
What happens when you revoke the profile?
Deleting a Gazebo access profile immediately revokes the agent's access. The next time Cursor calls get_credential, it receives a permission denied response. Your underlying service credentials — Stripe keys, GitHub tokens — are unchanged and unaffected.
What good naming looks like
Profile names appear in the audit log, so they should be readable in context. A log entry that says "cursor-alice-billing requested Stripe at 14:32" is useful. One that says "agent-1 requested Stripe at 14:32" is not.
Good naming conventions:
cursor-[developer]-[project]for developer-specific profilescursor-[project]-[environment]for environment-scoped profiles (staging vs. production access)cursor-[task]for task-specific profiles created and revoked with the task
The profile name is also how you identify which session caused an unexpected action. Name it like a git branch — specific enough to be useful after the fact.
Investigating unexpected API calls
One of the practical benefits of the MCP model over .env credentials is that you have a record of what actually happened. When you see an unexpected charge in Stripe, an unexpected commit in GitHub, or a Vercel deployment you didn't trigger, the Gazebo access log gives you a starting point.
Every get_credential call is logged with:
- Which agent identity made the request (the profile name)
- Which service was requested
- The timestamp of the request
- Whether the request was permitted or denied
Cross-referencing the access log with your Stripe, GitHub, or Vercel activity log lets you reconstruct which agent was active at the time of the unexpected event. That's usually enough to narrow down which session or task triggered it.
If the access log shows a request to a service outside the agent's intended scope — a Stripe call from a profile that was only supposed to need GitHub — that's a signal worth investigating: either the profile scope is broader than intended, or the agent was prompted to do something unexpected.
How to audit your Cursor setup periodically
Treat your active Cursor profiles the way you'd treat open browser sessions: review them periodically and close the ones you're not using. A monthly pass through your Gazebo profiles takes a few minutes and keeps the access surface clean.
Questions worth asking:
- Which profiles haven't made a credential request in the last 30 days? Those can probably be deactivated.
- Are any profiles scoped more broadly than the current project requires? Narrow them.
- Are there projects you've finished that still have active profiles? Revoke them.
The goal isn't perfect hygiene on every profile at all times — it's a habit of regular review that catches the common drift: profiles created for a task that got broader over time, or profiles for projects that wrapped up months ago and were never cleaned up.
For a more complete treatment of the identity model this setup is built on, see IAM for AI agents. For how the same pattern applies to Claude Code and n8n, see Claude Code API security and n8n AI agent credentials.
For the broader security model behind this pattern — why per-agent identity matters for audit trails, revocation, and compliance — see zero trust for AI agents and AI agent permissions.
See Gazebo's security overview for how credentials are encrypted and stored, and the agents page to create your first access profile.
Last reviewed: August 2026. Independent editorial — not affiliated with or endorsed by Cursor (Anysphere). Cursor moves quickly — verify against Cursor's current documentation for the latest on tool configuration and session behavior.