Kernel Borderlands: An eBPF-Based Behavioral Detection and Multi-Agent Containment Architecture for Linux Server Workloads

1. Introduction

When a Linux server is compromised, the attacker’s actions eventually become kernel operations: a process is executed, a credential changes, a sensitive file is opened, a socket connects to a remote host, or a memory region becomes writable and executable. The extended Berkeley Packet Filter (eBPF) lets verified programs observe these operations at Ring 0 with low overhead [1], and since Linux 5.7 BPF-LSM programs can also deny them [2].

Observation, however, is not defence. A runtime defence must also decide how strongly to respond, enforce that decision where the attacker cannot simply ignore it, prove afterwards that its record of what it did has not been altered, and protect itself from being blinded or turned against the host. Existing tools usually provide one or two of these properties: eBPF monitors alert but rarely respond, enforcement tools respond with a fixed kill-or-deny rule, and almost none keep a tamper-evident record of their own actions.

• Transitions, not events.

A single execve() is not an attack, and neither is a single anonymous mmap() or a single change of user ID. The same execve() after a privilege change, inside an unexpected process lineage and after a burst of writable-and-executable mappings very likely is. KB therefore treats the transition between behavioural states over time as its unit of analysis: each event updates one of six weighted behavioural dimensions of its process, the composite score is smoothed, and rule chains move the process through the states SAFE, OBSERVED, SUSPICIOUS, BORDERLANDS and COMPROMISED.

• Problem statement.

From this view we derive five problems that existing tools do not solve together.

• Observability is not response. Seeing an attack is of little use unless the system can choose and apply a proportionate response inside the kernel, quickly and, where possible, reversibly.
• Telemetry must never delay enforcement. A burst of events, for example from a build job that spawns thousands of short-lived processes, must not stall the path that carries containment orders. We hit exactly this failure during development: on one shared socket a telemetry burst filled the send buffer, the sensor misread EAGAIN as a dead peer, and containment delivery went down with it.
• The defence must not be turnable against itself. The containment pipeline must refuse to act on PID 1, kernel threads, critical daemons, organisation-critical workloads or its own watchdog, even if an upstream decision asks it to.
• Decisions must be provable. Every enforcement action, policy reload and agent decision must be recorded so that later modification or deletion is detectable.
• The decision-makers need supervision. Once agents may recommend containment, a stuck or misbehaving agent must be detected and restarted, and the decision layer should not start until the layers beneath it have been verified.

Kernel Borderlands (KB) implements the full observe–score–decide–enforce–audit loop for Linux server workloads. Its name reflects the central idea: each process lives in a behavioural zone (SAFE, SUSPICIOUS or BORDERLANDS), and the defence acts at the border between normal and hostile behaviour rather than on individual events. The contributions of this paper are:

• An architecture of five cooperating subsystems connected only through root-owned Unix sockets, with telemetry and control on separate channels (§Section 4).
• Five graded containment levels enforced by BPF-LSM, guarded by two ordered authorisation gates (CPM, CWP) that no decision layer can bypass (§Section 6).
• A unified formulation of every learned and statistical decision procedure: behaviour scoring, the reinforcement-learned Containment and Jury policies, quorum consensus, agent oversight, beaconing detection and the audit chain (§Section 5).
• An evaluation combining offline policy results, a live attack capture, a run-time overhead benchmark, the test suites, and a source-level security audit, together with the defects found by testing on real hosts (§Section 14–§Section 16).
• An open-source implementation packaged for Ubuntu and Arch Linux, with its kernel requirements, portability model and a test case study (§Section 11, §Section 14.4).

Section 2 reviews related work and Section 3 states the threat model. Section 4, Section 5, Section 6, Section 7, Section 8 and Section 9 describe the architecture, the mathematical formulation and each subsystem; Section 10, Section 11, Section 12 and Section 13 cover implementation, deployment, the end-to-end path and the operator interfaces. Section 14 evaluates the system, and Section 15, Section 16, Section 17 and Section 18 discuss the results, the audit, the limitations and future work.

2. Background and Related Work

• eBPF and BPF-LSM.

The BSD Packet Filter [3] introduced an in-kernel virtual machine for packet filtering. eBPF generalised it with maps, helper functions and a verifier that proves termination and memory safety before a program is loaded [1]; programs attach to tracepoints, kprobes, XDP [4] and, through KRSI, LSM hooks [2]. BTF and CO-RE let one compiled object run unchanged across kernel versions [5].

• Access control and intrusion detection.

SELinux [6] and AppArmor enforce static policy through the LSM framework [7]; an exploited server that stays within its permitted operations does not violate that policy. Forrest et al. showed that system-call sequences form a “sense of self” for a process [8], which started a long line of host-based anomaly detection [9]. Network datasets such as NSL-KDD have well-known flaws [10,11], and ADFA-LD [12] provides Linux system-call traces of modern attacks.

• eBPF security tools.

Falco [13] and Tracee [14] evaluate rules and signatures over kernel events and focus on detection. Tetragon [15] adds in-kernel enforcement, but its response is rule-triggered and binary. Table 1 compares these approaches with KB.

• Learning-based response and trust.

Choosing a response under uncertainty is a sequential decision problem suited to reinforcement learning [16]; KB uses PPO [17] with RLlib [18] on Ray [19]. Agreement among agents relates to the Byzantine generals problem [20]. Hash-chained logs [21,22] make tampering detectable, and TPM measured boot [23,24] anchors trust below software, which matters because a software watchdog on a compromised kernel faces the confused-deputy problem [25].

• Gaps in existing approaches.

Taken together, the survey leaves eight gaps that KB is designed to close: (L1) signature tools miss novel and obfuscated attacks; (L2) static access-control policy cannot adapt when a permitted binary is hijacked; (L3) user-space monitors can be killed or blinded by a privileged attacker; (L4) most eBPF tools stop at an alert, leaving a human in the critical path; (L5) where enforcement exists it is all-or-nothing, so a false positive on a production database is as damaging as the attack; (L6) nothing prevents a containment pipeline from being steered against PID 1, systemd or the defence itself; (L7) plain logs can be edited after the fact; and (L8) systems that automate response rarely supervise the automation itself.

3. Threat Model and Design Goals

We assume an attacker who has gained code execution on the host, for example through a vulnerable network service, and who may escalate to root. The attacker may try to stay within a process’s permitted system calls, spread activity across many resources to evade rate limits, flood the telemetry channel, or attack the defence itself. A full kernel compromise, in which the attacker can rewrite kernel memory, is beyond any same-host software defence and is out of scope.

From this model we derive five goals. G1 enforcement must happen in the kernel; G2 responses must be proportionate, and reversible below the final level; G3 no decision path may contain PID 1, kernel threads, critical daemons or KB’s own components; G4 every action must be recorded in a log whose alteration is detectable; and G5 the decision layer must not start until the layers beneath it have been verified. Table 2 maps the STRIDE categories to the mechanisms that address them.

