MCP server security: the config nobody reads

An engineer adds a browser server to an agent's MCP config. The block names a command, a package, and an API key. The agent can now open pages, click controls, and return results. Setup took minutes. The security review never started.

Now make the situation slightly less comfortable. The server update is compromised, its tool description changes, or the browser connector attaches to the engineer's daily profile. The agent still sees an ordinary tool. That tool may now carry active cookies, account access, and the authority of every credential placed in its config.

Nothing in the protocol answers the real question: is MCP safe for this task? MCP standardizes how tools connect. It does not certify the server, narrow its permissions, or decide which identity the tool should carry. Those decisions live in source code, client config, credential scope, and the execution environment.

Everyone installed MCP servers. Almost nobody threat-modeled them.

MCP made integrations reusable. A server can declare tools, describe their purpose, accept structured calls, and return results to a model. That removed custom integration work. It also moved critical security decisions into a small config block that often looks like setup glue.

The trust boundary is larger than the server process. It includes whoever publishes the package, every dependency it loads, the descriptions shown to the model, the credentials passed by the client, the network destinations the process can reach, and the systems behind each tool. A review that stops at the server name misses most of that boundary.

A 2026 practitioner overview groups prompt injection, MCP-layer risk, and data leakage as central agent-security concerns. The categories compound. Untrusted content can steer a model, an MCP tool can provide authority, and an output channel can move the result elsewhere.

The useful review question is not whether MCP is safe in general. Ask what this server can cause, which identity pays the cost, and what survives after the task ends. That framing turns a vague platform debate into a concrete threat model.

The five risk classes

These risks do not require a novel exploit. They follow from the way agents choose tools, carry authority, and execute third-party code. Review each class before a server joins a production workflow.

Tool poisoning: descriptions are control input

A model relies on tool names, descriptions, and parameter guidance to decide what to call. That metadata is therefore part of the agent's control plane. A malicious server can write descriptions that steer the model toward unnecessary calls. A compromised update can change trusted wording after the original review.

Treat description changes like permission changes. Review the exact text, compare releases, and pin the server version where the client allows it. A tool claiming to read a page should not quietly describe unrelated write actions, credential access, or broad network reach.

The companion guide covers indirect prompt injection in browser agents; this threat model stays on what MCP lets the model call next.

Confused deputy: valid authority, wrong task

An agent can hold valid credentials while acting for the wrong reason. That is the confused-deputy problem. The user requests a read-only task, but the agent also has tools that send messages, change records, upload files, or approve charges. The credentials work. The task never justified their use.

Separate read paths from write paths. Use different credentials when the systems support them. Put human approval in front of state changes. Most importantly, do not let a convenient all-purpose agent become the deputy for every system its operator can access.

Credential sprawl: config files become secret stores

MCP client configs commonly pass secrets through an environment block. That is better than hardcoding a key into application source, but the config still becomes sensitive. Copy the same server into several clients and the same credential may spread across home directories, project folders, backups, support bundles, and screenshots.

Give each server a dedicated credential. Scope it to the smallest resource set. Keep secrets out of source control. Record where each copy lives, rotate it on a defined schedule, and revoke it when the client or workflow disappears. A forgotten config is still an active credential path.

Over-broad scopes: every tool expands the blast radius

A server may expose more tools than one workflow needs. A broad token can turn those tools into real authority. The model then has to choose correctly across a capability set that should never have been available for the task.

Start from no access. Allow only the tools the job requires. Prefer read-only operations. Split sensitive write tools into a separate server or approval path. Least privilege is not a note in the system prompt. It must be enforced by the credentials and runtime around the model.

Supply-chain risk: the server is executable code

A copied config can invoke a package runner, fetch a server, and hand it credentials in one block. That convenience hides a software supply chain. The publisher, package registry, release process, transitive dependencies, and update path all sit inside the trust decision.

