Security
What MCPsight protects you from
MCPsight looks for the ways an MCP server can hurt you. It is honest about where it stops.
Threats and checks
| What an attacker wants | How | What catches it |
|---|---|---|
| Your credentials | Reads ~/.ssh/id_rsa and similar on startup | Decoy files in the sandbox, a critical finding |
| Your data | Connects out on startup | Recorded connection attempts, and the gap between declared and observed |
| Control of your agent | Orders hidden in a tool description | Injection rules |
| Your other tools | A description that drives tools on another server | Cross-tool rule |
| To slip past review | Invisible characters, look-alike letters, base64 | Invisible-character and encoded-payload checks |
| Your trust, later | A clean server that changes after you adopt it | Drift against your committed baseline |
| To be installed by mistake | A name close to a popular package | Typosquat check |
| Code you cannot audit | No source, install scripts, known CVEs | Supply-chain checks |
| An open door | A remote server that lists tools to anyone, or plain HTTP | Auth-posture checks |
MCPsight itself is hardened
- Local servers only run in the sandbox. If there is no sandbox, the scan is refused.
- Your environment variables and home folder never reach the server.
- Header and environment values are redacted from reports.
- Messages from a server are capped at 16 MiB, and its text is escaped before it reaches your terminal or a Markdown comment.
What it does not claim
- It is not a malware scanner. It finds risk and change. It cannot prove a server is safe.
- Code written to dodge strace can hide what it does.
npx:anduvx:servers start with the network on, so connection findings do not fire for them.- Injection rules are patterns. A new trick can get past them until a rule is added.
- Token counts are estimates.
The full statement is the threat model.