Securing an MCP server means treating the tools it exposes as real access and constraining who — and what — can call them. An MCP server is not a read-only window. If it can post, delete, or spend, an agent with the wrong permissions can do all of that. The security model has three axes: the credential, the tool surface, and the autonomy granted to the agent.
What Is the Core Risk?
OWASP names it Excessive Agency: a system granted more functionality, permissions, or autonomy than the task requires. It arises from excessive tools, excessive permissions, or excessive autonomy — and it is triggered by hallucinations or prompt injection (OWASP).
In an MCP setting, Excessive Agency has a concrete shape. You connect an agent to a server with twenty tools, hand it a broad credential, and let it act without confirmation. Now a single manipulated input can chain into a real-world action.
What Is Prompt Injection, and Why Does It Matter?
Prompt injection is when an attacker embeds instructions in content the agent reads, hoping the model follows them. OpenAI's guidance for custom MCP servers is blunt: trusting the server's developer "does not make this safe" if the data the server can access contains malicious input.
The practical implication: the blast radius of an MCP server is bounded by the tools it exposes. A server that can read your inbox and post to social is a bigger target than one that can only read. Minimize the write surface.
What Are the Concrete Controls?
OWASP's prevention list maps cleanly onto MCP:
- Minimize extensions. Expose only the tools the task needs. Do not enable a fleet-control server for a read-only use case.
- Minimize functionality. Each tool should do one bounded thing, not accept open-ended input.
- Minimize permissions. Scope the credential. A key that can only touch its owner's accounts is far safer than a global one.
- Execute in the user's context. Actions should run as the authenticated user, with that user's limits.
- Require user approval. Human confirmation before high-impact actions such as posting.
- Complete mediation. Authorize in the server, not in the prompt. Never trust the model to decide what is allowed.
- Log and rate-limit. Monitoring and throttling limit damage when something goes wrong.
The through-line: authorization belongs in the server, not in the instructions given to the model.
How Do You Handle Credentials?
API keys are the common case, and they are only as safe as their scope and lifecycle. The rules:
- One key per integration. Revoke independently.
- Least privilege. Reject broad default keys.
- Never commit. Configs with live keys go in
.gitignoreor reference environment variables. - Rotate on exposure. A key in a log, screenshot, or repo is compromised.
The data backs up the discipline. GitGuardian's 2025 State of Secrets Sprawl counted 23,770,171 new hardcoded secrets in public GitHub repositories in 2024, a 25% increase, and found that public repositories using GitHub Copilot had a 6.4% secret leakage rate (GitGuardian). AI-assisted work and secret sprawl are growing together.
Remote servers add a transport consideration. Cloudflare notes that when a server acts on a user's behalf, it should issue its own scoped token rather than forward an upstream credential — so a compromised client token exposes only the tools you granted, not the underlying account (Cloudflare).
What Should You Check Before Connecting?
Cursor's security guidance is a good checklist for any MCP server: verify the source, review permissions, limit API keys, and audit code for critical integrations. Add one more: know whether the server exposes write actions. If it does, keep approval on.
How Conbersa Handles MCP Security
Conbersa's MCP server authenticates every request with a per-user API key and enforces ownership per tool — a non-admin key only sees its own devices and sessions. There is no unauthenticated mode, content tools are marked experimental, and live video is not streamed through MCP. See API keys and MCP API key authentication.