Prefer a server from a vendor you can identify or source you can inspect. Verify the package name and distribution channel. Review what the process reads, writes, and contacts. Pin reviewed versions when possible, then repeat the review before upgrades. Community adoption is not a security assessment.

The browser tool special case

Browser tools carry a form of authority that config reviews often miss. The authority lives in session state. If an MCP browser tool drives your real browser profile, it inherits the cookies and identity already present there. The model may be one navigation away from an authenticated inbox, an internal dashboard, or a billing portal.

Consider a hypothetical research task. The agent opens an unknown vendor page in the operator's normal browser. That page influences the agent's next action, and the browser already holds an active admin session in another tab. The risk is not only what the page can render. It is what the connected browser can reach as the operator.

The distinction changes the blast radius. A disposable session still reaches the real web, but it begins without the operator's history, cookies, or active logins. If a task goes wrong, there is less inherited authority to misuse and less residue to survive.

That is the security value of a browser exposed through MCP as an isolated session rather than a remote control for your daily profile. The useful capability remains. The durable identity does not come along for the ride.

A practical checklist before you add a server

Do this review before the first production task. Retrofitting boundaries gets harder once configs, credentials, and workflows spread across a team.

1. Read the source or identify the vendor. Confirm who maintains the server, where releases come from, which dependencies run, and what network destinations it contacts. If you cannot inspect the code, require a vendor and update path you can hold accountable.
2. Scope every credential. Create a dedicated key for the server. Limit it to the required account, resource, actions, and environment. Do not reuse a personal token that reaches unrelated systems.
3. Build least-privilege configs. Enable only required tools. Prefer read-only access, separate write actions, and require approval for messages, uploads, purchases, deletions, and record changes.
4. Isolate execution surfaces. Run untrusted servers away from the operator's workstation and daily browser profile. Limit filesystem and network reach. Put browser work in a fresh session with no inherited identity.
5. Log tool calls outside the agent. Capture the tool name, request, result, acting identity, and task context in a system the agent cannot rewrite. Review unexpected calls and permission failures as security signals.

Apply the same checklist to internal servers. Familiar code can still carry excessive scopes, stale secrets, and unsafe defaults. Ownership makes a server easier to fix. It does not remove the need to threat-model it.

What a safe browsing tool looks like

A safer browser tool separates web fidelity from operator identity. The site should receive a real browser. The task should receive only the access it needs. The operator's device, cookies, and normal profile should remain outside the execution boundary.

Legba's MCP browser server follows that model. It spawns a real Chromium browser with a fresh identity on a fresh residential IP. The agent can navigate, act, extract, and capture the page. The browser runs off the operator's device and off their stack.

The client config makes the boundary visible. It declares mcpServers, a command, its args, and an env block containing LEGBA_API_KEY. Keep that key in the environment block and out of source control. Give it the scope required for the workflow, not the authority of an unrelated account.

The session lifecycle matters more than the install command. Spawn a fresh session. Drive the page. Read the result. Destroy the session. The Legba documentation maps that lifecycle across MCP, API, and SDK surfaces. On close, cookies, storage, tokens, and the session fingerprint go with it.

Disposal limits persistence. It does not excuse broad authority during the live task. If you deliberately sign in, that identity exists inside the session until it ends. Continue to scope credentials, separate write actions, restrict destinations, and log calls outside the agent.

The same principle applies beyond MCP. Browser infrastructure for agents should make the execution boundary explicit: fresh in, scoped while live, destroyed when done.

Plug in tools, not trust

MCP made tool interfaces portable. It did not make trust portable. Every server still arrives with code, descriptions, credentials, scopes, network access, and an execution surface. Those parts deserve review before the first tool call.

Read the config as a security document. Ask what the server can do, what the task actually needs, which identity it carries, where its secrets live, and what evidence remains. Then remove every capability without a direct answer.

The browser case makes the choice plain. A tool attached to your daily session carries your history and identity. A tool attached to a disposable browser carries only what the current task receives. When the task ends, that browser ends with it.

Plug in the tool. Keep the trust boundary small.