Plugin Tier Security & Hive Immunity
Plugin Tier Security & Hive Immunity
Author: Joel Johnston Date: 2026-04-06 Domain: Security Architecture Stroke Timeline: Pre-stroke design
Abstract
Two interlocking security systems for roboNet. Plugin Tier Security defines a 5-tier trust hierarchy that constrains what plugins can do based on their provenance and verification status. Sentinel is a distributed behavioral immune system — each node monitors every peer, detects deviations from baseline, and coordinates graduated responses through mesh consensus. No central security authority. No single point of failure. Patent candidate — no known prior art for distributed behavioral baselining with multi-node quorum approval in mesh networks.
Part I — Plugin Tier Security
The Problem
roboNet plugins extend the mesh's capabilities. A plugin can be:
- A proprietary business process from a verified enterprise deployer
- An open-source community contribution
- An experimental tool under development
- An untested script from an unknown source
- Malicious code disguised as a plugin
These categories require radically different security postures. One security policy for all plugins means either:
- Applying maximum restriction to trusted code (unusable)
- Applying minimum restriction to untrusted code (dangerous)
The tier model resolves this by matching security posture to provenance and verification level.
The Five Tiers
Tier 0 — Kernel
Who: Core mesh primitives only. Hardcoded at compile time.
Access: Full mesh. All capabilities. All resources.
Modification: Not possible at runtime. Changes require a core release.
Examples: Leader election, quorum consensus, HCTH trust engine, Sentinel core.
Tier 0 is not a plugin category — it is the mesh itself. The tier exists in the model to define the top of the capability hierarchy and make explicit that all plugin tiers operate below it.
Tier 1 — Trusted
Who: Signed plugins from verified authors. Verification requires: code review, identity binding (Ed25519 key registered with mesh operator), and security audit.
Access: Full mesh access. All standard operations. Participation in quorum for non-destructive decisions.
Resource limits: Configurable per-plugin, no hard cap.
Blast radius: Bounded by operator policy, not enforced by sandbox.
Examples: Forge orchestration layer, Chain-Builder pentest framework, Waggler worker coordinator.
Tier 1 plugins are trusted because their authors are accountable. A Tier 1 plugin from a compromised author is revoked by revoking the author's signing key — all plugins signed with that key drop to Tier 3 pending re-verification.
Tier 2 — Standard
Who: Community plugins. Known source, not individually audited.
Access: Sandboxed execution. Limited mesh API surface. No quorum participation. No access to trust engine or Sentinel internals.
Resource limits: CPU 25%, memory 512MB, network I/O 10MB/s (configurable).
Blast radius: Sandbox boundary. A failing Tier 2 plugin cannot affect other plugins or core operations.
Examples: Community-developed data processors, third-party AI model adapters, integration plugins.
Tier 3 — Experimental
Who: Plugins under development. May be authored by mesh operators but not yet ready for Standard verification.
Access: Isolated execution. Read-only mesh status. No write operations. No network I/O outside the plugin sandbox.
Resource limits: CPU 10%, memory 256MB, no network I/O to mesh.
Blast radius: Execution sandbox only. Cannot affect any other component.
Examples: New plugins in development, plugins failing Tier 2 verification, downgraded Tier 2 plugins after violation detection.
Tier 4 — Raw Scripts
Who: Unvetted code. Operator-uploaded scripts with no provenance check.
Access: Read-only access to operator-specified data. No mesh access. No file system access outside designated temp directory.
Resource limits: CPU 5%, memory 128MB, 30-second max execution time.
Blast radius: Operator-designated temp directory only.
Examples: One-time data transformation scripts, ad-hoc analysis jobs, scripts from external sources being evaluated.
Tier Enforcement Architecture
Tier constraints are enforced at the execution layer, not the trust layer. A Tier 2 plugin cannot request capabilities above Tier 2 — the request is rejected before the plugin code executes.
Enforcement stack:
- Plugin registry records tier at installation time
- Capability resolver validates all capability requests against tier ceiling
- Execution sandbox enforces resource limits via OS-level controls (cgroups on Linux)
- Audit log records all capability requests, grants, and denials
A plugin that attempts to access capabilities above its tier generates an audit event. Multiple tier-ceiling violations within a time window trigger automatic downgrade.
Part II — Sentinel: Distributed Behavioral Immune System
The Problem
Static security rules (firewall rules, access control lists, signature-based detection) fail against:
- Novel attack patterns not in the signature database
- Legitimate credentials used maliciously (insider threat)
- Slow, low-signal attacks that stay below rule thresholds
- Compromised nodes that behave correctly most of the time
Biological immune systems solved this problem through a different approach: learn what normal looks like, then detect deviation from normal. A pathogen does not need to match a known signature. It needs to behave differently from what the body expects.
Sentinel applies this model to the mesh.
Behavioral Baselines
Each node maintains a behavioral baseline for every peer. The baseline is built from observation:
- Message frequency — how often does this peer send messages?
- Message size distribution — what is the typical payload size distribution?
- Capability request patterns — which capabilities does this peer typically request?
- Time-of-day patterns — when is this peer typically active?
- Command sequence patterns — what sequences of commands does this peer typically issue?
- Task completion rates — what fraction of accepted tasks does this peer complete successfully?
- Resource consumption curves — how does this peer's resource usage correlate with its task types?
Baselines are built over a configurable learning period (default: 72 hours of observation). After the learning period, Sentinel begins anomaly detection.
Anomaly Detection
Deviation from baseline is scored continuously. The deviation score is a weighted sum across all baseline dimensions:
deviation_score(peer) = Σ(weight_i × deviation_i(peer))
Weights are configurable per deployment. Default weights prioritize:
- Capability request anomalies (high weight — most indicative of compromise)
- Command sequence anomalies (high weight — hardest to fake)
- Resource consumption anomalies (medium weight — noisy but useful)
- Message frequency anomalies (low weight — legitimate variance)
Graduated Response
Sentinel does not have a binary "block / allow" response. Response is graduated by deviation score:
| Deviation Score | Response | Human Notification |
|---|---|---|
| 0.0 – 0.3 | Normal operation | None |
| 0.3 – 0.5 | Elevated monitoring (baseline recalculation check) | Dashboard indicator |
| 0.5 – 0.7 | Soft quarantine (capability restrictions applied) | Alert |
| 0.7 – 0.9 | Hard quarantine (task execution suspended) | Urgent alert |
| 0.9 – 1.0 | Disconnect proposal (requires quorum approval) | Critical alert |
Quarantine is reversible. A peer whose behavior returns to baseline exits quarantine. The exit is not automatic for hard quarantine — it requires sustained below-threshold behavior for a configurable period (default: 1 hour).
Quorum Approval for Disconnect
No single node can permanently disconnect a peer. The disconnect proposal is submitted to the mesh quorum. Default requirement: 2/3 of active quorum members must independently confirm elevated deviation scores for the same peer.
This prevents a compromised Sentinel node from using the security system as an attack vector (disconnecting healthy peers). A single rogue Sentinel node can generate a disconnect proposal but cannot approve it unilaterally.
The quorum requirement scales with the severity of the proposed action:
- Soft quarantine: local decision (no quorum required)
- Hard quarantine: simple majority confirmation
- Disconnect: 2/3 supermajority confirmation
- Permanent ban: unanimous confirmation
Multi-Node Correlation
When a peer's deviation score exceeds 0.5 on one node, that node broadcasts a correlation request: "I am seeing anomalous behavior from peer X — does anyone else?"
Other nodes that are also seeing elevated deviation from X respond with their own scores. The correlation engine aggregates multi-node observations.
A peer that shows normal behavior to most nodes but anomalous behavior to one node is likely a network partition issue, not a security threat. A peer that shows anomalous behavior to multiple nodes simultaneously is a genuine threat signal.
Multi-node correlation eliminates most false positives.
Biological Analogy
The immune system analogy is not decorative — it is the design model.
| Immune System | Sentinel |
|---|---|
| White blood cells | Sentinel instances (one per node) |
| Baseline immune tolerance | Behavioral baseline learning period |
| Antigen recognition | Deviation scoring |
| Inflammatory response | Graduated response (alert → quarantine → disconnect) |
| Adaptive immunity | Baseline evolution (baselines update as peers' behavior legitimately evolves) |
| Cytokine signaling | Multi-node correlation broadcasts |
| Lymph node coordination | Quorum consensus for high-risk responses |
The immune system does not have a central authority. Each white blood cell operates independently with local detection capability. Coordinated response emerges from signaling, not central command. Sentinel is designed on the same principle.
Prior Art Assessment
Literature search conducted April 2026 across security architecture papers, commercial security products (CrowdStrike, SentinelOne, Darktrace), and mesh/microservice security frameworks (Istio, Consul Connect).
Findings:
- Behavioral baselining: exists in endpoint detection products (SentinelOne, Darktrace)
- Multi-node correlation: exists in SIEM (Security Information and Event Management) products
- Distributed consensus for security decisions: exists in Byzantine fault tolerance literature
No equivalent found for: distributed behavioral baselining where each node independently evaluates every peer, with quorum consensus required for high-impact security decisions, operating without central coordination, in a peer-to-peer mesh network.
The specific combination of local-first behavioral baselining + multi-node correlation + quorum-gated responses + no central authority is novel.