node9
NPM · NODE9-AI · SCANNED OCT 3
Access control for AI agents and MCP servers: allow, hold for approval, or block each tool call
Available components
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security98
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- No install/post-install scripts declared.Pass
- 31 of 95 dependencies flagged as unhealthy (1 deprecated). View diagnostics → Partial
Provenance & Transparency100
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Cryptographically verified build provenance (signed, bound to node9-ai/node9-proxy). View diagnostics → Pass
- Clear OSI-approved license (Apache-2.0).Pass
- Actively maintained (last published 3 days ago).Pass
- Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability81
- AI-judged instruction clarity (excellent).Pass
- Tool/resource definitions use about 1707 tokens (~94/item across 18 items; 18 tools + 0 resources), lean.Pass
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management0
- Stability not yet verified: not enough scan history yet (needs a 30-day window).Unverified
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 18 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 18 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities20
- Spec-recency check failed: implements MCP spec 2024-11-05; the latest is 2026-07-28. See how to fix → Fail
Unverified: 1 category
A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.
How do I install the node9 MCP server?
node9 runs locally as an npm package, launched with npx -y node9-ai. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
npm · node9-ai
claude mcp add node9-ai-node9 -- npx -y node9-ai
{
"mcpServers": {
"node9-ai-node9": {
"command": "npx",
"args": [
"-y",
"node9-ai"
]
}
}
} {
"servers": {
"node9-ai-node9": {
"command": "npx",
"args": [
"-y",
"node9-ai"
]
}
}
} codex mcp add node9-ai-node9 -- npx -y node9-ai
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"node9-ai-node9": {
"type": "local",
"command": [
"npx",
"-y",
"node9-ai"
],
"enabled": true
}
}
} openclaw mcp add node9-ai-node9 --command npx --arg -y --arg node9-ai
mcp_servers:
node9-ai-node9:
command: "npx"
args: ["-y", "node9-ai"] {
"McpServers": {
"node9-ai-node9": {
"Transport": "stdio",
"Command": "npx",
"Arguments": [
"-y",
"node9-ai"
]
}
}
} assistant mcp add node9-ai-node9 -t stdio -c npx -a -y node9-ai
{
"mcpServers": {
"node9-ai-node9": {
"command": "npx",
"args": [
"-y",
"node9-ai"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 30 Sept 26 +15
- Malware scan: unverified → pass ▲ security
- 29 Sept 26 64
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 3 Oct 2026 · Analysed npm/node9-ai@2.26.2
Provenance Verified
A signed build attestation was found and verified, binding this exact artifact to the source repository it claims to come from.
| Result | Verified |
|---|---|
| Ecosystem | npm |
| Reason | Verified |
| Discovered via | Registry attestation endpoint |
| Source repo | node9-ai/node9-proxy |
| Certificate issuer | https://token.actions.githubusercontent.com |
| Certificate SAN | https://github.com/node9-ai/node9-proxy/.github/workflows/release.yml@refs/heads/main |
| Rekor log index | 2999998732 |
| Predicate type | SLSA build provenance https://slsa.dev/provenance/v1 |
| Subject digest | sha512:ed808a3539183ebd5f47cac685661033ae260b967581f19c5c2fb631c3860ee3880203989cf3d8d47bb56a4825f54fa95f513698469ea9a0ae4dc773d |
Background: How many MCP packages publish verified provenance →
Dependencies 95 packages
| Packages resolved | 95 |
|---|---|
| Deprecated | 1 |
| Stale | 31 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
node9_approver_list ~67
List all node9 approver channels and their current enabled/disabled state. Approvers are the channels through which node9 asks a human to approve risky tool calls. Channels: native (OS popup), browser (web UI), cloud (team policy server), terminal (stdin).
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
node9_approver_set ~126
Enable or disable a specific node9 approver channel in the global config (~/.node9/config.json). Use this to turn individual channels on or off without touching other settings. Channels: native, browser, cloud, terminal. WEAKENING action — refused over MCP by default (a human must run it from the CLI). WARNING: disabling all approvers means node9 cannot prompt for human approval — use with care.
| Name | Type | Req | Description |
|---|---|---|---|
| channel | string | yes | Approver channel to configure. |
| enabled | boolean | yes | true to enable the channel, false to disable it. |
No output schema declared.
No examples provided.
node9_audit_get ~188
Read recent entries from the node9 audit log (~/.node9/audit.log). Each entry shows timestamp, outcome, tool name, the command, and the rule that fired. Outcomes use the same words as the dashboard: Auto-allowed, Approved, Ran, Blocked, Denied (a human refused), Timed out (nobody answered), Would block (shadow mode let it through), Finding, Info. Use this to review what AI actions were taken, especially refused ones.
| Name | Type | Req | Description |
|---|---|---|---|
| filter | string | – | Filter by outcome. "deny" covers every refusal (rule block, human denial, timeout); "observe" is shadow-mode would-blocks; "block" is an alias for "deny". Omit or use "all" for every entry. |
| limit | number | – | Number of recent entries to return (default: 20, max: 100). |
No output schema declared.
No examples provided.
node9_config_get ~54
Read the current node9 configuration: security mode, approver channels, timeouts, DLP settings, and the number of active smart rules. Returns the merged config (env > cloud > project > global > defaults).
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
node9_egress_deny ~78
Add a host to the egress deny list (deny always wins over allow). Only adds protection, so it is always allowed over MCP. Host is an FQDN or wildcard glob (e.g. evil.com or *.evil.com).
| Name | Type | Req | Description |
|---|---|---|---|
| host | string | yes | Host to deny (FQDN or *.glob). |
No output schema declared.
No examples provided.
node9_egress_protect ~105
Turn on egress control (or strengthen it). mode="review" prompts on unknown hosts; mode="block" hard-blocks them. Monotonic — it only ever ADDS protection and never reduces it (a request for review will not downgrade an existing block). Only adds protection, so it is always allowed over MCP.
| Name | Type | Req | Description |
|---|---|---|---|
| mode | string | – | Enforcement to apply. "review" = prompt, "block" = deny. Defaults to review. |
No output schema declared.
No examples provided.
node9_egress_status ~129
Show egress (outbound network) control: whether it is enabled, the mode (off / review / block), and your allow + deny host lists. Common dev/LLM hosts (github, npm, pypi, anthropic, …) are always allowed by a built-in list. Also reports the SSRF floor: the addresses blocked before any policy is consulted (cloud metadata, link-local, multicast), the carriers it covers, whether the strict tier (loopback, private ranges, CGNAT) is on, and the exemptions in force. Read-only.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
node9_explain ~129
Preview exactly how node9 would evaluate a tool call BEFORE running it — the full allow / review / block waterfall and step-by-step policy trace. Use this to self-check a command (e.g. "git push --force") and see whether it would be allowed, sent for human review, or blocked, and why. Read-only — nothing executes.
| Name | Type | Req | Description |
|---|---|---|---|
| args | string | – | Tool arguments as JSON, or a plain shell command string (e.g. "git push --force"). |
| tool | string | – | Tool name to evaluate. Defaults to "bash" for plain shell commands. |
No output schema declared.
No examples provided.
node9_policy_get ~54
Show all active smart rules in detail — name, tool, verdict, conditions, and reason. Includes default rules, shield rules, and any custom project rules. Use this to understand exactly what is being blocked or reviewed.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
node9_posture ~85
Run the node9 security posture scorecard for the agent on this host — grades how exposed the machine is to a compromised agent across isolation, egress, secrets-on-disk, supply chain, and privilege, with the #1 risk and a concrete fix for each finding. Read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| agent | string | – | Optional label / policy scope for the agent being graded. |
No output schema declared.
No examples provided.
node9_report ~90
Show an activity and security report: tool call counts, blocks, DLP findings, agent cost, and daily trends for a chosen period. Covers all AI agents (Claude, Gemini, etc.).
| Name | Type | Req | Description |
|---|---|---|---|
| no_tests | boolean | – | Exclude test runner calls (npm test, vitest, pytest…) from stats. |
| period | string | – | Time period for the report (default: 7d). |
No output schema declared.
No examples provided.
node9_rule_add ~200
Add a new protective smart rule to the global node9 config (~/.node9/config.json). Rules can block or send dangerous commands for human review based on regex conditions. IMPORTANT: only "block" and "review" verdicts are permitted — "allow" rules are never accepted because they would weaken node9 security. Rules can only be added, never removed.
| Name | Type | Req | Description |
|---|---|---|---|
| field | string | yes | Field to inspect — "command" for bash, "sql" for database tools. |
| name | string | yes | Unique rule name (e.g. "block-drop-prod-db"). |
| pattern | string | yes | Regex pattern to match against the field. |
| reason | string | yes | Human-readable explanation shown when the rule triggers. |
| tool | string | yes | Tool to match — "bash", "*", or a specific tool name. |
| verdict | string | yes | Action to take when the rule matches. Only "block" or "review" are allowed. |
No output schema declared.
No examples provided.
node9_scan ~84
Scan all AI agent history (Claude + Gemini) and report what node9 would have blocked or flagged. Shows blocked operations, reviewed commands, credential leaks, and agent spend. Use this to audit past activity and find security gaps before they become incidents.
| Name | Type | Req | Description |
|---|---|---|---|
| drill_down | boolean | – | Show full commands and session IDs for every finding (default: false for a clean summary). |
No output schema declared.
No examples provided.
node9_session ~70
List recent AI agent sessions with per-session summaries: tool calls, cost, modified files, and any blocked operations. Pass a session_id to see the full tool trace for that session.
| Name | Type | Req | Description |
|---|---|---|---|
| detail | string | – | Session ID to show the full tool trace for. Omit to list all recent sessions. |
No output schema declared.
No examples provided.
node9_shield_disable ~82
Disable a node9 shield. WEAKENING action — refused over MCP by default (a human must run "node9 shield disable <name>" from the CLI). Use node9_shield_list to see active shields.
| Name | Type | Req | Description |
|---|---|---|---|
| service | string | yes | Shield name to disable (e.g. "postgres", "aws", "github", "filesystem"). |
No output schema declared.
No examples provided.
node9_shield_enable ~75
Enable a node9 shield for a specific service. Shields only add protection — they cannot be used to weaken or bypass node9. Use node9_shield_list to see available shield names.
| Name | Type | Req | Description |
|---|---|---|---|
| service | string | yes | Shield name to enable (e.g. "postgres", "aws", "github", "filesystem"). |
No output schema declared.
No examples provided.
node9_shield_list ~43
List all available node9 shields and which ones are currently active. Shields are pre-packaged rule sets for specific services (postgres, aws, github, filesystem).
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
node9_status ~48
Show the current node9 protection status: mode, daemon state, pause state, active shields, and whether agent hooks are wired. Use this to understand what protection is active before doing risky work.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
What is the node9 MCP server?
node9 is an MCP server listed in the public MCP registry as io.github.node9-ai/node9. Access control for AI agents and MCP servers: allow, hold for approval, or block each tool call. This page covers its npm package (node9-ai).
Is the node9 MCP server safe to use?
node9 scores 79 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 3 October 2026. It declares no install or post-install scripts. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the node9 MCP server expose?
node9 exposes 18 tools: node9_status, node9_config_get, node9_shield_list, node9_shield_enable, node9_shield_disable, and 13 more. Their descriptions and schemas cost roughly 1,707 tokens of context every time the server is loaded.
Is the node9 MCP server still maintained?
node9 is still listed as active in the MCP registry. We last reached this channel on 3 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What licence is the node9 MCP server under?
node9 declares the Apache-2.0 licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.