COMPILE
Constrain the language surface
Unsupported APIs, including os/exec, are rejected before native guest execution.
Security engineering / Joulebox native runtime
Security by
subtraction.
The safest kernel interface is one untrusted code cannot reach. Joulebox runs supported agent-generated code in a deliberately small execution model, with a syscall policy tailored to each compiled program.
No guest futexSingle guest OS threadNo arbitrary execProgram-specific seccomp
Scope: This page studies documented attack-path reachability, not current host vulnerability. The evaluated production/demo Linux 6.18.56 kernels are patched against, or not affected by, the CVEs shown below.
01 / Philosophy
Prompts aren't permissions.
An AI agent instructed to write Go can still produce unexpected code, files, or network operations. Security must come from enforced capabilities—not instructions about how the agent should behave.
MINIMIZE
Keep the runtime small
Goroutines are supported on a single guest OS thread. The native guest does not need futex, clone, or dynamic mmap.
ENFORCE
Restrict the kernel boundary
Per-program seccomp, Landlock, namespaces, dropped capabilities, and a noexec home filesystem provide distinct restrictions.
Not a CVE blacklist. The point is architectural: if an interface is absent from the guest's execution model, a newly discovered vulnerability requiring that direct interface cannot be triggered through it.
02 / Threat landscape
Vulnerability disclosures are rising.
Your attack surface shouldn't.
The number of published vulnerabilities is a reminder that software and kernel interfaces carry ongoing exposure. Securely's response is to remove capabilities that supported agent workloads don't need, rather than depend on detecting every future flaw.
Architectural response
Fewer interfaces. Fewer direct entry points.
Restricted compilation and per-program guest syscall policies exclude some vulnerability trigger paths. This does not eliminate kernel risk, replace host patching, or constitute an independent security audit.
02 / Native execution path
Less functionality exposed.
Less kernel surface reachable.
These layers describe the compiled native guest. Other components of the system—including the compiler, shell, translator, and supervisor—have separate security boundaries and are not covered by the guest syscall count.
UNTRUSTED INPUT
Supported Go / translated Python
Limited APIs; no arbitrary subprocesses or native extension loading.→
NATIVE RUNTIME
Minimal static execution
Goroutines on one OS thread; no guest futex or dynamic memory mapping syscalls.→
LINUX BOUNDARY
Per-program syscall filter
Plus namespaces, Landlock, no capabilities, and restricted executable filesystems.2Syscalls permitted for a native hello-world example:
write, exit_group0Direct guest
futex calls permitted0Guest-created OS threads
Per programEffective guest syscall inventory varies with compiled code
The hello-world example describes the final guest policy, not the full launch or system-wide trusted computing base. Values reflect the supplied Joulebox architecture and should be checked against the deployed policy revision.
03 / Kernel vulnerability case studies
The CVE entry-point matrix.
A review of published Linux vulnerabilities and the direct interfaces their documented triggers require. Blocked direct entry point does not mean complete immunity: indirect paths and other trusted components require separate analysis.
| Case | Documented prerequisite | Native guest | Host kernel 6.18.56 |
|---|---|---|---|
| CVE-2026-43499GhostLock · futex | PI futex requeue, multiple OS threads; published chain has additional steps | Direct futex path blockedNo guest futex or guest OS threads | PatchedPer supplied kernel review |
| Why the direct path is unavailable Native guest code cannot issue Important: The production/demo kernel is patched; this row does not report an active exposure. See Red Hat advisory ↗ and research PoC ↗. The PoC has not been executed or independently audited for this page. | |||
| CVE-2024-0582io_uring · memory lifetime | io_uring_setup, register, mapping | Direct entry blockedNo guest io_uring calls | Not affectedOutside affected kernel range |
| Why this is included This illustrates exclusion of an entire optional kernel API. It is not a claim that a typical hardened general-purpose sandbox necessarily exposes io_uring. | |||
| CVE-2024-1086nf_tables · netfilter | Netlink configuration path and appropriate namespace/capability conditions | Direct config path blockedNo guest sockets or namespace creation | Not affectedFixed upstream before 6.18 |
| Why the direct path is unavailable The native guest cannot open netlink sockets or acquire the namespace/capability combination needed for the documented configuration route. Trusted namespace setup is a separate part of the system. | |||
| CVE-2025-38242userfaultfd · memory management | userfaultfd and UFFDIO_MOVE | Direct entry blockedNo guest userfaultfd or ioctl | Not affectedOutside affected kernel range |
| Why the direct path is unavailable The native guest does not expose | |||
Direct trigger interface excluded Indirect reachability not fully assessed
Click any CVE row for reasoning and source links. This matrix does not compare against a named third-party sandbox and does not assert that these CVEs are exploitable on the current host. Three of the four cases are also blocked by many hardened general-purpose configurations; the futex case best illustrates the native runtime's reduced dependencies.
04 / Featured case study
GhostLock: why not needing futex matters.
Historical attack-path analysis · host patched
CVE-2026-43499
The reported trigger involves futex priority-inheritance requeue operations across multiple threads. Conventional multithreaded runtimes need synchronization primitives; Joulebox's native guest runs goroutines on one OS thread without exposing the futex syscall.
What we can say: the documented direct futex trigger cannot be issued by native guest code under the described policy.
What we cannot say: that all futex-related kernel vulnerabilities are impossible to reach indirectly, or that this is a current unpatched host issue.
# Native guest policy ✓ goroutines on one OS thread ✓ program-specific seccomp ✕ futex syscall ✕ OS thread creation # GhostLock documented direct trigger FUTEX_WAIT_REQUEUE_PI │ ▼ BLOCKED: futex not permitted # Host status Patched / not currently exposed
05 / Reproduced capability test
Executable bytes.
Not executable authority.
A native Joulebox program constructed a 140-byte AArch64 ELF, wrote it to the session home with mode 0700, and verified the file on disk. A direct execution attempt was denied.
$ go run main.go ELF written: ./probe-arm64.elf File size: 140 bytes File mode: -rwx------ Permissions: 0700 $ ./probe-arm64.elf bash: ./probe-arm64.elf: Permission denied
Why execution is denied: the session home is mounted
noexec, Landlock does not grant execute rights there, and the Joulebox command dispatcher refuses to launch paths inside the home. This test does not isolate which of those controls returned the observed error.06 / Security boundaries
A smaller guest surface isn't a smaller universe.
The guest's syscall policy is only one part of the overall trusted computing base. Security claims must account for the components that compile, translate, launch, and interact with untrusted code.
GUEST
Still touches Linux
Supported programs can access permitted file operations within their home and clock functions. Bugs in those allowed kernel paths remain relevant.
TOOLCHAIN
Parses untrusted input
The compiler parses source under its own constrained policy. The Python translator, shell, and Git environment also process attacker-controlled material and require separate review.
CONTROL PLANE
Broader authority
The launcher and playd supervisor have broader responsibilities. The Go-based playd process is not protected by the native guest's seccomp filter.
Not a guarantee of immunity. Joulebox uses a shared Linux kernel. Excluding syscalls reduces direct attack paths, but does not establish freedom from kernel exploits, compiler bugs, supervisor vulnerabilities, or VM-equivalent isolation. Independent security assessment remains important.
07 / Methodology
Evidence before adjectives.
A CVE should enter this matrix only when its trigger prerequisites can be tied to an actual execution policy. New CVEs should default to unreviewed, not automatically "blocked."
01 / IDENTIFY
Documented trigger
Record affected versions, vulnerable kernel subsystem, and required syscalls, arguments, objects, and privileges.
02 / VERIFY
Effective guest policy
Review all stacked seccomp filters, filesystem restrictions, inherited descriptors, and launch-stage handoff. Distinguish final guest from trusted setup.
03 / ASSESS
Direct vs indirect reachability
Confirm whether a direct entry point is available, then examine alternative kernel call paths and broker interfaces. Unchecked paths remain unverified.
04 / MAINTAIN
Version the evidence
Record kernel build, policy revision, analysis date, and upstream sources. Reassess after compiler, runtime, or policy changes.
How to interpret the matrix statuses
Direct entry blocked: the documented guest-controlled syscall or capability prerequisite is excluded. Indirect reachability unverified: the kernel subsystem may still be entered through other allowed operations or trusted services. Patched/not affected: the current kernel does not have the cited historical flaw under the supplied version review.
Selected external references
GhostLock / Red HatGhostLock PoCio_uring / NVDNetfilter / Ubuntuuserfaultfd / MITRE
Assessment prepared from supplied architecture and kernel-policy review, November 2026. Not an independent audit. No exploit PoCs were executed for this webpage.
Design partners
Security is a property
of what code can reach.
Let's evaluate the actual capabilities your agent workloads need—and the kernel interfaces they don't.
Discuss your workload ↗