AI coding agents can read what your shell can read. That is powerful — and dangerous.
A local agent running in your development environment may be able to inspect source code, credentials, customer data, private notes, build artifacts, SSH config, cloud credentials, and anything else reachable from the account it runs under.
Bulwark is a consent layer for that world. Instead of trusting an agent process with ambient read access, Bulwark places a policy gate in front of sensitive file reads. When an agent tries to access protected material, the read can be paused, evaluated, audited, and approved out-of-band by a human.
The goal is not to be another sandbox.The goal is to make agent access explicit, policy-driven, and reviewable.Bulwark v0.1.0 is available now as a Linux technical preview. This release proves the core primitive end-to-end:
Kernel-level read gate
A protected file open is paused at the kernel before any bytes reach the agent. Decisions are made by inode, so a symlink or a rename with an innocent name still hits the same protected file.
Off-band consent
The approval travels over a channel the agent has no handle on. The agent sees only the result — the file opens, or it does not. It is structurally unable to approve its own access.
Local policy & audit
A policy file defines what is protected. Every decision is recorded — the process chain that led there, the file, allow or deny, and why — never the file content.
Public binaries
Signed-checksum artifacts for x86_64 and aarch64 Linux.
This is an MVP. It is intended for technical evaluators, early users, and design partners who want to inspect the primitive and understand the direction. macOS support is in development.
Traditional developer security assumes a human is driving the terminal. AI agents change that assumption.
An agent can move faster than a human, inspect more files than a human would manually open, and combine local context in ways that are difficult to review after the fact.
An agent reads a config file, includes a credential in a debug payload, and prepares to send it onward. This is not malicious. It is normal behavior. Bulwark gives teams the missing control point: before sensitive data is read, ask whether it should be read.
A security tool is only as useful as its honesty about what it does not do. Bulwark intercepts the file open — that is the boundary, and it has edges.
What it gates. Opens of a protected file by the supervised process tree, decided by inode. Because the decision is by inode and not by name, renames, symlinks, and hard links to a protected file are all still gated — they resolve to the same inode.
What it does not gate. Bulwark controls reach, not consequences. It does not stop an agent from using data it has already read, from acting on credentials already present in its environment, from reading a copy of a secret made elsewhere, or from sending anything over the network. It governs one question — may this process open this inode — and nothing downstream of the answer.
It intercepts the open, not the past. A file descriptor that was already open before Bulwark started is not gated; Bulwark sees opens, not descriptors that predate it. In the normal flow the gate is installed before the agent is launched, so the supervised tree cannot pre-open a protected file — but a descriptor handed in from outside the tree is out of scope.
It assumes the host root is trusted. Bulwark runs as a privileged process. The same root that runs it can stop it. Bulwark reduces what an agent can reach; it is not a defense against a compromised host or a malicious administrator. This is a deliberate boundary, not an accident — and the kind of tamper-resistance and managed-daemon hardening a fleet deployment needs is part of the Pro/Fleet direction below.
The decision context is ours, not the agent's. The process chain, the path, and the reason shown at decision time are derived by Bulwark from the kernel and the process tree. They are not text supplied by the agent. The agent is the subject of the decision, never a participant in it.
This is a technical preview. Some interactions — among them filesystem layering and supervisor-restart behavior under load — are still being characterized, and that work is ongoing in the open. We would rather state the edge than imply a wall that is not there.
Linux only. Bulwark uses fanotify permission events and requires root (CAP_SYS_ADMIN).
sudo bulwark run \ --protect ~/.ssh \ -- bash -c 'cat ~/.ssh/id_ed25519' # -> cat: Permission denied
With off-band consent, the read is held while you decide:
sudo bulwark run --consent socket --protect ~/.ssh -- claude bulwark consent # shows Process / Path / Reason, then allow / deny
Download binaries and checksums from the latest release.
The local Bulwark core is open and available as a technical preview. For teams, the future Bulwark Pro / Fleet direction is centralized control — upcoming, design-partner stage:
· Managed policy across hosts
· Centralized audit logs and proof trails for sensitive access
· Signed, managed daemons
· Team approval flows
· Integration with agent and security workflows
We are especially interested in teams adopting AI coding agents who need a practical consent and audit layer before those agents touch sensitive source, credentials, or production-adjacent material.