Agent Immune: Three-Layer Defense for Autonomous Execution

Agent Immune is the security layer that prevents the Autonomic ecosystem from executing malicious code, running compromised dependencies, or leaking sensitive data. It operates as a three-layer defense that every code-touching workflow passes through.

Architecture

Layer 1: Dependency Scanning. Before any third-party package is installed, Immune queries the OSV database for known vulnerabilities. This runs on every Cargo.toml, package.json, requirements.txt, or go.mod that enters the system. Results are cached with a TTL of 24 hours. A dependency with a critical severity CVE blocks execution entirely — spine will not dispatch to Muscle until Immune returns a pass.

// agent-immune scan ./Cargo.lock
{
  "scanned_at": "2026-06-21T10:00:00Z",
  "manifest": "Cargo.lock",
  "dependencies": 142,
  "vulnerabilities": [
    {
      "id": "GHSA-xxxx-yyyy-zzzz",
      "package": "serde",
      "installed": "1.0.150",
      "fixed": "1.0.180",
      "severity": "HIGH",
      "summary": "Deserialization of untrusted data can cause memory exhaustion"
    }
  ],
  "scan_status": "blocked"
}

Layer 2: Sandboxed Execution. Code generated by an LLM or fetched from an untrusted source runs in a sandbox. The default sandbox uses seccomp to block system calls that are not in the allowlist: no execve, no ptrace, no mount. For higher-risk operations, Immune supports Firecracker microVM sandboxing — a lightweight VM that boots in ~125ms and provides hardware isolation. The sandbox level is configurable per workflow node.

The seccomp filter is defined as a BPF program that runs on every syscall:

{
  "sandbox": "seccomp",
  "allowed_syscalls": [
    "read", "write", "open", "close", "fstat",
    "mmap", "munmap", "brk", "exit_group"
  ],
  "blocked_syscalls": ["execve", "ptrace", "mount", "clone"],
  "action_on_violation": "kill"
}

Layer 3: Memory Verification. After execution, Immune verifies that the process did not access memory outside its declared scope. This is implemented as a post-execution audit of seccomp logs and, for Firecracker guests, a memory-dump inspection. OOM detection is included: if a sandboxed process is killed by the OOM killer, Immune records the event and escalates to Heart.

Standalone Mode

agent-immune scan ./Cargo.toml runs OSV dependency scanning and prints a JSON report of findings with severity, CVE ID, and fixed version. agent-immune sandbox --cmd "python generated_script.py" executes a command in the seccomp sandbox and returns the output only if all syscalls were allowlisted.

Integrated Mode

Spine calls Immune before every Tool node that executes generated code. The workflow definition includes a sandbox field (none, seccomp, firecracker) that determines the isolation level. Results are published as security.scan.completed events through Nerves. If a scan fails, the workflow enters its error handler — typically an approval gate that notifies a human.

Design Decisions

Seccomp is the default sandbox, not Firecracker, for a practical reason: startup latency. A seccomp-bpf filter compiles in microseconds and applies to a forked process. A Firecracker microVM takes ~125ms to boot. For the common case — executing generated code that came from a trusted brain with validated dependencies — seccomp is sufficient. Firecracker is reserved for execution contexts where the code source is untrusted, such as running scripts from community-contributed skills or executing LLM output directly.

The OSV cache with a 24-hour TTL strikes a balance between freshness and API load. The OSV database receives updates throughout the day, but re-scanning every dependency on every workflow execution would overwhelm both the OSV API and the local network. The TTL means a vulnerability disclosed at 2 AM is caught by the morning build cycle at worst.