π‘οΈ Node9
What did your AI agent actually do? Find out.
Node9 sits between your AI agent and the tools it can use β discover what it's already been doing, protect against risky actions in real time, and review what happened over any time window.
Works with Claude Code Β· Codex CLI Β· Antigravity (agy) Β· GitHub Copilot CLI Β· Gemini CLI Β· Cursor Β· Windsurf Β· VSCode Β· Claude Desktop Β· Opencode Β· Pi Β· Hermes Agent Β· any MCP server.
What Node9 does
- π Discover β scan every past AI session for credential leaks, agent loops, blocked operations, and every secret on disk an agent could reach right now
- π‘ Protect β review or block risky commands before they run β
rm -rf, git push --force, DROP TABLE, credential reads, curl | bash, AWS/GitHub/Stripe key leaks
- π Review β period-windowed report (today / week / month / 90 days) β cost per agent, top tools, shields fired, blast radius
Retrospective scan
This is my own machine β 90 days while building Node9. Score 25/100, 5 credential files an AI agent could reach right now.
npx node9-ai scan
node9 scan
Security posture scorecard
node9 posture grades how exposed this machine is to a compromised agent β isolation, egress, secrets on disk, supply chain, privilege β and hands you the exact command to fix each finding.
node9 posture
node9 posture --ship
Findings are grouped by who can fix them: π the ones node9 reduces (just run the command) and π§± the ones only you can. Each carries a plain-language what / why / who and a real remediation β e.g. the "agent runs unsandboxed on the host" finding points straight at node9 sandbox run (below).
π‘οΈ Node9 Posture β agent on this host Score: 100/100 (Good)
2 advisories below don't affect the score β OS-level exposure, yours to weigh.
π’ node9 is already protecting you
β
Secrets node9 DLP is blocking this
β
Egress node9 egress is approval-gating this
β
Approval gate node9 is blocking this
β
Privilege node9 is approval-gating this
π node9 reduces these β run the command, the rest is yours
β οΈ Isolation Running directly on the host β no container
The agent runs loose on your whole machine, not in a sandbox.
β node9 sandbox run <agent> β jail it: kernel egress + scoped mounts + node9 inside
β node9 shield enable project-jail β or shrink the blast radius, keep host access
β οΈ Network exposure 4 services on 0.0.0.0 (node :3000/:4000, PostgreSQL :5432, Redis :6379)
Reachable from your whole network, not just this laptop.
β node9 shield enable postgres|redis β node9 blocks DROP TABLE / FLUSHALL
β bind to 127.0.0.1 / firewall the port (your part)
β
Supply chain no issues found
β
Coverage no issues found
Track this across your fleet & keep it green β node9.ai
Scan a repo β agent-CI security
node9 scan-repo checks any repo (or a local folder) for ways an AI agent wired into GitHub Actions could be hijacked by an outsider β injectable workflows, agent-reachable secrets, unpinned MCP servers, over-broad agent config, and poisoned instruction files. Static and parse-only: it reads only committed config, never executes repo code. No install or token needed for public repos.
npx node9-ai scan-repo <owner/repo>
node9 scan-repo .
node9 scan-repo <owner/repo> --json
π‘οΈ node9 scan-repo Β· node9-ai/agent-security-demo Β· β οΈ agent-security risk found
inspected 2 config file(s), 2 finding(s)
π΄ CRITICAL Injectable agent workflow β untrusted input reaches a tool-using agent with secrets
.github/workflows/vulnerable-example.yml Β· CI-2
β’ runs with base-repo secrets (pull_request_target)
β’ checks out the untrusted PR head into the workspace root
β’ allowed_non_write_users: "*" β any user can trigger the agent
β’ no effective actor gate
π΄ CRITICAL Exfiltratable secrets reachable by an injectable agent
.github/workflows/vulnerable-example.yml Β· CI-4
β’ agent has arbitrary shell (bare Bash) β can read env and exfiltrate
What it checks:
| CI-1 | committed agent config that pre-authorizes broad tools or runs remote hooks |
| CI-2 | injectable agent workflows β an outsider can trigger the agent and hijack it |
| CI-3 | unpinned / @latest MCP servers or inline credentials (supply chain) |
| CI-4 | secrets an injected agent could exfiltrate |
| CI-6 | poisoned or dangerous instructions in CLAUDE.md / AGENTS.md / skills |
Gate every PR β the same engine as a GitHub Action, so a hijackable config can't get merged:
- uses: node9-ai/agent-security-action@v1
with:
fail-on: high
Marketplace: node9 Agent Security Check
Live monitoring
node9 monitor opens an interactive terminal dashboard with two views:
[1] Realtime β live activity, approvals, security alerts, current risk score
[2] Report β period-windowed summary: cost, top tools, shields fired, blast radius
Report
Press [2] in monitor for a period-windowed summary. Toggle the window with [T]oday Β· [W]eek Β· [M]onth Β· [N]inety β same panels as the scan above, driven by your post-install audit log.
node9 monitor
node9 report --period 7d
Install
brew tap node9-ai/node9 && brew install node9
npm install -g node9-ai
node9 init
node9 login
node9 doctor
Requires Node.js 18+.
init on its own gives you full local enforcement: rules, shields, DLP and
approvals all work offline, on this machine.
login is what puts the machine on your dashboard. It prints a code, opens
the browser, and you approve the machine there; if you don't have an account
yet, signing up mid-flow returns you to the same approval with the code
intact. Until you run it, everything is enforced locally but nothing reaches
Mission Control, so the dashboard stays empty.
node9 logout disconnects a machine again. It revokes that machine's key;
local enforcement keeps running.
Shields β curated rule packs
Each shield is a curated rule set for a service or domain. Enable only what you need.
project-jail | Blocks reads of ~/.ssh, ~/.aws, .env, credentials via Bash and Read tool | node9 shield enable project-jail |
bash-safe | curl | bash, rm -rf /, disk overwrite, eval of remote | node9 shield enable bash-safe |
postgres | DROP TABLE, TRUNCATE, DROP COLUMN, DELETE without WHERE | node9 shield enable postgres |
mongodb | dropDatabase, drop(), deleteMany({}), index drops | node9 shield enable mongodb |
redis | FLUSHALL, FLUSHDB, CONFIG SET on a live server | node9 shield enable redis |
aws | S3 delete, EC2 terminate, IAM changes, RDS destroy | node9 shield enable aws |
k8s | namespace delete, helm uninstall, cluster role wipes | node9 shield enable k8s |
docker | system prune, volume prune, rm -f containers | node9 shield enable docker |
github | gh repo delete, remote branch deletion, settings changes | node9 shield enable github |
filesystem | chmod 777, writes under /etc/, /boot/, /usr/ | node9 shield enable filesystem |
mcp-tool-gating | unapproved MCP tools silently activating new capabilities | node9 shield enable mcp-tool-gating |
node9 shield list
Always on β no config needed
- Git β catches
git push --force, git reset --hard, git clean -fd
- SQL β catches
DELETE / UPDATE without WHERE, DROP TABLE, TRUNCATE
- Shell β catches
curl | bash, unauthorized sudo
- DLP β flags AWS keys, GitHub tokens, Stripe keys, PEM private keys in any tool argument, file contents, or shell config (
~/.zshrc, ~/.bashrc)
- Response DLP β background scanner reads Claude's conversation history and alerts you if Claude wrote a secret in its response text
- Skills pinning β SHA-256 verification of installed Claude skills / plugins between sessions
Review prompts β approve inline, in your agent
When node9 flags an action for review (e.g. git push --force, a DROP TABLE), the approve/deny prompt renders inline in the agent conversation β no frozen session, no separate terminal, no hook-timeout race. node9 still runs the full evaluator and makes the decision; only the prompt surface moves to the agent.
- On by default for Claude Code and GitHub Copilot CLI β the agents whose hook contract honors a native
ask. Every other agent (Codex, Gemini, Antigravity, Hermes, Cursor, OpenCode, Pi) uses node9's own approver.
- Control it with
reviewChannel in ~/.node9/config.json (or --no-ask on the hook):
{
"settings": {
"reviewChannel": "ask", // "ask" = inline agent prompt (default) | "approver" = node9's own approver
},
}
- Team setups: when a cloud/team approver is configured (
approvers.cloud: true), reviews route to that approver instead β node9 won't let an inline self-approval bypass routed/second-party approval.
Sandbox β run an agent in a jail
When watching isn't enough, node9 sandbox runs the agent inside a disposable container with a kernel-enforced egress allowlist and scoped mounts β while node9's hooks govern and audit every tool call inside the box. The hard version of protection: the agent can only touch the folder you mount and reach the hosts you allow; everything else is dropped at the kernel.
cd ~/my-project
node9 sandbox new
node9 sandbox run
node9 sandbox tail
- Disposable β the container is destroyed on exit; your project edits land on your real disk, nothing else survives.
- Same policy β your existing shields / egress rules / approvals apply inside the box, streamed to the same audit log and dashboard.
- Closes the posture loop β running it flips the Isolation / Egress findings green.
Honest scope (Phase 1): single container, Claude first (Codex next); the agent still holds its own credentials in the box (the egress wall confines them to the allowed hosts) β "the agent never holds a secret" is the credential-broker phase on the roadmap. Requires Docker.
MCP gateway
Wrap any MCP server transparently. The agent sees the same server β Node9 intercepts every tool call.
{
"mcpServers": {
"postgres": {
"command": "node9",
"args": ["mcp", "--upstream", "npx -y @modelcontextprotocol/server-postgres postgresql://..."]
}
}
}
Or just run node9 init β it wraps your existing MCP servers automatically.
π MCP tool pinning β rug-pull defense
MCP servers can change their tool definitions between sessions. A compromised or malicious server could silently add, remove, or modify tools after you first trusted it β a rug pull attack.
Node9 pins tool definitions on first use:
- First connection β gateway records a SHA-256 hash of every tool's name, description, and schema
- Subsequent connections β hash is compared; if tools changed, the session is quarantined and every tool call is blocked until a human reviews and approves the change
- Corrupt pin state β fails closed (blocks), never silently re-trusts
node9 mcp pin list
node9 mcp pin update <serverKey>
node9 mcp pin reset
Other commands
Beyond the three flow commands above (scan / monitor / report):
node9 blast | What an AI agent can reach right now β files, creds, env | First thing to run on any machine |
node9 tail | Live stream of every tool call (text-only, no TUI) | Piping into other tools, CI, logs |
node9 sessions | Session history with prompt, tool trace, and cost | Reviewing a handoff or past work |
node9 dlp | Credential-leak findings in Claude response text | Any time a DLP desktop alert fires |
node9 mask | Redact plaintext secrets from local session history files | After a DLP finding β cleans local disk |
Plus a live HUD in your Claude Code statusline:
π‘ node9 | standard | [bash-safe] | β
12 allowed π 2 blocked π¨ 0 dlp | ~$0.43
π claude-opus-4-7 | ctx [βββββββββββ] 54% | 5h [ββββββββββ] 12% | 7d [ββββββββ] 7%
π 2 CLAUDE.md | 8 rules | 3 MCPs | 4 hooks
Reading the data β what the numbers mean
Node9 surfaces the signal. Here are the patterns worth knowing:
Would have blocked β₯ 5 in a week | Agent is attempting high-impact ops; shields are worth reviewing |
Single review-git-push rule >50% of findings | Your own rule is firing as intended β not a risk, just supervision |
DLP finding in user-prompt tool | You pasted a secret into your own prompt β rotate the key |
| Agent Loop Γ50+ on same file | Agent stuck in edit/test/fix cycle β check context or slow down |
| MCP tool pin mismatch | Server changed its tools β review before re-trusting |
| Large MCP response warning | That server is inflating your context window for every subsequent turn |
Response DLP alert | Claude wrote a secret in its response text β not blocked, rotate immediately |
DLP finding in tool-result | Claude read a file containing a secret (.env, credentials) β rotate the key and run node9 mask |
DLP finding in [Shell] | Plaintext secret in ~/.zshrc or ~/.bashrc β every AI session can see it |
One-off signals are normal; persistent patterns are what you act on.
Python SDK β govern any Python agent
from node9 import configure, protect
configure(agent_name="my-agent", policy="require_approval")
@protect("bash")
def run_command(cmd: str) -> str:
...
Python SDK β Β· CI code review agent example β
Under the hood
- Scan reads raw agent history from
~/.claude/projects/, ~/.gemini/tmp/, ~/.gemini/antigravity-*/brain/, ~/.copilot/session-state/, ~/.codex/sessions/ β no API calls, fully offline
- Runtime intercepts tool calls via pre-execution hooks (Claude Code, Codex, Antigravity, GitHub Copilot CLI, Gemini CLI, Opencode, Pi) or via the MCP gateway (Cursor, Windsurf, VSCode, Claude Desktop). All decisions land in
~/.node9/audit.log atomically.
- MCP gateway is a stdio proxy; intercepts
tools/list + tools/call JSON-RPC, forwards the rest
- Policy engine uses mvdan-sh for bash AST analysis β defeats obfuscation via backslash escaping, variable substitution, eval of remote download
- Sandbox generates a Dockerfile + entrypoint that seal an
ipset/iptables deny-by-default egress wall, then drop to a non-root agent with node9's daemon + hooks running inside; only the agent's credential file is mounted, never your whole ~/.claude
Full docs
Config reference, smart rules, stateful rules, trusted hosts, approval modes, CLI reference β at node9.ai/docs.
Related projects
Enterprise
Node9 Pro adds governance locking, SAML/SSO, central audit export, and VPC deployment. See node9.ai.
License
Apache-2.0
Built with β and healthy paranoia.