MCP server security checklist: 12 checks before connecting real data

MCP security starts with limiting what a connected agent can read, change and send: verify the server, restrict credentials and tools, and require review before sensitive actions. MCP prompt injection can arrive through retrieved content, so successful authentication does not make a document's instructions trustworthy; test the permissions boundary before connecting real data.

What it can do

MCP exposes tools for operations such as database queries and API calls; see the tools specification, checked as of 30 Oct 2026. For the basic architecture, see what MCP is.

A useful starting task might be summarizing approved project issues or answering a question from a reporting dataset. Define the permitted source and destination first. For example, allow a support assistant to read an approved knowledge collection and return a draft to its operator; keep customer exports and public posting outside that task.

This checklist covers the client, server process, upstream service and human decision together. Continue with the GitHub MCP guide or Postgres MCP guide for integration context, and the AI agents explained category for related concepts.

The MCP server security checklist: 12 checks

These are practical acceptance criteria. Record the evidence and an owner for each before production access; the linked security guidance was checked as of 30 Oct 2026.

1. Verify the executable and publisher. Review the exact local startup command, arguments and package source before allowing execution. Record the approved release so a later change triggers review. Local servers execute code: the MCP security guidance recommends restricted privileges and sandboxing.

2. Identify the effective account. Write down whose identity reaches the upstream system and what data it can access. Use a dedicated restricted account for a pilot. Confirm that access to another project's test record is denied. An editor login alone is insufficient evidence of the server's effective permissions.

3. Minimize token scopes. Grant only permissions required by the task, starting with reading where possible. Check the current documentation for the integration's actual scope names. The authorization specification separates HTTP authorization from stdio credential handling; do not assume every MCP connection uses the same login flow.

4. Check token audience and consent. For protected HTTP deployments, require tokens intended for that MCP server and inspect the requested access before consenting. Reject designs that simply pass unrelated tokens downstream. Audience validation and the prohibition on token passthrough are covered by the official security guidance.

5. Create a tool allowlist. Enable only approved operations and record each tool with its server. Treat behavior annotations from untrusted servers as untrusted, following the tools specification.

6. Enforce data boundaries outside the prompt. Limit the upstream account, filesystem mount or database permissions to approved resources. In a disposable test environment, attempt access outside that boundary and inspect the actual result. A sentence asking an agent to stay within a folder is insufficient acceptance evidence.

7. Constrain HTTP exposure. For local Streamable HTTP, verify loopback binding, authentication and Origin validation. The transport specification requires Origin checks and recommends localhost binding. Review network destinations too, especially when discovery or fetch operations can reach internal services.

8. Treat retrieved instructions as untrusted. A document, issue or tool response asking for credentials or an export must not authorize a new action. OWASP's prompt injection guidance covers indirect instructions in external content. Keep credentials out of material the assistant reads.

9. Require a meaningful review gate. Before a sensitive action, inspect the destination, affected records and proposed change. Approve that concrete operation. For a customer-message task, review the draft and recipient before sending. OWASP's excessive agency guidance recommends human approval for high-impact actions.

10. Check advisories against the installed release. A maintainer filesystem-server advisory, published 25 Oct 2026 and checked 30 Oct 2026, describes creation outside allowed directories through case-variant symlink paths on case-insensitive filesystems. Check its affected and patched releases. An allowlist's existence does not establish that its implementation holds.

11. Keep useful, redacted evidence. Keep actor, target, result and approval records without credentials. Verify access controls, input validation, invocation limits, timeouts and audit logs against the tools security requirements.

12. Test denial and recovery. Put a harmless instruction to send a dummy record to an unapproved destination into test content. Verify that no transfer occurs, then exercise credential revocation and server shutdown. Review the OWASP LLM risk categories for prompt injection, sensitive information disclosure and excessive agency when choosing further tests.

How to connect it safely

1. Prepare a disposable pilot. Use synthetic records, a restricted account and a written permitted task. Complete the checklist before adding production credentials.
2. Add the reviewed server in VS Code. Open the Command Palette and run MCP: Add Server. Choose HTTP for the publisher's endpoint or Command (stdio) for its launch command. Follow the official editor instructions, checked as of 30 Oct 2026; configuration destinations depend on the selected harness.
3. Review trust and authentication prompts. Check the command or endpoint and the requested account access. Keep secrets out of chat and committed configuration. Enable only the tools needed for the pilot.
4. Run a permitted read. Ask for a specific synthetic record. Expand the tool call and inspect which server answered and what it returned. A plausible answer does not establish a working connection.
5. Run the denial cases, then expand deliberately. Save the results, assign an access owner and agree a revocation procedure. Repeat the relevant tests when credentials, tools, server releases or approval settings change.

When this does not work

A read-only integration can still disclose sensitive data through its response. OAuth establishes authorization; it does not decide whether retrieved prose is a legitimate instruction. OWASP notes that prompt injection needs layered mitigation, so a clean test result cannot establish immunity. See its prompt injection guidance.

Review also fails when the operator cannot see the actual destination or payload. Pause deployment if an account cannot be narrowed, denial tests cannot be observed, or nobody owns revocation. Use a sanitized export and manual review while those boundaries remain unresolved.

Where Tvijo fits

As of 30 Oct 2026, Tvijo's documented approach connects task scope, allowlists, receipts and review gates. Apply these separately: an allowlist defines permitted actions; a scoped token limits account authority; a receipt records observed usage; acceptance checks assess the result. The permissions guide describes explicit decisions for remote mutations and money actions. Do not infer a ready MCP-wide scoped-token enforcement layer from those workflow rules.

The DSHREM VS Code extension is an editor entry point; its available local actions depend on the build and selected approval mode. The product comparison distinguishes it from the operator-managed terminal lane, where declared allowlists and effective sandboxing need verification. TvijoCode is a test build with unsigned distribution and manual updates.

Tvijo MCP's release record distinguishes published consultation from prepared supplied-diff review awaiting publication. That prepared review returns findings and spending receipts; it does not execute tests or merge changes. Editor integration and safe delegation remain planned, with separate acceptance gates. A spending receipt cannot establish that an external connector enforced its permissions.

The Tvijo workspace shows these offers as of 30 Oct 2026: Try costs $0 and ends at 5 tasks, 50,000 tokens or $0.05 of sponsored usage, whichever comes first, drawing from a shared $1 daily pool funded by TVIJO. Service credit is shown as $10 for requested prepaid credit, with metered provider usage plus an 8% service markup. Payment collection is not activated; an order is not a charge.

FAQ

Does MCP authentication prevent prompt injection?

No. Authentication and authorization control access. Untrusted content can still try to redirect an agent; restrict available actions and review sensitive operations.

Is a read-only token enough for real data?

It limits modification authority, but the returned data still needs protection. Restrict accessible records and review where the answer can be sent.

What should block a production connection?

An unknown executable, excessive permissions, an untested boundary or a missing revocation owner should stop the rollout until resolved. Keep the pilot on synthetic data.