Agencies run infrastructure for a lot of clients: WordPress sites, online stores, staging servers, and the production server that has to stay up during a launch. For years only people touched those servers, and the SSH keys lived in a password manager.
This post is for agencies and developers who manage servers for clients and are about to connect an AI client such as Claude, ChatGPT or GitHub Copilot to that infrastructure.
MCP Authentication: API Keys or Scoped OAuth?
There are two common ways to give an AI client access to a hosting account. Both work, but they carry different risks, and the difference matters more once the client can act on its own.
Pasted API key
You create a token in the hosting dashboard and add it to the AI client's config. The client can do everything the token can do until someone rotates it. If the token can delete a server, so can the AI client.
OAuth with scoped permissions
- You sign in to your host in your own browser
- You approve the permissions this connection gets
- Start read-only, add write access when a task needs it
- Reconnect to change what you granted
- No password or general-purpose token in the AI client's config
API keys still make sense for fixed scripts and CI jobs, where the code that uses the key is reviewed before it runs. An AI client is different: it decides at runtime which actions to take, so the permission boundary ends up doing more of the safety work. That is also why the MCP specification has based authorization for remote servers on OAuth 2.1 with PKCE since its March 2025 version.
What Has Changed in MCP Security?
Security practice for MCP servers is still developing, and the figures below show where gaps have been reported. Trend Micro reported 1,467 MCP servers exposed to the internet in April 2026, nearly three times the 492 it found in July 2025.
Vulnerability reports rose with it. Between January and February 2026, 30 CVEs were filed against MCP software, from individual MCP servers to the official MCP TypeScript SDK. A widely reported earlier flaw, CVE-2025-6514 (CVSS 9.6), let a malicious MCP server run OS commands on the connecting machine through mcp-remote, a package downloaded more than 437,000 times, until version 0.1.16 fixed it.
Another analysis, by BlueRock, looked at more than 7,000 MCP servers and found that around 36.7% of them might be exposed to server-side request forgery (SSRF), a flaw that can let an attacker reach internal systems through the server.
Readiness is lagging too. In Cisco's State of AI Security 2026 report, 83% of enterprises planned to deploy agentic AI capabilities in 2025, but only 29% reported feeling prepared to do so securely.
None of this is an argument against MCP. It is a sound way to connect an AI client to your servers, but the setup that is quickest to configure is not always the one that gives you the most control, so it is worth spending a few extra minutes on scoped, read-only access first.
Why Broad Access Costs Agencies More
When you manage servers for clients, over-broad access tends to cost more, for three reasons.
Prompt Injection
General Analysis reported on 8 July 2025 that an instruction hidden in a support ticket led an AI client to leak private data through the Supabase MCP. If the AI client has write access it never needed, an instruction like that can turn into a real action, such as a resize or a deletion.
One Key, Many Clients
A single all-access token puts every client's servers behind one credential, so if it leaks, every client is exposed instead of one.
Ambiguous Goals
"Create a WordPress server" can mean managed WordPress tooling or a raw VPS with a manual install. Both readings are valid, and an AI client with write access may pick the one you did not intend, with the server billed either way.
Neither risk depends on a malicious model. Both come from access that is broader than the task needs, or from a goal that leaves room for interpretation, and both can be reduced with scoped access and specific prompts.
Scope the Access, Then Be Specific
Scope the access. Start read-only for inventory and troubleshooting, since a question like "which of my servers look unusual?" does not need write access. Add permissions to create, resize or snapshot when a task needs them, and reconnect to remove them afterwards. Taking a snapshot also needs a permission that allows changes. If a host only offers one key with full access, that is a trade-off worth weighing before you connect client servers.
Be specific in the prompt. The plan an AI client makes depends on the goal it gets, so a few extra words up front save a correction later. These lines narrow it down:
Provisioning and snapshots run in the background, so an accepted request is not the same as a finished one, and an AI client that moves on too early can start the next step while a job is still running. A snapshot gives you a fast rollback point. It does not replace your backup strategy, but it can turn a bad change into a short fix.
How Webdock MCP Handles Access
Webdock MCP is a remote MCP server built on the OAuth model described above, so the permissions you approve at sign-in set the limit of what the AI client can do.
OAuth Sign-in
You sign in to Webdock in your browser. No password or general-purpose API token goes into the AI client.
Your Permissions
You approve what the connection may do, from read-only to full server management. Reconnect to change it.
Price First
Profiles, locations and monthly prices are readable, so you can ask for the price before anything billable.
Setup steps live in the Webdock MCP guides, including the Claude setup guide.
Eight Checks Before You Connect a Client Server
- 1Read-only first. Use read-only access for inventory and troubleshooting, and add write permissions per task.
- 2No shared all-access tokens. Avoid one token that reaches every client's servers.
- 3Scope per job. Grant what the task needs, for example create access for provisioning, and nothing broader.
- 4Name the server. For risky changes, say which server to touch: "Only change client-production-server. Do not modify any other server."
- 5Price before provisioning. Ask for the profile and monthly price before anything billable.
- 6Snapshot before risky changes. Especially on client production servers.
- 7One step at a time. Ask the AI client to wait for each operation to finish.
- 8Verify after. Ask it to re-read the server state and confirm the change took effect.
Most of these checks are one choice at sign-in or one line in a prompt, so they add little time. The useful part is deciding on them before a launch or an incident, not during one.
What the Setup Decides
Broad access lets an AI client work across all client servers with less setup. Scoped, read-only OAuth access limits what any single session can change and makes mistakes easier to review and reverse, at the cost of granting write access per task when it is needed.
Frequently Asked Questions
For an AI client, scoped OAuth is the safer default: you approve specific permissions in the browser and can reconnect to change them. API keys fit fixed scripts better, where the code using the key is reviewed in advance.
Yes, with Webdock MCP you approve permissions during sign-in, so a connection can stay read-only until a task needs more.
No, creating a snapshot needs a permission that allows changes. Reconnect and grant it when the task needs it.
No, a snapshot is a recovery point for fast rollback. Keep a separate backup strategy alongside it.
Webdock MCP is included with your Webdock account. You only pay for the servers you run, at normal Webdock prices.