How are MCP connectors reviewed and sandboxed?

MCP connectors are threat-scored on submission and run in isolated sandboxes; unpinned npx/uvx packages, moving git sources, internal endpoints and hook scripts raise risk, and Critical risk blocks approval until an owner overrides.

MCP connectors let Harriet call external tools, and sandboxed connectors run third-party packages (npx / uvx) at run time. Because that's code you didn't write, Harriet threat-scores every connector before it can be approved and isolates the ones that execute packages.

Threat-scoring on submit

When a connector is submitted for review, Harriet attaches a risk score and band based on:

Unpinned packages — an npx/uvx package without a fixed version, or a git+https://… source without a pinned commit, can change after you approve it. Pinned references (a version, tag or commit) score lower.
Endpoint safety — connectors pointing at internal or link-local hosts (a common SSRF vector) or plain http:// endpoints are flagged.
Hook scripts — a custom JavaScript hook runs on every tool call and is treated as untrusted code.
Secrets and OAuth — environment variables, credential files and per-user OAuth tokens handed to third-party code increase the blast radius.

An AI reviewer also reads the connector configuration for injection, exfiltration and credential-theft patterns.

Sandboxing

Sandboxed connectors run in isolated containers, by default in an EU region, never on Harriet's application servers. Every tool call is recorded in an append-only audit log you can inspect later.

Approval and Critical risk

The reviewer sees the score and findings in the review queue.
Critical connectors are blocked from approval and activation. An account owner may override with a documented reason, which is kept for audit—prefer resolving the finding (for example, pinning the package) instead.

Re-testing a live connector (compliance)

Once a connector is approved, open it in Company settings → Integrations and the Supply-chain security panel shows its current risk band, the approval audit trail (who approved it and when), and the full scan history. Use Run scan to re-test on demand—for example, to re-score a sandboxed uvx/npx connector against its current remote package when you need to demonstrate compliance after it's installed and working. The new result is recorded in the history; a manual scan never deactivates a working connector on its own.

What IT should do

Pin packages to a version or commit; avoid latest and bare git branches.
Use HTTPS endpoints and avoid internal hosts unless you intend an internal integration and understand the SSRF implications.
Keep hook scripts minimal and reviewed.

How to create an MCP connector (it-how-to-create-mcp-connector)
How does Harriet keep skills and MCP connectors safe? (it-supply-chain-security)