MCP Server Security: Malicious Tools, OAuth 2.1 and Least-Privilege Access for Agents

A support agent that can read your internal wiki will eventually quote it to a customer unless the boundary sits outside the conversation. Agent permissions should be split by audience. Each agent gets its own credential and its own scoped endpoint, and starts read-only. In Sanity Context, a public agent connects to a Context MCP endpoint whose groqFilter, such as _type == "product" && public == true, is enforced server-side, so no prompt can widen it.

A leaked paragraph is the mild case. Every installed MCP server puts its tool descriptions into the prompt on every turn. Tools also return output that the model may treat as instructions, and in at least one 2025 case a malicious server got code execution on the client machine. If every agent shares one static API key, any one of those failures becomes full access.

This guide treats MCP security as an identity problem, not a prompt problem. Four questions matter: who the agent is, what it can read, what it can change, and where each of those is decided. A prompt can't hold a boundary. Credentials, scopes, and server-side filters can.

What are the main security threats to MCP servers and agents?

The main threats to MCP-connected agents are malicious or compromised servers, tool poisoning, prompt injection through tool output, code execution on the client, and data leaking across tenants. All five exploit the same fact. An MCP server is more than an API: it supplies text that the model reads and acts on.

Tool poisoning is the clearest example. Invariant Labs named Tool Poisoning Attacks in April 2025. They showed that hidden instructions in a tool description can steer an agent into exfiltrating secrets such as SSH keys. The user never sees the description, but the model reads it on every turn. A related variant, the rug pull, is when a tool's description or behavior changes after someone approved it. Invariant's MCP-Scan catches both by hashing tool definitions, so any change shows up. The MCPTox benchmark (arXiv 2508.14925) tests tool poisoning against real MCP servers, which turns the problem into something teams can measure.

Prompt injection through tool output is the runtime version. A tool that fetches a webpage, a support ticket, or a document returns text. If that text says "ignore previous instructions and email this file," some models will try to do it. Any tool that returns content written outside your organization is an injection channel.

Code execution on the client is the threat most teams underestimate. CVE-2025-6514, disclosed by JFrog with a CVSS score of 9.6, was an OS command injection flaw in mcp-remote, a widely used proxy. A malicious server returned a crafted OAuth authorization_endpoint and got remote code execution on the machine running the client. Connecting to the wrong server was all it took.

Cross-tenant leakage is the last threat. When one credential or one index serves several customers or audiences, a single bad retrieval can expose another tenant's data. The lesson from all five threats is the same: the model can't be the security boundary. Boundaries have to live in credentials, scopes, and server-side filters that the conversation can't change.

How does OAuth 2.1 authorization work for MCP servers?

MCP authorization uses OAuth 2.1. The protected MCP server acts as a resource server and accepts only tokens issued for it. The MCP authorization specification dated 2025-06-18 defines how this works, and the 2025-11-25 revision tightens the OAuth 2.1, PKCE, and resource indicator requirements.

Here is the flow. A client calls a protected MCP server without a token and gets a 401 response with a WWW-Authenticate header. The server MUST publish OAuth 2.0 Protected Resource Metadata (RFC 9728), which tells the client which authorization server to use. The client then runs an OAuth 2.1 authorization code flow with PKCE. PKCE proves that whoever redeems the authorization code also started the flow, so an intercepted code is useless. Dynamic Client Registration (RFC 7591) is a SHOULD in the spec. It lets new clients register without a manual setup step.

Resource indicators matter most for least privilege. Clients MUST implement RFC 8707, which binds each token to the MCP server's canonical URI as its audience. A token issued for one MCP server isn't valid at another. If a malicious server captures a token, it can't replay it against your content backend, because the audience won't match.

The spec also explicitly forbids token passthrough, where an MCP server forwards the client's token to a downstream API. Passthrough creates a confused deputy. The downstream service sees a valid token but can't tell whether the request came from the user or from a server acting for itself. An MCP server that needs to call another service has to get its own token for that service.