4. System Architecture

KB consists of five subsystems (Figure 1). kb-core (C/eBPF) is the only Ring-0 component. kb-control-plane (kbd, Go) ingests telemetry, keeps state, audits and exposes APIs. kb-aads (Python/Ray) is the agent swarm. kb-checker (Rust) is the integrity watchdog, and kb-op provides the operator interfaces.

Telemetry flows one way, from the sensor’s user-space bridge to kbd over kbd.sock; containment, sensitive-path, rule and workload pushes return over a separate kbct.sock (Table 3). The split fixes a real availability bug: on a single multiplexed socket, a telemetry burst filled the send buffer, write() returned EAGAIN, and the sensor treated this as a dead peer, taking containment delivery down with it. All sockets are root-owned Unix domain sockets with mode 0660 and group kb; the internal data path has no TCP listener.

• Wire contract.

Messages between the C sensor and the Go control plane are packed little-endian frames: a 4-byte length prefix, a 4-byte header (magic 0x4B42, wire version 3, message type) and a fixed payload. Table 4 lists the message types. Because the two sides are compiled separately, sizes and type codes are locked by byte-exact tests on both sides. New types are additive: a receiver ignores a type it does not know, which is how the containment acknowledgement (type 10) was introduced without changing the wire version.

• Architectural principles.

Three principles shape the design. First, each layer talks only to its neighbours, which limits the blast radius of a failed component. Second, enforcement authority sits in the control plane and the sensor: the swarm is advisory, and disabling it leaves deterministic enforcement by the policy engine running. Third, the watchdog does not trust any component’s report about itself; it reads the BPF programs and the kernel containment map directly and compares the map with the control plane’s state.

5. Mathematical Formulation

• Behaviour score and zones.

Each process has six behavioural dimensions $d_k\in [0,100]$ (process, syscall, privilege, file, network, memory). An event e sets the dimension it belongs to, $d_{k\left(e\right)}\leftarrow v\left(e\right)$, where the value depends on the event’s flags:

