Scoped MCP credentials for Windsurf agents
Windsurf is an agentic IDE built for multi-step coding flows. An agent can traverse a codebase, edit files, run commands, and work through a sequence that spans source control, deployment, diagnostics, and third-party APIs. Long chains are valuable precisely because one seemingly harmless instruction can lead to later actions with broader consequences. Repository text, terminal output, generated configuration, and issue descriptions may all influence a tool-using agent. Establish boundaries before the flow starts: define the repository and environment, decide which actions require review, and give each external service its own least-privilege credential instead of relying on a developer's ambient workstation access.
Why does Windsurf need IAM?
A sustained Windsurf workflow can combine code changes with real service operations. A broad Cloudflare token might cover every zone, a GitHub token every repository, or a Vercel token multiple projects, while the task may require only one cache purge, branch, or deployment. That mismatch creates blast radius and makes it difficult to separate an intended workflow from an accidental or prompt-influenced one. Gazebo bounds credential retrieval to a Windsurf profile, so the agent has a distinct service identity rather than inheriting all credentials present on the machine. The retrieval audit trail supports investigation and profile revocation stops future retrieval for that workflow. It does not replace provider audit logs, confirmation before destructive operations, change review, or environment-specific credentials; use those controls together.
How Gazebo works with Windsurf
- 1
Connect only the services the flow needs and first constrain credentials at the provider: select a repository, Vercel project, Cloudflare zone, or non-production account rather than an unrestricted organisation credential.
- 2
Create a Windsurf access profile for the workflow, repository, and environment. Keep a diagnostic profile read-only where possible and create a separate, short-lived deployment profile only after the change is ready.
- 3
Add Gazebo's MCP endpoint to Windsurf's MCP configuration. Keep the bearer token out of committed project settings and avoid shell exports that make unrelated secrets available to terminal commands.
- 4
Windsurf requests a credential with get_credential when a configured tool needs one. Gazebo validates the profile and records the retrieval, making service access explicit rather than implicit in the IDE environment.
- 5
Review access records with commits, CI output, deployment events, and the agent's plan. Revoke the profile at the end of the workflow or immediately when instructions, scope, or expected behavior change; reissue narrower access for any follow-up.
What this looks like in practice
Multi-step deployments with scoped access
Split a release sequence into bounded service permissions: repository access for the intended branch, deployment access for the target project, and a zone-limited credential if a cache operation is necessary. Review the planned diff and deployment target before enabling the write-capable profile. A cache purge or production deployment should not be an incidental side effect of a broad token.
Audit complex agent workflows
For a long-running flow, retain the task definition, agent plan, code changes, CI records, provider audit events, and Gazebo credential-retrieval history. Together these sources distinguish the request for a credential from the action performed with it and make an overnight change easier to review or investigate.
Instant revocation for shared environments
Assign separate profiles to people, projects, or automation runs instead of distributing one shared service secret. If a laptop, task, or session needs containment, revoke that profile without interrupting other developers. Revisit profiles during role changes and remove integrations that are no longer part of the workflow.
Constrain diagnostic tooling
A debugging flow often needs logs or status information, not the ability to alter live configuration. Create a read-only profile for diagnosis and keep credentials capable of changing DNS, environment variables, or deployment settings in a separately approved workflow. This lets Windsurf investigate a failure without making a command suggested by a log line or repository document an immediate production change.
Set up Gazebo for Windsurf
Connect your services once. Your Windsurf agent gets exactly the access it needs — nothing more.
Get started freeServices Windsurf commonly connects to
Further reading
Zero Trust for AI Agents: What It Means and How to Apply It
Zero trust means every credential request is verified, scoped, and logged — regardless of where the agent runs. Here's what the four core primitives look like in practice.
1Password for AI Agents and Gazebo: Two Credential Layers, How They Fit Together
1Password for Claude handles web login credentials for browsing agents. Gazebo handles programmatic API credentials for coding agents. They solve different layers of the same problem and can run together.
Why Environment Variables Are Insecure for AI Agents
Environment variables feel like a secure way to pass credentials to AI agents. They're not. Here's why the process environment is a shared bus, not a secrets store — and what to do instead.
MCP Security: What Developers Need to Know
MCP expands your agent's surface area. Every tool exposed over MCP is a potential credential leak or injection vector — unless you scope access at the agent level.
API Key Rotation vs. Revocation: Why Agents Need the Latter
Rotation replaces a key everywhere it's used. Revocation cuts one agent's access without touching anything else. Why revocation is the right default for agents — and what you need in place.
RBAC for AI Agents: Does Role-Based Access Control Work?
RBAC works for agents — but only if you drop the assumption that makes it useful for humans. Here's what breaks, what to use instead, and how HashiCorp Vault's policy model fits in.