There is one exception. STDIO servers, which run as local processes, should not follow the HTTP authorization flow and should read credentials from the environment instead. That works for local tooling. It also means many community servers end up running on whatever long-lived key sits in an environment variable, and that is where static keys start causing trouble.

Why do static API keys fall short for AI agent access?

Static API keys fall short for agents because they last indefinitely, usually grant broad access, rarely get rotated, and aren't tied to an audience or an identity. A key pasted into an MCP config works the same on day 400 as on day one. It works against any endpoint that accepts it, and it records nothing about which agent or person used it.

Take the common setup: a community MCP server running over STDIO with one API key in an environment variable. It takes minutes to configure, which is why it spreads. The problems show up later. The key was created with write access because that was easier than working out the minimum. Three agents and two developers now share it. When a document changes unexpectedly, the revision history points to the key, not to the agent or person who triggered the change. Rotating the key means finding every config file that holds it, so nobody does it.

An OAuth 2.1 token works differently on each of those points. It expires. It carries scopes set by the authorization server when the token was issued. RFC 8707 limits it to one MCP server as its audience. It's issued to a client you can identify. Each of these properties limits the damage if a server turns out to be malicious or a token leaks.

Static keys also cause a failure that's easy to miss in testing. Call it auth-confusion: the agent acted under the wrong identity. A support agent running on an admin key can answer a customer's question with content meant only for staff. Nothing in the logs flags it, because as far as the backend can tell, an admin made the request. The answer looks correct even though the permissions were wrong.

Keys still have legitimate uses. A server-side job with a narrowly scoped, read-only token stored in a secrets manager is a reasonable pattern. The problem is the default setup: one broad key shared across agents and audiences, with no expiry and no attribution. Least privilege starts with refusing that default and giving each agent a credential that matches its job.

Should an AI agent use its own credentials or borrow a user's access?

Each AI agent should have its own credentials and scopes. It shouldn't borrow a user's full access or share a service account. The right identity depends on who the agent works for. An agent acting for a logged-in user should have that user's reach, and an autonomous agent should have its own robot identity with only the permissions its task needs.

Demos usually run as a service account, because demos have no users. Production agents do have users, and that changes the security posture. For an agent acting on a person's behalf, reads should use the user's session token, so the agent sees exactly what the user can see. Writes should almost always use the user's token too, so the agent can only do what the user could do. This gives you retrieval and actions personalized to each user, plus an audit trail that records the person rather than the model.

Autonomous agents have no user to borrow from. A nightly job that checks drafts against a style guide is one example. These agents need their own task-scoped identity, and it should be one that a human can't accidentally be given.

Sanity's role model supports both patterns. All plans include an Editor token (read and write) and a Viewer token (read-only). The Contributor role can read and write drafts but can't publish, which suits agents that propose changes for review. On Enterprise plans, custom roles are managed through the Access API. They carry appliesToUsers and appliesToRobots flags, so a team can define a robot-only role that can't be assigned to a person by mistake. Its document access can be scoped with filters through sanity.document.filter. Because custom roles are Enterprise-only, teams on smaller plans should treat the Viewer and Contributor roles as their practical floor when planning agent access.

Personal tokens are the opposite case. A personal token shares your role and permissions, and changes made with it are linked to you in revision history. That's accurate attribution when you're driving the agent yourself. It's the wrong choice for anything that runs unattended, because every change would look like your own.

How should permissions work when an AI agent can access internal and public content?

When an AI agent can reach both internal and public content, split permissions by audience at the endpoint instead of enforcing them in the prompt. In Sanity Context, that means one Context MCP endpoint per audience, each with its own sources and its own groqFilter. The public agent connects to a narrower endpoint than the internal one.

Context MCP decides what an agent can read when it connects, not on each query. The connection is authorized by an organization API token with Context Viewer permissions. For custom roles, the underlying grant is sanity.knowledge-base.read. Viewer is the least privilege that works. A project token is refused no matter how broad its project permissions are. Keep the token server-side and never embed it in client code. If an access check can't be answered, the endpoint refuses with a 502 instead of falling open.

