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 configured NockGuard audit trails. View recorded allowed and blocked MCP calls by agent. Activity outside those proxies is not covered.
[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; NockLock records use a separate format.
Watch it happen.
The Wall is a local dashboard for recorded decisions in configured NockGuard audit trails. It shows allowed and blocked MCP calls routed through those proxies, by agent; activity outside a configured proxy is not covered.
Recorded decision stream
See allowed and blocked MCP calls written to the configured audit trail, tagged by agent. The Wall reads recorded events; it does not observe activity outside the proxy.
Per-agent, at a glance
Review recorded calls for each agent with a configured NockGuard trail, including tools the policy blocked.
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 events. The Wall displays records from configured NockGuard audit trails and 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