The Five-Minute Security Check
You don't need to be a security expert to do a basic security evaluation of an AI tool. Five minutes of structured checking can reveal the most common issues and give you enough information to make an informed decision.
Start by checking the tool's security grade on an aggregation platform. If the tool has been scored, the grade gives you an immediate signal. An A or B grade means the tool passed automated checks for dependency health, maintenance activity, and code quality. A D or F grade means significant issues were found.
Step 1: Check Dependencies
After installing the tool (or before, if you can examine the dependency file), run a dependency audit. For npm packages, npm audit checks for known vulnerabilities. For Python packages, pip-audit does the same.
Pay attention to the severity of any findings. A low-severity issue in a transitive dependency is different from a critical vulnerability in a direct dependency. Focus your concern on critical and high-severity issues, especially in dependencies that handle data the tool processes.
Step 2: Check Maintenance Activity
Visit the tool's GitHub repository (or equivalent) and look at the commit history. When was the last commit? Are issues being responded to? Is there more than one contributor?
A tool with no commits in the past six months is probably not receiving security patches. This doesn't mean it's insecure today, but it means that if a vulnerability is discovered tomorrow, it's unlikely to be fixed promptly.
Step 3: Review Permissions
Read the tool's documentation to understand what permissions it requests. An MCP server's tool descriptions tell you what operations it can perform. If a tool requests broader permissions than its stated purpose requires, that's worth questioning.
A file system server that only needs to read files but requests write access is over-permissioned. A database server that requests the ability to drop tables when you only need query access is a risk you can avoid by finding a more restricted alternative.
Step 4: Check the Author
Look at who maintains the tool. Do they maintain other well-regarded projects? Do they represent an organization with a reputation to protect? Are they responsive to issues and security reports?
An anonymous author with no other projects isn't automatically untrustworthy, but it means you have fewer trust signals to work with. An author with a track record of maintaining quality open-source software provides more confidence.
Step 5: Consider the Blast Radius
Finally, think about what happens if this tool is compromised or behaves unexpectedly. If it only reads files in a specific directory, the blast radius is limited. If it has access to your email, database, and cloud infrastructure, the blast radius is much larger.
Match your evaluation rigor to the blast radius. A tool that can only read public data deserves less scrutiny than one that can modify your production database. Allocate your evaluation effort where the risk is highest.