Free · Open Source · MIT

The security layer
for AI agents.

Three open-source layers, one model. NockLock fences what an agent can touch on the machine. NockGuard firewalls the tools it can call. The Wall shows the recorded audit trail, live. The illustration shows NockLock policy outcomes; each layer's limits are described below.

Browse the source See the layers ↓
$ brew install nocktechnologies/tap/nocklock nocktechnologies/tap/nockguard

macOS Homebrew · Linux and source setup →

Illustrative policy example, not a live session or audit transcript: blocked environment variables are removed before launch; the agent can work on project files, while configured SSH-key reads and unapproved network hosts are denied. Enforcement and event coverage vary by platform.

The model

Three layers.
One boundary.

An agent can do damage two ways: through the machine it runs on, and through the tools it calls. Nock Security puts policy at both boundaries, with a live view of recorded events. All three are open source, MIT, and run locally with no telemetry.

NockLock 01 · the fence

Sandboxes the agent process itself: filesystem, network, and secret fencing. Allowlist the hosts it needs; blocked secrets are stripped from the environment before launch. The OS-level boundary.

[network]
allow = ["api.anthropic.com"]
allow_all = false
NockGuard 02 · the firewall

An MCP proxy between the agent and its tool servers. Calls routed through it pass a per-agent policy: allowlist, deny, input validation, rate limits. The tool-level boundary.

policy: default-deny
allow:
  - nockcc.task_*
  - github.read_*
NockGuard Wall 03 · the live view

A local dashboard of recorded Guard decisions, with optional NockLock fence records from a log you select. Coverage depends on what each source records.

[allow] kit · github.read_pr
[block] ash · write_file
[allow] mira · nockcc.task_create
01 · NockLock · the fence

Fence the machine.

NockLock wraps agent CLIs with filesystem, network, and environment policy. Observed events go to a local SQLite audit log. Allowed file access and kernel network denials are not recorded per attempt; Linux file-denial logging depends on the interposer and macOS capture is best effort.

FS

Filesystem fence

Confine the agent to your project root; ~/.ssh, ~/.aws and other credential paths are denied for reads and writes. On Linux it's a kernel allowlist (Landlock). On macOS it's a kernel write boundary (Seatbelt); reads outside the root are not confined.

NET

Network fence

The proxy checks hostnames without decrypting HTTPS. Linux CONFINED blocks direct IP sockets, but local Unix sockets remain reachable below Landlock ABI 9; --net-fence=netns adds a network namespace and packet floor. With a configured filesystem root, macOS Seatbelt blocks connects that bypass the proxy. Without that root, macOS egress is advisory.

SEC

Secret fence

Blocked environment variables are removed before the agent starts, on both platforms. An optional preflight scan refuses to launch if it finds a key in the paths you name.

Full platform limits: filesystem platform boundary and network enforcement levels in the README.

Install on macOS

No NockLock account. No telemetry. Install your agent CLI separately.

Claude Code on macOS needs an exported CLAUDE_CODE_OAUTH_TOKEN or ANTHROPIC_API_KEY; its login keychain is fenced. See the authentication steps and Linux/source setup. Homebrew alone is not a complete Linux install.

# macOS Homebrew
$ brew install nocktechnologies/tap/nocklock

# from your agent's project directory
$ nocklock init --runtime claude-code
$ nocklock doctor
$ nocklock wrap -- claude
02 · NockGuard · the firewall

Firewall the tools.

NockGuard is an MCP proxy that sits between your agent and its tool servers. Calls routed through it pass a per-agent policy before they reach the server. When auditing is enabled, routed calls and their allow/block decisions are written to the local NockGuard trail.

Illustrative NockGuard animation, not live traffic or an audit transcript: example MCP calls are allowed or blocked by policy. Only calls routed through a configured NockGuard proxy are covered.

01

Per-agent tool policies

Each agent gets its own tool allowlist. Kit can call github.read_pr; Ash is denied write_file. Default-deny, scaffolded by nockguard init.

02

Input validation & rate limits

Validate configured input patterns and cap tool-call rates before forwarding to the server.

03

Local NockGuard audit trail

When auditing is enabled, calls routed through the proxy are recorded in NockGuard's local JSONL trail. The Wall reads this Guard trail and can add an explicitly configured NockLock log; the sources retain separate formats.

Try it on one serverPut NockGuard in front of a filesystem server.

Open a short, complete path from install to a verified read. For the full policy and signing guide, see the NockGuard README ↗.

Install and make a test file

Homebrew installs NockGuard and the Wall on macOS. The sample filesystem server needs Node.js with npx. Linux users can follow the release download and checksum steps in the README install guide ↗.

# macOS
$ brew install nocktechnologies/tap/nockguard

$ QS=$(mktemp -d)
$ cd "$QS"
$ printf 'NockGuard read succeeded\n' > hello.txt
$ pwd -P

Copy the physical folder path printed by pwd -P into <QS> below. Use fixture and executable paths without spaces for this example.

Initialize, connect, and verify

$ nockguard init
$ nockguard keygen --agent coder

The starter policy lives at ~/.nockguard/policy.yaml and allows coder to call read_file. Existing policies are preserved; check your coder rules if you already have one.

GUI clients may not inherit your shell's executable search path. Run these in the same terminal and copy their outputs into <NOCKGUARD_PATH>, <NPX_PATH>, and <SHELL_PATH> below:

$ command -v nockguard
$ command -v npx
$ printf '%s\n' "$PATH"

Point one MCP filesystem server through NockGuard, replacing all four placeholders:

{
  "mcpServers": {
    "files": {
      "command": "<NOCKGUARD_PATH>",
      "args": ["proxy", "--upstream", "<NPX_PATH> -y @modelcontextprotocol/server-filesystem <QS>", "--agent", "coder"],
      "env": {"PATH": "<SHELL_PATH>"}
    }
  }
}

Save the config and restart or reload the MCP client. Ask it to call read_file on <QS>/hello.txt; after the read succeeds, verify the signed trail and open the local Wall:

$ nockguard verify --agent coder
$ nockguard wall --agent coder

A successful routed read creates a signed trail. nockguard verify --agent coder checks its integrity and reports PROTECTED for a non-empty, fully checkpointed trail. For a blocked-write canary, the README explains the acceptance check against a local MCP stub and links its script. nockguard selftest uses synthetic probes and reports PROVEN for the firewall gate; it does not prove your client is wired through this proxy.

03 · NockGuard Wall · the live view

Watch it happen.

The Wall displays a configured NockGuard audit trail and, optionally, a NockLock log selected with --lock-db. It shows the decisions those sources recorded; it cannot show unrecorded activity.

▸

Recorded decision stream

See recorded allowed and blocked MCP decisions by agent. Add a NockLock events.db to show its recorded fence events alongside them; the database is opened read-only.

▸

Per-agent, at a glance

Review the configured Guard trail by agent and optional NockLock records by session. See the combined Wall setup and verification limits.

▸

Local and private

Runs on your machine against your own audit log. Nothing leaves the box.

Illustrative NockGuard Wall animation, not live audit data: sample allowed and blocked MCP events. The Wall can also show an explicitly configured NockLock log. It does not measure secrets leaked.

Fence it. Firewall it.
Watch it.

Browse the source · free Skool coming soon · get notified
macOS: brew install nocktechnologies/tap/nocklock nocktechnologies/tap/nockguard
The stack

The rest of the fleet.

Security is the foundation. The rest of the stack runs on top of it: memory, patterns, orchestration, and the cockpit that ties it together.