$$v\left(e\right)=\left\{\begin{array}{cc}5\hfill & \mathrm{exec}\mathrm{or}\mathrm{exit}\left(\mathrm{process}\right)\hfill \\ 80\mathrm{if}\mathrm{escalation},\mathrm{else}10\hfill & \mathrm{credential}\mathrm{change}\left(\mathrm{privilege}\right)\hfill \\ 70\mathrm{if}\mathrm{sensitive}\mathrm{path},\mathrm{else}5\hfill & \mathrm{file}\mathrm{open}\left(\mathrm{file}\right)\hfill \\ 15\hfill & \mathrm{connect}\mathrm{or}\mathrm{bind}\left(\mathrm{network}\right)\hfill \\ 90\mathrm{if}\mathrm{RWX},25\mathrm{if}\mathrm{anonymous},\mathrm{else}5\hfill & \mathrm{mmap}\mathrm{or}\mathrm{mprotect}\left(\mathrm{memory}\right)\hfill \end{array}\right.$$

(1)

The syscall dimension is not set by individual events. Every ten ring-buffer polls the sensor reads the per-process system-call counters from a kernel map, computes the distribution $p_i$ of the calls made since the previous scan, and normalises its Shannon entropy by the entropy of 512 equally likely calls:

$$d_{\mathrm{sys}}=\min \left(100,100·{\displaystyle \frac{-{\sum }_i{p}_i{\log }_2{p}_i}{{\log }_{2}512}}\right),{\tilde{d}}_{\mathrm{sys},t}=\alpha d_{\mathrm{sys},t}+(1-\alpha ){\tilde{d}}_{\mathrm{sys},t-1},$$

(2)

and a smoothed value ${\tilde{d}}_{\mathrm{sys}}\ge 60$ raises a high-entropy evidence flag. The composite score is

$$s_t={\displaystyle \sum _{k=1}^6}{w}_k{d}_k,$$

(3)

with $\mathbf{w}=(0.20,0.25,0.20,0.10,0.10,0.15)$ in the order above, and it is smoothed by an exponential moving average

$$S_t=\alpha s_t+(1-\alpha )S_{t-1},S_0=s_0,\alpha =0.3.$$

(4)

The zone is SAFE if $S_t<{\theta }_s$, SUSPICIOUS if ${\theta }_s\le S_t<{\theta }_b$ and BORDERLANDS otherwise, with defaults ${\theta }_s=40$, ${\theta }_b=75$ that can be overridden per process name. In parallel, a rule engine tracks evidence flags and ordered sequences (for example an RWX mapping followed by a write to process memory within 30 s; all 19 rules are listed in Appendix C) and moves a process from SAFE through OBSERVED, SUSPICIOUS and BORDERLANDS to COMPROMISED.

Figure 2. Rule-driven behaviour states. The dashed IOC rule, which would jump directly to COMPROMISED, is designed but cannot yet fire (Section 17)

Figure 2. Rule-driven behaviour states. The dashed IOC rule, which would jump directly to COMPROMISED, is designed but cannot yet fire (Section 17)

• Containment policy.

Containment is a single-step decision over the observation $o=(\mathrm{score},\mathrm{zone},u_{\mathrm{root}},\Delta \mathrm{score},e)\in {\mathbb{R}}^5$ with action $a\in \{0,\dots ,4\}$ (NONE to TERMINATE). Against the labelled target level t the reward is

$$r(a,t)=1-0.3|a-t|-0.2|a-t|\mathbb{1}[a<t],$$

(5)

so under-containment costs 0.5 per level of error and over-containment 0.3 (Figure 3). The policy ${\pi }_{\theta }$ is trained with PPO, which maximises the clipped surrogate

$$L\left(\theta \right)={\widehat{\mathbb{E}}}_t\left[\min \left({\rho }_t{\widehat{A}}_t,\mathrm{clip}({\rho }_t,1-ϵ,1+ϵ){\widehat{A}}_t\right)\right],$$

(6)

with ${\rho }_t={\pi }_{\theta }\left(a_t\right|o_t)/{\pi }_{{\theta }_{\mathrm{old}}}\left(a_t\right|o_t)$. Serving is deterministic, $a^{*}=\arg {\max }_a{\pi }_{\theta }(a\mid o)$.

• Jury policy and quorum.

The Jury reuses o with a binary target $t^{\prime }=\mathbb{1}[t>0]$ and rewards $+1.0$ (TP), $-0.5$ (FP), $+0.1$ (TN) and $-1.0$ (FN). Without a full observation it falls back to a threshold on a confidence $c\in [0,1]$: CONTAIN if $c>0.75$, otherwise ALLOW. For votes ${\left\{(v_i,w_i)\right\}}_{i=1}^n$ from a freshly spawned Jury pool, containment proceeds iff

$$Q={\displaystyle \frac{{\sum }_{i:v_i=\mathrm{CONTAIN}}{w}_i}{{\sum }_{i=1}^n{w}_i}}>\frac{1}{2},$$

(7)

and Q is false for $n=0$. All weights are currently $w_i=1$, giving a simple majority.

• Beaconing and slow exfiltration.

For each (PID, address, port) flow, the last $\min (N,100)$ inter-connection intervals are binned into $(0,1],(1,5],(5,10],(10,30],(30,\infty )$ seconds, and

$$H=-{\displaystyle \sum _{j=1}^5}{p}_j{\log }_2{p}_j$$

(8)

is the Shannon entropy [26] of the bin distribution, with a sentinel 3.0 below ten samples. Connection counts $x_i$ per 60 s bucket feed Welford’s running mean and variance [27] and a one-sided CUSUM [28] with slack $k={\sigma }_i/2$:

$$S_i=\max \left(0,S_{i-1}+(x_i-{\mu }_i-k)\right),$$

(9)

flagged when $S_i>5{\sigma }_i$ after at least five buckets. A beacon alert requires both $H<1.2$ and the CUSUM flag and is debounced to one per flow per five minutes, so neither regular low-volume traffic nor a single burst triggers it alone. Figure 4 shows why the threshold separates beacons from interactive traffic: a fixed-interval beacon puts every interval in one bin ($H=0$), while timing spread over all five bins reaches the maximum ${\log }_{2}5\approx 2.32$.

• Severity and courthouse oversight.

A score s maps to CRITICAL ($s\ge 90$), HIGH ($s\ge 75$), MEDIUM ($s\ge 50$) or LOW, and is raised one tier if the process matches a registered critical workload; severity routes alerts but never decides containment. For a registered agent with error count e, status $\sigma$ and uptimes $u_0,u_1$ read $\tau =3$ s apart, the verdict is terminate if the agent is unregistered, restart if $\sigma \ne \mathrm{active}\vee e\ge 5\vee u_1\le u_0$, and healthy otherwise.

• Audit chain.

Each audit row commits to its predecessor,

$$h_i=\mathrm{SHA}256(f_i\parallel h_{i-1}),h_0=\text{``}\mathrm{genesis}\text{’’},$$

(10)

so altering or deleting a row changes every later hash, which recomputation detects [21].

6. kb-Core: Sensor and Enforcement

• Hooks and portability.

Tracepoints and kprobes on process exec and exit, system calls, commit_creds, openat, connect/bind, mmap/mprotect, process_vm_writev and security_capable, plus TLS uprobes, write one unified event record into a 1 MB ring buffer. The sensor is built with CO-RE: kernel fields are read only through BPF_CORE_READ(), and libbpf relocates them at load time, so one object runs on any kernel from 5.10 with BTF and CONFIG_BPF_LSM. Loading is all-or-nothing and depends on the kernel’s actual features rather than its version number, which matters because enterprise kernels backport eBPF features: if BTF, a relocation or a program type is missing, the load fails and the sensor exits before attaching any program. Table 5 lists the attachment points. Section 11 gives the CO-RE build, the kernel requirements and a compatibility matrix for 16 distributions.

• Graded containment.

Five LSM programs (file_open, bprm_check_security, socket_connect, socket_bind, file_mprotect) consult contained_pids_map and deny the operation, returning -EPERM from the exec hook and -EACCES from the others (Table 6). Level 1 is applied through cgroup v2 limits [29]. Level 4 applies every block the hooks can enforce, and kbd then sends SIGKILL through a pidfd. It does so only if the process passes kbd’s own copy of the CPM and CWP checks and the sensor acknowledges that it wrote level 4 to the map; a refusal, or no acknowledgement within 3 s, means no kill. In file_open, the full-quarantine check runs before bpf_d_path(), so a path-resolution failure cannot bypass it. Listing  shows the hook with its comments removed. The key is zero-padded because map lookups compare all 64 bytes, and bpf_d_path() does not clear the tail.

• Authorisation gates.

Any decision layer can be wrong, so two user-space gates run in a fixed order before the kernel map is written (Algorithms Section 6 and Section 6). Releasing containment is never gated. The Critical Process Module (CPM) has a compiled-in floor that includes systemd, kbd and kb-checker, so KB cannot be turned against its own watchdog. Critical Workload Protection (CWP) lets an organisation register workloads by path or by SHA-256 hash; a HASH-tier binary that no longer matches its digest is logged as “Identity Verification Failed” and becomes eligible for containment, because it has shown itself not to be the workload it claims to be.

...

Algorithm 1: CPM classification (cpm_classify)

1: if readlink(/proc/pid/exe) fails then return REJECT_KTHREAD

2: if pid $=1$ then return REJECT_PID1

3: if pid ∈ protected_pids then return REJECT_PID

4: path ← readlink(/proc/pid/exe)

5: if path ∈ protected_exec_paths then return REJECT_EXEC

6: return ALLOW

...   

...

Algorithm 2: CWP classification (cwp_classify), run only after CPM allows

1: tier ← lookup(workloads, pid), else by resolved path; if none return ALLOW

2: if tier = PATH then return REJECT_PATH

3: if path or registry lookup fails then return REJECT_HASH    {fail closed}

4: if SHA256(file) ≠ expected then log “Identity Verification Failed”; return ALLOW

5: return REJECT_HASH

...

• Safety of the gates.

Let $\mathcal{P}$ be the set of processes that CPM protects: PID 1, kernel threads, registered PIDs and processes whose resolved executable is on the protected list, which includes systemd, kbd and kb-checker. Let $\mathcal{W}$ be the CWP-registered workloads whose identity check passes (a PATH-tier match, or a HASH-tier binary whose SHA-256 equals its registered digest).

Proposition 1.

For any sequence of containment requests from any decision path (operator, policy engine or swarm), no process in $\mathcal{P}\cup \mathcal{W}$ is written to the containment map at a level above zero, and none is killed by a TERMINATE decision.

Proof 

(Proof sketch). The containment map is written only by the sensor’s command handler, and every request with level $\ell >0$ passes Algorithm Section 6 and then Algorithm Section 6 before the write; a rejection returns without writing. Algorithm Section 6 rejects every member of $\mathcal{P}$, including when /proc/pid/exe cannot be resolved. Algorithm Section 6 rejects every member of $\mathcal{W}$, and fails closed when the path or registry lookup fails. Requests with $\ell =0$ only delete entries. TERMINATE’s SIGKILL is sent only after the sensor acknowledges a successful level-4 write, and through a pidfd opened before the request, so it reaches only a process that passed both gates. No other code path writes the map, so the property holds whatever the decision layer requests. It assumes an uncompromised kernel and sensor, which is the threat model of Section 3.    □

• Rate limiting.

A token bucket (capacity 100, refill one token per 10 ms) is kept per 〈tgid, start_time, resource〉 in a 10,240-entry LRU map (Algorithm Section 6). The start time stops a reused PID inheriting an exhausted bucket, and per-resource keys stop an attacker from spreading activity to stay under a flat per-PID limit. Tier-1 events (credential changes, capability probes, TLS plaintext) are never throttled, and dropped events are reported as a summary count.

• TERMINATE and the sensor acknowledgement.

Levels 1–3 are enforced entirely by the hooks. Level 4 adds a SIGKILL sent by kbd, and because a kill cannot be undone it is guarded twice. Before sending level 4, kbd pins the target with pidfd_open and applies its own copy of the CPM and CWP rules: PID 1, kernel threads, the protected-executable list (the sensor’s floor plus the packaged /usr/bin and /usr/sbin paths) and the loaded workload registry, failing closed when it cannot classify the process. It then registers for the sensor’s reply and sends the command. The sensor answers every containment command with a CONTAINMENT_ACK that reports what its own gates and the map write did (Table 7, Figure 5 and Figure 6). kbd kills, through the pinned pidfd, only on applied; a refusal, an unknown code or no reply within 3 s means no kill, and a PID whose request went unanswered is locked out for 30 s so that a late reply cannot answer a newer request. Every non-applied decision is written to the audit log as CONTAINMENT_REFUSED_BY_SENSOR. A sensor that predates the acknowledgement never replies, so TERMINATE is refused until the sensor is upgraded.

...

Algorithm 3: Token-bucket throttle (in eBPF)

1: key $\leftarrow \langle$tgid, start_time, resource〉; b ← lookup or insert $\{C,\mathrm{now},0\}$

2: b.tokens $\leftarrow \min (C,\mathrm{b}.\mathrm{tokens}+\lfloor (\mathrm{now}-\mathrm{b}.\mathrm{last})/\Delta \rfloor )$

3: if b.dropped $>0$and b.tokens $>0$then emit DROPPED(b.dropped); b.dropped $\leftarrow 0$

4: if b.tokens $>0$then b.tokens$--$; return ALLOW

5: b.dropped$++$; return THROTTLE

...

7. kb-Control-Plane

kbd keeps per-process state in an in-memory L1 sync.Map, authoritative for reads, backed by an L2 SQLite database in WAL mode written by a single goroutine through a 4096-entry channel, so ingestion never blocks on disk I/O. On a process exit both layers are flushed, so a reused PID inherits nothing. An upsert preserves any active containment level; an earlier version reset it to NONE on every telemetry update.

• Audit log.

Every enforcement action, policy reload and agent decision is appended to the chain of Eq. 10. Verification is exposed through an HTTP route, a gRPC method and kbctl audit verify. Our review found that VerifyChain did not check rows.Err() after iterating, so an I/O error mid-scan looked like a valid, shorter chain. It now returns the error, with a fault-injecting regression test.

...

Algorithm 4: Audit chain append and verification (internal/audit)

Log(action, subject, actor, reason):

1: lock; $ts\leftarrow$ now; $c\leftarrow ts|$action$|$subject$|$actor$|$reason$|$prev

2: $h\leftarrow \mathrm{SHA}256\left(c\right)$; insert row with (prev, h); prev $\leftarrow h$

Verify():

3: prev ← “genesis”; count $\leftarrow 0$

4: for each row in id order do

5:    if scan error then return (false, count, error)

6:    if $\mathrm{SHA}256\left(\mathrm{fields}\right|\mathrm{prev})\ne$ row.hash then return (false, count, “chain broken”)

7:    prev ← row.hash; count ← count$+1$

8: if the cursor reports an error then return (false, count, error)    {the fixed defect}

9: return (true, count, none)

...

...

Algorithm 5: Beacon detector, per flow (internal/detection)

1: $w\leftarrow$ window[(pid, address, port)] (create if absent)

2: if w has a previous timestamp then append the interval to w (keep the last 100)

3: if the event falls in the current 60 s bucket then count ← count$+1$

4: else fold count into Welford $(\mu ,M_2)$; $S\leftarrow \max (0,S+\mathrm{count}-\mu -\sigma /2)$; open a new bucket

5: $H\leftarrow$ entropy of the intervals over five bins (3.0 if fewer than 10 samples)

6: cusum ← (buckets $\ge 5$) ∧ ($\sigma >0$) ∧ ($S>5\sigma$)

7: return beacon $=(H<1.2)\wedge$ cusum    {alerts debounced to one per flow per 5 min}

...   

• Policy and workloads.

ReloadPolicy swaps a new policy engine under an RWMutex without restarting. The critical-workload registry can be Ed25519-signed; when a public key is configured, a missing or invalid signature is rejected and the last good registry kept. Automatic NAMESPACE containment on a beacon alert is opt-in per process, because a statistical heuristic should not gain enforcement authority by default. Thresholds and enforcement options are set per process name (for example, nginx uses 55/85 instead of 40/75), and paths listed in the policy only add to a compiled-in floor of sensitive paths and can never remove it. The shipped defaults are listed in Appendix D.

• Internal structure and interfaces.

kbd is organised as Go packages for socket I/O and wire decoding (ipc), two-layer storage (store), per-process policy (policy), the audit chain (audit), beacon detection (detection), translation of decisions into sensor commands (enforcement), a client for the watchdog (checkerclient) and the orchestrating object with its APIs (controlplane). Table 8 lists the two external interfaces. Both are reachable only locally: gRPC on the root-owned kba.sock, and HTTP bound to loopback with a CORS allow-list. State-changing HTTP routes require a bearer token compared in constant time; if no token is configured they refuse every request rather than run unauthenticated.

8. kb-Aads: The Agent Swarm

The swarm is a set of Ray actors sharing a common base class. The Patroller dispatches a PID to a Hunter pool when its score first crosses 40. The Judge opens a consensus round, spawns a fresh Jury pool and gates the Executor on Eq. 7 (Algorithm Section 8); a crashed juror is treated as an absent vote, not a veto. The Containment agent chooses the level with the trained policy, and the militia applies CGROUP → SECCOMP → NAMESPACE → TERMINATE strictly in order, halting at the first failure. The Healer is deliberately rule-based: it restores a process only when it is SAFE, scores below 20 and has been contained for 60 ticks, because no ground truth for restore outcomes exists. A SwarmRegistry lets the Judge locate agents and apply the courthouse verdict. On a test host the swarm started nine agents with no errors. Table 9 summarises the roles.

• Integration status.

Every role in Table 9 is implemented and covered by the 68 swarm tests, but release 1.0.0 does not yet connect them into a live decision loop. The Patroller hands a flagged PID to the Hunter, whose investigation is still a stub, and no live code path yet calls the Judge’s consensus round, the Containment policy or the militia; the orchestrator leaves the coupling of a quorum decision with a containment level as an open integration step. In the released system, live enforcement therefore comes from the control plane’s policy engine and from operators, and the swarm’s contribution is the trained policies evaluated in Section 14.    

...

Algorithm 6: Judge consensus round

1: pool ← spawn n Jury actors (n from configuration); register each

2: results ← gather(vote(alert) for each juror, return_exceptions)

3: votes ← results that are not exceptions    {crash ⇒ absent vote}

4: if votes is empty then return    {round skipped}

5: if $Q\left(\mathrm{votes}\right)>{\displaystyle \frac{1}{2}}$ then Executor.quarantine(alert)

...   

...

Algorithm 7: Militia escalation (command_squad)

1: stages ← [CGROUP, SECCOMP, NAMESPACE, TERMINATE] truncated to the target level $\ell \in \{1,\dots ,4\}$

2: for each stage do

3:    spawn one squad member for the stage and register it

4:    result ← await member.execute(pid, reason)    {stages never race}

5:    if not result.success then break    {halt; no retry}

6: return the stage reports

...   

...

Algorithm 8: Courthouse check of an agent (assess_severity)

1: $h\leftarrow$ registry.lookup(agent); if none then return TERMINATE

2: $s_0\leftarrow h$.status(); if$s_0$.status ≠ active or$s_0$.errors $\ge 5$ then return RESTART

3: wait $\tau =3$ s; $s_1\leftarrow h$.status()

4: if $s_1$.uptime $\le s_0$.uptime then return RESTART    {agent is not advancing}

5: return HEALTHY

...

• Training data.

No eBPF-captured attack corpus existed, so all six of ADFA-LD’s attack families [12] were mapped to five KB scenarios and target levels, with benign data from ADFA-LD Normal traces and live /proc telemetry (Table 10, Figure 7). Each row carries the five wire-level features of o. For a trace of length n with syscall diversity $\delta =\left|\right\{\mathrm{distinct}\mathrm{calls}\left\}\right|/n$ and longest run of a repeated call r, each statistic is standardised against the mean and standard deviation of the ADFA-LD Normal traces, and

$$\begin{array}{c}\overline{z}=\frac{1}{3}\left(|z_n|+|z_{\delta }|+|z_r|\right),\mathrm{score}=\min (100,25\overline{z}),\\ \Delta \mathrm{score}={\mathrm{clip}}_{[-100,100]}\left(25({\overline{z}}_2-{\overline{z}}_1)\right),\end{array}$$

(11)

where ${\overline{z}}_1,{\overline{z}}_2$ are computed on the two halves of the trace. The zone feature is $\max \left(\mathrm{floor},\min (2,\lfloor \mathrm{score}/40\rfloor )\right)$, with a per-scenario floor so that a labelled attack is never SAFE. The rows are split 70/15/15 into training, validation and test sets, stratified by class. Training used RLlib PPO with class-balanced sampling (category first, then row), so the rare attack classes receive equal attention.

9. kb-Checker and the Boot Sequence

kb-checker holds no persistent state and opens no network listener. It hashes the JIT-compiled BPF programs, reconciles the kernel containment map with the control-plane database and heals differences, requires the exec event of a spawned /bin/true within 3 s, and flags hooks averaging over 500 ns. When it cannot recover cleanly it escalates from SIGKILL of the sensor, to detaching BPF links, to an iptables lockdown that keeps only loopback.

In the boot design, order is a security property enforced with plain systemd dependencies (Figure 8). kbd binds its sockets and signals readiness (Type=notify); the watchdog requires it, takes a PID-file lock and runs blocking audits; and the swarm requires the watchdog, so a failed audit prevents the decision layer from starting (goal G5). Release 1.0.0 relaxes this while the watchdog’s recovery path is repaired: kb-checker is installed but not started by kbctl up, and the swarm unit, which is installed but not enabled, depends only on kbd. The boot gate is therefore part of the design but not enforced by the packaged units (Section 17).

Table 11. Audit loops of kb-checker.

Check	Period	Method
BPF bytecode integrity	60 s	SHA-256 of each loaded program obtained through bpf_obj_get_info_by_fd
Control-plane health	5 s	gRPC health check against kbd
Swarm health	30 s	status query of the agent swarm
Sensor liveness	60 s	spawn /bin/true and require its exec event within 3 s
Containment-map integrity	60 s	compare the kernel map with the control plane’s state and heal differences
Hook latency	60 s	warn when a program’s average run time exceeds 500 ns

Table 11. Audit loops of kb-checker.

Check	Period	Method
BPF bytecode integrity	60 s	SHA-256 of each loaded program obtained through bpf_obj_get_info_by_fd
Control-plane health	5 s	gRPC health check against kbd
Swarm health	30 s	status query of the agent swarm
Sensor liveness	60 s	spawn /bin/true and require its exec event within 3 s
Containment-map integrity	60 s	compare the kernel map with the control plane’s state and heal differences
Hook latency	60 s	warn when a program’s average run time exceeds 500 ns

• Fallback ladder and failure handling.

Escalation is suppressed for a 15 s start-up grace period, which removed false lockdowns on cold boot. After that, an integrity violation first stops the sensor through systemctl; only if that fails does the watchdog kill the sensor process (pkill -9), remove the pinned BPF objects under /sys/fs/bpf, and set the iptables policies to drop all traffic except loopback, so an operator at the console can still intervene. Two other failures are handled by construction. If the sensor cannot load or attach its programs, for example because bpf is missing from the active LSM list, it exits before attaching anything and systemd restarts it; the host stays up but unprotected, and the failure is visible in the unit status. The watchdog orders itself after the sensor with Wants= rather than Requires=: a real boot test showed that Requires= made a sensor restart issued by the watchdog’s own recovery also stop the watchdog, which then misread its own termination as a failed recovery and escalated to a false lockdown.

10. Implementation

Table 12 summarises the implementation, and Appendix E reproduces the code behind the main mechanisms. The sensor is compiled with clang -target bpf; bpftool generates a skeleton that the user-space loader links against libbpf. The bridge reconnects to kbd with exponential back-off between 100 ms and 5 s, so a control-plane restart never requires reloading the hooks. Wire messages are packed little-endian structures whose sizes are locked by byte-exact tests on both the C and Go sides, because a silent mismatch between the two once dropped every containment command. The KernelBorderlands gRPC service offers 13 RPCs, including process and zone queries, event and alert streams, SetContainment, SubmitAgentDecision, audit verification and export, zone override, and policy and workload reload. Generative AI assistance used during development, evaluation and writing is described in the Acknowledgments.

11. Deployment, Portability and Requirements

KB is meant to run on the Linux servers an organisation already has, not on a specially built kernel. This section describes how one sensor binary runs across kernels, which kernel features it needs, how BPF-LSM is enabled, which distributions are supported, and how the packaged release is installed.

11.1. Software Stack

Table 13 lists the software each subsystem needs. Everything is free and open source, and a deployment needs no licences or extra hardware, since KB runs on the server it protects.

11.2. Compile Once, Run Everywhere

An eBPF program reads kernel structures such as task_struct and cred directly, and their layout changes between kernel versions and vendor builds. KB uses CO-RE [5] so that one compiled object runs on every supported kernel without per-host compilation or a kernel module.

• One header for all kernels. The build generates vmlinux.h from the build host’s BTF (bpftool btf dump file /sys/kernel/btf/vmlinux format c) instead of using version-specific kernel headers.
• Relocatable field accesses. Kernel fields are read only through BPF_CORE_READ(): the parent’s thread-group ID (task->real_parent->tgid) and the new credentials in commit_creds (uid, gid, euid, cap_effective). Clang (-g -O2 -target bpf) records each access as a relocation instead of a fixed offset, and -g keeps the BTF that relocation needs.
• Fix-up at load time. When the sensor starts, libbpf matches the relocations against the running kernel’s /sys/kernel/btf/vmlinux and patches the correct offsets into the bytecode before the verifier sees it.
• All-or-nothing load. If BTF is missing, a relocation cannot be resolved, or the kernel rejects a program or map type, the skeleton load fails and the sensor exits before attaching any program. If loading succeeds but attaching fails, for example because bpf is not in the active LSM list, the sensor also exits. A host is therefore never left half-instrumented.

Between load and attach the sensor fills its maps (sensitive paths, the CPM floor and the CWP registry) and registers itself as protected, so no hook runs before protection is in place.

Table 14. Kernel features required by the sensor and the control plane.

Feature	Used for	Since Linux
LRU hash map	rate limiter, per-process state	4.10
BTF (CONFIG_DEBUG_INFO_BTF)	CO-RE relocation	5.4
bpf_probe_read_kernel/_user	reading kernel and user memory	5.5
BPF-LSM (CONFIG_BPF_LSM, bpf in lsm=)	the five enforcement hooks	5.7
BPF ring buffer	the single 1 MB event stream	5.8
bpf_d_path	path of the opened file in lsm/file_open	5.10
pidfd_open, pidfd_send_signal	the TERMINATE kill in kbd	5.3
cgroup v2	level 1 (CGROUP) throttling	4.5
Minimum kernel for the full feature set		5.10

Table 14. Kernel features required by the sensor and the control plane.

Feature	Used for	Since Linux
LRU hash map	rate limiter, per-process state	4.10
BTF (CONFIG_DEBUG_INFO_BTF)	CO-RE relocation	5.4
bpf_probe_read_kernel/_user	reading kernel and user memory	5.5
BPF-LSM (CONFIG_BPF_LSM, bpf in lsm=)	the five enforcement hooks	5.7
BPF ring buffer	the single 1 MB event stream	5.8
bpf_d_path	path of the opened file in lsm/file_open	5.10
pidfd_open, pidfd_send_signal	the TERMINATE kill in kbd	5.3
cgroup v2	level 1 (CGROUP) throttling	4.5
Minimum kernel for the full feature set		5.10

11.3. Enabling BPF-LSM

Telemetry needs only eBPF and BTF, but enforcement needs the BPF Linux Security Module. Two conditions must hold: the kernel is built with CONFIG_BPF_LSM=y, and bpf appears in the list of active LSMs. Many distributions build the option but leave bpf out of the default list, so it must be added to the lsm= kernel parameter (Listing ).

11.4. Distribution Compatibility

Table 15 lists the distributions KB targets. Native distributions were tested and deployed with the packaged release and meet every requirement. Target distributions ship stock kernels with the required features but have not been validated end to end. Verify marks vendor kernels whose BTF or BPF-LSM configuration depends on the exact build; their version numbers understate their eBPF features because enterprise kernels backport them, so the checks of Listing  are authoritative. “Boot param” means that BPF-LSM is compiled in but bpf must be added to lsm=.

11.5. Packaging and Service Units

Release 1.0.0 is built from one install target into an Ubuntu .deb and an Arch Linux package, published with SHA-256 checksums and with field manuals for both distributions. Installation provisions the kb group, the operator account and the configuration under /etc/kb, but starts nothing; kbctl up starts the stack. Table 16 lists the systemd units as shipped.

Figure 9 shows how the units, sockets and local network endpoints fit together on one host. All internal sockets live under /run/kb/; the only TCP listeners are bound to loopback, apart from the operator’s SSH port.

12. End-to-End Containment Path

Figure 10 follows one malicious process from its first kernel event to an enforced and audited containment. The steps cross every trust boundary in the system, and each boundary has a check that does not depend on the layer above it: the verifier for the hooks, the gates for the map write, the LSM hook for the operation, and the hash chain for the record. Steps 6–7 show the designed swarm path; in release 1.0.0 the policy engine or an operator issues the containment request directly (Section 8), as in the live capture of Section 14.

13. Operator Interfaces and Packaging

kbctl is a Go gRPC CLI for isolation and restore, zone override, audit verification and export, policy reload, workload signing, and starting or stopping the stack. kb-tui is a Rust terminal console reached through a dedicated sshd instance on port 2222 with a forced command, so authentication is handled by OpenSSH rather than custom code. The web dashboard requires a bearer token for isolate (level 3, reversible), kill (level 4) and restore, and kb-mcp exposes a read-only statistics tool (event rate and number of active processes) to LLM tooling over the Model Context Protocol. KB is distributed as an Ubuntu .deb and an Arch Linux package built from one install target; the packages provision the kb group and the operator account but start nothing until an operator runs kbctl up.

Table 17. Operator interfaces

Interface	Functions
kbctl (Go, gRPC)	process isolate –level (default NAMESPACE), zone override, audit verify|export, policy reload, workload reload|keygen|sign, stats; stack control up|down|status; dashboard up|down|status|url|open; ssh up|down|status|connect|add-key; tui
kb-tui (Rust, ratatui)	four views: Processes, Alerts, Agent Activity and Query Console, with confirmed containment actions; reached over sshd@kb-operator on port 2222 with a forced command, and every session is recorded in the audit chain
kb-dashboard (React, TypeScript)	Processes, Zone Topology, Alerts, Telemetry, Services, Containment, Consensus Log, Rogue Management, Console and Settings; Isolate and a two-step Kill are separate actions
kb-mcp (Go)	Model Context Protocol server over stdio with one read-only tool, kb.get_statistics

Table 17. Operator interfaces

Interface	Functions
kbctl (Go, gRPC)	process isolate –level (default NAMESPACE), zone override, audit verify|export, policy reload, workload reload|keygen|sign, stats; stack control up|down|status; dashboard up|down|status|url|open; ssh up|down|status|connect|add-key; tui
kb-tui (Rust, ratatui)	four views: Processes, Alerts, Agent Activity and Query Console, with confirmed containment actions; reached over sshd@kb-operator on port 2222 with a forced command, and every session is recorded in the audit chain
kb-dashboard (React, TypeScript)	Processes, Zone Topology, Alerts, Telemetry, Services, Containment, Consensus Log, Rogue Management, Console and Settings; Isolate and a two-step Kill are separate actions
kb-mcp (Go)	Model Context Protocol server over stdio with one read-only tool, kb.get_statistics

14. Evaluation

14.1. Containment and Jury Policies

The first PPO run reached 97.8% overall test accuracy but only 60.0% on CGROUP and 70.4% on SECCOMP. The cause was in the features, not the model: two attack scenarios shared one engineered event-type code and zone floor. Giving each scenario its own code lifted every attack class to 97.1–100% and cut under-containment from 1.1% to 0.0% (Figure 11). Overall accuracy fell to 84.4% because the benign class, 87% of the test set, fell from 100% to 82.2%. We accept this trade deliberately: a false positive costs a review or a restore, while a false negative costs a compromise, which is exactly the asymmetry of Eq. 5.

The Jury collapses the same labels to CONTAIN/ALLOW and uses the same splits. It reached 100.0% validation and test accuracy with zero false negatives (Table 18). Training is not seeded, so figures vary slightly between runs (an earlier run scored 99.8% and 99.4%), but zero false negatives held in every run observed. The binary task is easier because the attack classes that the five-way policy must separate collapse into one label.

14.2. Live Detection and Response

We captured telemetry from a live run on an Ubuntu virtual machine during a controlled attack simulation: 188 rounds at a 3 s interval, each touching the file, memory and network dimensions of one long-lived process. The capture holds 10,440 sensor events (7,703 hook events), 489 zone transitions and 409 audit rows. The attack process escalated SAFE → SUSPICIOUS → BORDERLANDS six times, and no other process reached BORDERLANDS. Each time, the control plane issued a CGROUP throttle within about 1 ms of the BORDERLANDS audit record, and the sensor logged it as applied 0.53–1.90 s later, with a mean of 1.35 s (Figure 12). These delays come from journal timestamps and so include logging latency.

Privilege-change events dominate the hook stream (51.4%), and the sensor flagged 3,563 hook events (46%) as sensitive (Figure 13). The ring buffer reported overload 1,863 times at 101–270 events/s, with 40,761 events dropped in total, which is the load that the rate limiter and the Tier-1 exemption are designed for. Half of the watchdog’s 855 log lines are health checks and a quarter are recovery actions, reflecting ten sensor restarts during the capture. These are feasibility traces rather than a detection-rate benchmark: one attack script was used, the benign baseline is short, and watchdog-forced restarts leave gaps in the sensor stream.

14.3. Functional Scenarios

Table 19 summarises the live scenarios run against a running sensor and control plane. The three attack chains exercise the rule engine end to end, and the gate scenarios confirm that protection holds even while the telemetry channel is saturated.

14.4. Test Case Study

Testing ran at four levels because each level caught defects the others missed: unit tests (Go with in-memory SQLite, pytest with injectable fake Jury and militia classes so that consensus logic runs without a Ray cluster, cargo test, and C tests for the behaviour engine); byte-exact wire tests on both sides of the C/Go boundary; live-sensor scripts that drive real hooks (Table 19) and verify CPM and CWP against a running sensor; and boot tests of the unit chain. Table 20, Table 21 and Table 22 list representative cases by area, each backed by a named automated test or live script in the repository; all pass on release 1.0.0.

14.5. Test Suites and Implementation Size

Testing ran at four levels, because each level caught defects the others missed: unit tests, byte-exact wire-contract tests, live-sensor scenarios and end-to-end boot tests of the unit chain (Figure 14). The control plane has 164 Go tests and the swarm 68 pytest tests, with injectable fake actors so consensus logic is testable without a Ray cluster. The live script triggers all event types and three multi-stage attack chains against a running sensor; separate scripts verify CPM and CWP against it. The hand-written implementation, excluding generated code and vendored libbpf, is about 22,000 lines.

14.6. Run-Time Overhead

We measured overhead on a workstation with an Intel Core Ultra 9 275HX (24 threads) running Linux 7.2 with BTF, BPF-LSM and kprobes enabled. The installed kbd and sensor services ran with all 18 sensor programs loaded: 5 BPF-LSM hooks, 2 kprobes, 2 uprobes and 9 tracepoints, including raw_syscalls/sys_enter. Each workload ran five times, alternating between KB stopped and KB running, with the CPU governor fixed to performance and the state database reset before each KB run; we report medians (Table 23, Figure 15).

The added cost is a roughly fixed amount per hooked operation: 38 ns on every system call, from the sys_enter hook that feeds the syscall-entropy dimension, a few hundred nanoseconds for file, network and memory operations that have their own hooks, and 26 $\mu$s per process creation. In relative terms this is large for a null system call but disappears in real work: a parallel compile and a CPU-bound benchmark both changed by less than 1%, within run-to-run noise. Resident memory was about 28 MB for kbd and 12 MB for the sensor. The micro-benchmarks are single-process floods, so the sensor’s token bucket (burst 100, refilled at 100 per second per process, start time and resource) dropped and counted 150,000–190,000 events per run, which is its designed behaviour. On an earlier 4-vCPU virtual machine where the LSM and kprobe programs could not be loaded, the absolute per-operation costs were about twice as high, and a compile slowed by 14%; the difference between hosts shows that overhead should be measured on the deployment hardware. Aggregating sys_enter counts in a kernel map instead of per event would remove most of the remaining per-syscall cost.

Every individual run is listed in Appendix F.

14.7. Threats to Validity

The policy results come from ADFA-LD traces mapped to KB’s features, not from KB’s own sensor, so they show that the feature design and reward separate the attack classes, not that the deployed system detects those attacks at the same rate. The test split shares the generation process of the training data, and each of the four attack levels has only 25–35 test samples, so per-level accuracy has wide uncertainty. The live capture used a single attack script on one virtual machine, and the full-hook overhead was measured on a single host and kernel. A labelled eBPF corpus and an independent benchmark are needed before the detection rate can be stated.

15. Discussion

• Cost per event.

Every kernel-side operation is constant time and bounded by the verifier (Table 24), so the per-event cost does not grow with load (measured in §Section 14), and all kernel maps are sized at load time so a hostile process cannot exhaust them. User-space state grows with the number of live processes and is flushed on exit; only the audit log grows without bound, by design.

• Memory footprint.

Table 25 lists the fixed and growing structures. All kernel-side memory is fixed when the maps are created, so a hostile process cannot exhaust it, and the LRU maps age out stale entries. User-space state scales with live processes and is flushed on exit. Only two structures grow without bound: the audit log, which is append-only so that history cannot be lost, and the per-flow detector windows, which still need time-based eviction for idle flows.

• Design choices.

Several deliberate choices trade generality for assurance. Unix sockets instead of TCP keep the internal data path off the network. SQLite in WAL mode with a single writer needs no listener and removes lock contention, while the L1 map absorbs reads. systemd dependencies make the boot gate exactly as trustworthy as systemd itself and easy for operators to inspect. The CPM and CWP checks run in the sensor’s user-space bridge rather than in eBPF, because hashing a binary and resolving /proc/pid/exe cannot be done safely in the kernel; the cost is a few microseconds per containment decision, which is rare compared with telemetry. Containment is a single-step decision because that is how the control plane asks the question (which level for this process now?), and it keeps training stable on a small dataset. The Healer stays rule-based, and beacon-triggered containment stays opt-in, because neither has ground truth that would justify giving a learned or statistical rule enforcement authority.

• Learned decisions under a deterministic floor.

The swarm is advisory: CPM and CWP sit below every decision path, the policy engine can enforce without the swarm, and the reward shape encodes the asymmetry between a false positive and a missed attack. This layering means that a mistaken or compromised decision layer can at worst act against an unprotected process: the Healer or an operator can lift levels 1–3, and every action, including a TERMINATE kill, is recorded in the audit log.

• Lessons.

Four lessons from building KB generalise beyond it. Live tests find what unit tests cannot: the most serious defects, namely mismatched wire constants that silently dropped every containment command, a socket design that let telemetry bursts kill the control path, and a missing readiness notification that froze the boot chain, all passed their unit tests and were found only on a running system. Order checks deliberately and fail closed: checking full quarantine before resolving a path, rejecting a HASH-tier containment when the path cannot be resolved, and surfacing a cursor error decide whether a security property actually holds. Look at per-class metrics: a 97.8%-accurate model was failing on two of five classes, and the fix was in feature engineering, not in the learning algorithm. Claims decay: re-checking earlier audit findings, and this paper’s own claims, against the current source repeatedly found statements that had become out of date.

16. Security Audit and Defects Found

We re-verified every previously reported open defect directly against current source rather than carrying old claims forward. Most were already fixed: an unauthenticated HTTP API with wildcard CORS (now a constant-time bearer token and an origin allow-list), the telemetry update that reset containment, the LSM fail-open ordering, a custom SSH server without throttling (replaced by OpenSSH), a hard-coded dashboard host, unvalidated containment RPCs and three Jury consensus defects. Only the rows.Err() gap in the audit verifier was genuinely open, and it is now fixed. Audit findings decay as code moves and must be rechecked at every revision.

Integration testing on real hosts found defects that every unit test had passed (Table 26). Several would have disabled a security property while reporting success.

17. Limitations and Future Work

We state the limitations plainly, because a security system is defined as much by what it does not do as by what it does.

• Training data. The policies are trained on ADFA-LD, a public stand-in: it covers no memory-exploit scenario, and there is no mapping yet from the sensor’s live event stream to the training features. An attack lab that records labelled eBPF telemetry is the next step, followed by a detection-rate benchmark.
• Swarm integration. The swarm’s roles are implemented and tested, but in release 1.0.0 no live path yet connects a flagged process to the consensus round, the Containment policy and the militia (Section 8). The Hunter is a stub planned as a fine-tuned, tool-calling language model; the Healer needs restore-outcome labels before it can be learned; and the courthouse reaches only the restart verdict until peer-drift and boundary-violation detectors exist.
• Watchdog and boot gate. The watchdog’s recovery path still causes sensor restarts under load, so release 1.0.0 keeps it down and the swarm unit no longer requires it; the boot gate of Section 9 is therefore not enforced by the packaged units until the escalation logic is hardened.
• Kill under load. The sensor’s acknowledgement shares the telemetry socket, so under a telemetry flood it can be lost; TERMINATE then fails closed and leaves the process contained but alive. Only TERMINATE waits for the acknowledgement; for levels 1–3 a sensor refusal is audited but not returned to the caller.
• Overhead. Overhead was measured on one workstation and kernel with synthetic workloads; it should be repeated on server hardware with a production-like service.
• Detection inputs. The beacon detector uses connection frequency as a proxy for byte volume, because connect() telemetry carries no payload size; detector windows and the rate limiter keep state in memory, and idle flows are not yet evicted.
• Behaviour rules. Seven of the 19 shipped rules need evidence flags or sequence steps the sensor does not yet produce (shell spawn, ptrace, anonymous executable mappings, exec from /tmp, connect bursts), so they cannot fire (Appendix C).
• Coverage and scope. Operator additions to the CPM executable list have a receiver in the sensor but no sender yet, so the floor is compiled in. kb-mcp has not been audited. All policy is host-local, with no fleet management.
• Trust domain. Any same-host defence shares the kernel’s trust domain; a full kernel compromise is beyond it.

Future work follows directly from these limits:

• an attack lab that captures labelled eBPF telemetry from scripted attacks in isolated virtual machines, so the policies are retrained on KB’s own observation surface;
• a live decision loop that couples the Jury’s quorum with the Containment policy and the militia, with the Hunter built as a tool-calling agent using kb-mcp as its interface;
• restore-outcome labels for a learned Healer, and drift and boundary detectors for the full courthouse;
• multi-step escalation episodes in which the policy observes the effect of each stage;
• byte-level exfiltration telemetry from sendmsg/write accounting;
• server benchmarks (for example web, database and kernel-build workloads) and a hardened watchdog that restores the boot gate;
• fleet operation with a signed central policy store and aggregated audit chains; and
• moving the last line of defence to an out-of-band hardware attestation module, which is being pursued as separate work.

18. Conclusion

Kernel Borderlands shows that a Linux runtime defence can sit where attacks actually happen, inside the kernel, while keeping every automated decision proportionate, gated, auditable and supervised. Its contribution is the combination: graded BPF-LSM enforcement behind authorisation gates that the decision layer cannot bypass, a hash-chained control plane, a swarm whose containment and jury decisions are learned and checked by quorum, and a watchdog that gates the boot sequence. The policies reach 97–100% accuracy on every attack class with no under-containment and no Jury false negatives on held-out data, and the live capture shows the complete loop from kernel event to enforced, audited containment.