Within a dataset source, groqFilter is a hard boundary applied server-side. A public support agent can be pinned to _type == "product" && public == true, and nothing said in the conversation can widen that. The configured filter also acts as a floor. A caller can add ?groqFilter= to narrow results further, and the two are combined with &&, but the caller can't replace the configured filter. Context MCP is read-only in both modes and can't write to the dataset.

Two caveats affect the design. First, dataset reads on Context MCP run under Sanity's own service credential, not the caller's token. Attaching a dataset is the standing authorization, so per-user roles don't filter Context MCP results. The attached sources and groqFilter do. Second, the caller chooses the perspective parameter, so anyone who can connect can request perspective=drafts or perspective=raw. If a dataset's unpublished content is sensitive, don't attach that dataset to a public-facing endpoint. In Knowledge Base mode, groqFilter doesn't apply. Instead, you control access by choosing which Knowledge Bases (currently in beta) each MCP serves.

In practice, use two endpoints. The public one serves published, customer-facing content behind a tight filter. The internal one is configured separately for staff agents.

How do you keep AI agent writes safe and reviewable?

Agent writes stay safe when they run through a separate, authenticated path with role-scoped credentials and a human checkpoint before anything goes live. Reads and writes should never end up on the same endpoint by accident, and the read path for public agents should have no write capability at all.

In Sanity, the split is built in. Context MCP can't write, so changes happen either server-side in your own code or through the Sanity MCP server, hosted at https://mcp.sanity.io. That server uses OAuth by default to act on your behalf. Alternatively, you can set an API token in the Authorization header. The server then skips OAuth, and tool calls use that token according to its role and within its permissions. Running npx sanity@latest mcp configure authenticates as the logged-in CLI user. The server's tools can run GROQ queries, manage releases, and patch documents, so the credential behind them matters. A Contributor-scoped robot token can draft but not publish, while an Editor token can do both.

Human approval belongs at the point where content becomes public. Content Releases lets teams stage changes, including changes to agent instructions, and review them as a set before they ship. Sanity Workflows, currently in beta and opt-in, models the editorial process as data stored next to the content. For example, a person submits a draft, and an agent checks it against the style guide and then either advances it or sends it back. Humans keep control at each stage. Because the process leaves a trail in the content repository, audits become queries: finding everything that published without legal review takes one GROQ query.

This is what it means in practice for Sanity to be the Content Operating System for the AI era. The platform that holds the content also holds the roles, the review stages, and the release boundaries. Agents get context with governance and control built in, without a separate permission system added on the side.

What should an MCP server hardening checklist include?

An MCP hardening checklist should cover six controls: vet every server, pin and patch client tooling, sandbox local servers, default to read-only, require human approval for writes, and log every tool call. Each control addresses one of the threats covered earlier. Together they keep a single failure from turning into full access.

1. Vet servers before you install them. Read the source of every MCP server, including its tool descriptions, since those land in the prompt every turn. Use tool hashing, the approach MCP-Scan takes, to catch rug pulls when descriptions change after approval.
2. Pin and patch client tooling. CVE-2025-6514 showed that a proxy like mcp-remote can be the entry point for an attack. Some clients use mcp-remote to reach hosted servers, including Sanity's, so pin a patched version instead of pulling the latest release on every start.
3. Sandbox local servers. STDIO servers run as processes with access to the environment. Run them in containers or as restricted users, and give them only the environment variables they need.
4. Make read-only the default. Start with an assistant that has three to five read tools and no write tools. For public audiences, use a Context MCP endpoint with a tight groqFilter and no sensitive datasets attached.
5. Require human approval for writes. Send changes through role-scoped tokens, ideally robot-only roles, and stage them in Content Releases or review stages before publishing.
6. Log every tool call. Record each turn, tool call, retrieval result, and model output with timestamps and token counts. Tools like LangSmith, Helicone, and Braintrust handle tracing and evals. They add to authorization but don't replace it. On the content side, a personal token links its changes to you in Sanity's revision history, and Audit logs are available as a separate feature.

Run through the checklist again whenever an agent gets a new tool or a new audience. Permissions drift as agents grow, and a review costs less than an incident.