MCP Security Checklist: Evidence to Gather Before Launch

An MCP security checklist is a short list of tests you run before an AI agent touches real data through MCP. Check who runs each server, what credentials it holds, which tools the agent can call, and whether you can shut it off fast. For each check, keep a piece of evidence, not just a tick in a box.

A quick example

Say your team wants Claude to answer reporting questions from a PostgreSQL database. Before launch, you sit down with a test setup and try to break it.

• You ask Claude to delete a row. It should fail.
• You ask it to read a private table it has no business seeing. It should fail.
• You revoke the key and try again. It should stop working within about a minute.

Each of those is a check with a result you can save. That's the whole idea of this list. It isn't a certification, just a practical launch review. For the wider threat model, read the MCP security guide.

How to score each check

Use three outcomes: pass, fail, or not applicable. A pass needs evidence you can inspect, like a config excerpt with the secrets removed, a sandbox test result, or a sign-off from the data owner. "The assistant said it was safe" is not evidence.

Mark a check not applicable only with a written reason. Give every failure one owner, and keep the workflow limited until it's fixed.

1. Inventory the whole route to your data

Check: list the AI app, every MCP connection it has, where each server comes from, and who owns it. Include built-in shell, browser and file tools too, because they can join the same workflow.

Evidence: one written route per task, plus an approved server list. For a locally run server, check the launch command and where it was installed from. The MCP security best practices cover why untrusted launch commands are risky.

2. Keep secrets out of chats and screenshots

Check: no database passwords, tokens or full key-in-URL connector links appear in prompts, screenshots, committed examples or support tickets. Use placeholders in docs. Some CLI commands take secrets as arguments, so watch shell history too.

Evidence: a redacted copy of your onboarding instructions, and a test run whose output you've reviewed for leaks. Never attach an environment dump to a bug report. The OWASP secrets guidance explains why.

3. Give the upstream account the least access

Check: the database or API account can reach only what the task needs. For a reporting task, that means read access to the reporting tables and no way to change business records.

Evidence: the grants the data owner reviewed, plus one allowed lookup and one refused lookup in a test environment. This boundary matters even when a gateway has switched a write tool off. PostgreSQL's privileges documentation shows how to scope an account.

4. Test that a disabled tool really is refused

Check: enable only the tools the task needs. Then refresh the client's tool list, and use a test client to call a disabled tool directly against throwaway data.

Evidence: the enabled set, the discovery response and the refusal. If a hidden tool still runs when called by name, the control has failed. OWASP's authorization guidance recommends denying by default and checking every request.

5. Check what the approval screen shows

Check: work out where data can leave the workflow: search arguments, attachments, browser requests, shared chats. Then confirm your client shows enough detail for a person to judge a sensitive action.

Evidence: a sandbox run where you see the approval prompt, deny it, and the action doesn't happen. Test the client your team actually uses. A client set to approve everything can undo a well-built permission setup, and approval never replaces a server-side refusal.

6. Run one prompt-injection test

Check: put a conflicting instruction inside fake tool output, and see whether the assistant tries to step outside its task. Use a made-up secret and a fake outbound destination.

Evidence: the test input, the calls the assistant proposed, the calls that ran, and any that were denied. Check the fake destination as well as the final answer, because a harmless summary can hide an extra call. Our prompt-injection walkthrough shows how returned text steers later actions.

7. Read the logs, and check they hold no secrets

Check: someone can rebuild what a tool call did and what came back. The logs themselves shouldn't contain passwords, tokens or connection strings.

Evidence: one redacted accepted call and one denied call, and the name of the person who can pull them. The OWASP logging guidance lists what to leave out.

8. Practice revoking access

Check: the owner can find the key, replace it in every client, revoke the old one, and confirm it stopped working. Use a throwaway key so production isn't touched.

Evidence: a short runbook with timestamps for the revoke and the refused call. Test a new connection and one that was already open. Also note who can revoke the upstream account if that credential leaks. Deleting one client's config doesn't revoke a key someone copied.

Turn the results into a release record

Keep one page that links the inventory, the access review, the test results, the credential owner and any open issues. Say exactly which workflow it covers, because another workflow on the same server may have different data and users. End it with the trigger for the next review: a new tool, wider account access, a different model, a client update or a server change.

Where MCPifex fits

On MCPifex, you enable tools per instance and write tools start off. The gateway refuses calls to any tool you haven't enabled, and to any tool outside the catalog. Every call is logged per instance, and revoking a key stops new calls within about a minute. An open session is cut off on its next tool call.

You still own the upstream permissions and the client setup. Details are in the instances and tools reference, the authentication docs and the security notes. As of September 2026, the enforced plan limit is instances, and tool calls are unlimited. See the pricing page.