Skip to main content

Self-Protection Layers

A defense tool is only as trustworthy as its own integrity. If a compromised agent could silently rewrite Belay's rules, erase its audit log, or replace its binary, the whole boundary would be worthless. Belay guards its rules catalog, audit log, and binary through three complementary layers.

When this matters​

These layers exist for the adversarial case: a prompt-injected or otherwise misbehaving agent that turns its attention on the very tool watching it. They raise the cost and visibility of tampering — read the honest limit at the end before assuming they make tampering impossible.

Layer 1 — Command-layer deny (unprivileged, always on)​

On hook-visible tool calls, Belay inspects writes to its protected paths:

  • A direct Write or Edit to a protected path — the rules catalog, the audit log, or the belay binary — is denied (tamper.self_protect).
  • A Bash command that applies opaque external content (git apply, git am, patch) is surfaced for human review as an ask (tamper.indirect_write), since it could be a disguised write to a protected file.

This runs in the same deterministic, sub-100ms hot path as every other verdict and needs no special privileges.

Layer 2 — eBPF detect-and-kill (privileged, opt-in)​

Built with --features ebpf on Linux (requires CAP_BPF/root), a kernel-level sensor catches a process that writes a protected file outside the hook path — i.e. a write that never went through the tool-call boundary. A kernel OpenWrite event raises a Critical finding (bypass.self_tamper_write) and the reflex SIGKILLs the offending process.

note

This layer is detection plus reactive kill, not pre-write blocking. The write may land before the process is terminated; the value is fast, loud response and an audit record — not prevention of the first byte.

Layer 3 — Startup rules-integrity check (unprivileged, always on)​

The build embeds a SHA-256 of the rules catalog directly into the binary (include_str!). At daemon boot, Belay compares the on-disk rules catalog against that compiled-in hash. If the on-disk copy has drifted, it raises a loud alert.

Crucially, the running binary's compiled-in rules are unaffected by an on-disk edit — the daemon always enforces the rules it was built with, so tampering with the file on disk changes what a future build would load, not what the current daemon is doing.

The honest limit​

danger

True syscall-level prevention — blocking the write before it happens via fanotify FAN_OPEN_PERM or a BPF-LSM deny hook — requires CAP_SYS_ADMIN/root. Belay is designed to run unprivileged, never as root, so pre-write blocking is intentionally out of scope. Belay is a detect-and-respond system at the tool-call boundary, not a kernel-enforced mandatory access control.

This is a deliberate design trade-off: staying unprivileged means Belay cannot itself become a root-level foothold, at the cost of not being able to physically prevent every write. The three layers make tampering deny-at-the-boundary, detectable, and loud rather than silently possible.