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.
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.
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.
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
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_*
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
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.
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.
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.
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
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.
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.
Input validation & rate limits
Validate configured input patterns and cap tool-call rates before forwarding to the server.
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.
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.
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.
Local memory you review: decisions, directives and corrections your agents recall.
Learn more → FREE · OSS Nock Skills · the playbookOperational patterns: handoff protocols, review pipelines, standing orders.
Learn more → PRIVATE ALPHA Nock Terminal · the cockpitMission control for terminal-native coding agents (Claude Code, Codex CLI, Gemini CLI). Tabs, status, git, command palette. macOS, Windows, Linux. Private alpha.
Learn more → PRIVATE ALPHA · $49/MO AT LAUNCH Nock Command · the dashboardFleet coordination. Sprint planning, /fire dispatch, agent messaging, content pipeline.
Learn more → ← Back to homepage