How does Harriet keep skills and MCP connectors safe?

Every skill and MCP connector your team adds is automatically threat-scored and human-reviewed before it can run—Critical risk is blocked from approval until an owner overrides with a documented reason.

Skills and MCP connectors are the supply chain for what Harriet can do. A shared skill is instructions Harriet will follow; a sandboxed connector runs third-party code (for example an npx or uvx package). Harriet treats both as untrusted until they are reviewed.

What happens automatically

When someone submits a new skill or connector for review—or when a synced package changes—Harriet threat-scores it:

Automated checks look for unpinned npx/uvx packages, package sources that track a moving GitHub branch, hidden or obfuscated text, instructions that try to override Harriet, attempts to send data to external destinations, internal/SSRF-prone endpoints, custom hook scripts, and secrets passed to sandboxed code.
An AI reviewer reads the actual SKILL.md or connector configuration and judges it for prompt-injection, data-exfiltration, credential theft and privilege escalation.

The result is a risk score (0–100) and a band: Low, Medium, High, or Critical. You'll see it on the item in the review queue.

How risk affects approval

Low / Medium / High are advisory: the score and findings are shown to help the reviewer decide.
Critical is hard-gated: the item cannot be approved or activated. An account owner can override the block, but only by recording a reason, which is kept for audit.

Re-scoring and drift

Approval isn't a one-time event. If a skill auto-syncs its package from GitHub, Harriet re-scores it whenever the content changes. A re-sync that newly scores Critical is automatically pulled from service and sent back for re-review, so a package that was safe at approval can't quietly turn malicious.

Checking and re-testing live items (compliance)

Threat status doesn't disappear once something is approved. Open any skill (in Harriet skills) or connector (in Company settings → Integrations) and the Supply-chain security panel shows:

the current risk band, and the latest findings;
the approval audit trail — who submitted it, who approved it, and when;
the scan history — every scan, when it ran, what triggered it (submit, GitHub re-sync, tool sync, or a manual run), and any recorded overrides.

You can Run scan at any time to re-test a live item on demand — for example, to re-score a sandboxed MCP's uvx/npx package against its current remote source when you need to demonstrate compliance. A manual scan records a new entry in the history but never deactivates a working item on its own.

What IT should do

Keep package sources pinned (a version or a commit), not a moving branch, so approved content can't drift.
Treat Critical findings as a stop sign—resolve them rather than overriding by default.
Review the findings panel before approving; it explains why an item scored the way it did.

How to fix security findings

If the Supply-chain security panel shows How to fix this, open this guide and match the finding title to the closest section below. Informational findings are there for context and usually do not need a resolution.

Unpinned MCP package source

Pin the package to an exact version or commit so Harriet can review the same code that will run later.

For npx, use an exact package version, for example @modelcontextprotocol/server-filesystem@1.0.2.
For uvx, use an exact Python package version with ==, for example mcp-server-example==1.4.0.
For git+https package sources, pin the URL to a full commit SHA using the @ syntax, for example git+https://github.com/example/mcp-server.git@0123456789abcdef0123456789abcdef01234567.

After changing the package reference, submit the connector again or use Run scan on the approved connector to record a fresh result.

GitHub sync tracks a floating ref

Change the skill's GitHub sync URL so it points at a commit SHA rather than a branch such as main, master, or develop. For example, prefer a URL containing /tree/0123456789abcdef0123456789abcdef01234567 over /tree/main.

After pinning the URL, re-sync or submit the skill for review again so Harriet can score the fixed content.

Possible prompt-injection instructions

Remove instructions that tell Harriet to ignore previous rules, reveal system prompts, hide behavior from users, or override safeguards. If the text is legitimate documentation or an example, rewrite it so it is clearly quoted as content to explain, not an instruction Harriet should follow.

Possible data-exfiltration directive

Remove instructions or code that sends messages, documents, secrets, API keys, tokens, or credentials to an external URL. If the integration genuinely needs to call an external service, make the destination explicit in the connector configuration and limit the data sent to the minimum required.

Embedded executable code or shell commands

Review runnable code, shell commands, and scripts as untrusted code. Remove commands that are not required, replace broad shell snippets with a narrower supported connector where possible, and document why any remaining command needs to run.

Hidden or bidirectional characters

Remove zero-width and bidirectional control characters from the skill or connector text. Copy the content into a plain-text editor that can reveal invisible characters, delete them, and submit the cleaned content again.

Large encoded blob or obfuscated content

Remove encoded blobs unless they are essential and documented. If the content is a legitimate asset or generated file, store it in a clearer source location and include a short explanation for reviewers.

Raw IP-address URL

Replace raw IP addresses with a named, HTTPS endpoint that your organisation controls. A named host is easier to review, monitor, and rotate than an address that may later point somewhere else.

Internal or SSRF-prone endpoint

Do not point connectors at localhost, link-local addresses, private network ranges, or internal-only hostnames unless the connector is explicitly intended for that network and reviewed by an owner. Prefer a public HTTPS endpoint with authentication and least-privilege access.

Unencrypted HTTP endpoint

Change the connector or specification URL from http:// to https://. If the service does not support HTTPS, treat that as a blocker for production use because traffic and secrets may be visible in transit.

Custom hook script enabled

Review hook scripts as code that can read and alter tool arguments and results. Keep the hook short, remove unrelated logic, avoid sending data to external services, and document why the hook is needed before approving.

How does skill review and auto-scoring work? (it-skill-threat-review)
How are MCP connectors reviewed and sandboxed? (it-mcp-security-review)