SDK access
Modules call SDK methods for database, media, UI, tasks, AI, and knowledge rather than importing private runtime code.
Security
Security starts with boundaries that extension code must use.
The runtime is designed so modules, engines, and extractors work through public contracts. Permission checks, scoped models, audit events, and process policy are platform concerns.
Application boundary
A module should not need private runtime access.
The safest extension model is one where the supported path is also the easiest path.
Permissions
Actions and pages declare access requirements and run with the authenticated user and organization context.
Scoped models
Module models inherit base behavior that applies user and organization filters where configured.
Runtime policy
Two layers confine extension code: portable and kernel-enforced.
A Python-level Process Guard mediates extension behavior on every platform. On Linux, kernel facilities enforce the same boundary independently of the Python interpreter.
Process Guard (Python)
A default-on, portable layer that mediates which modules extension code may import and which network targets and files it may reach.
Filesystem & syscalls (Linux)
Landlock confines filesystem access (ABI v1–v5) and a hand-written seccomp-BPF filter blocks escalation syscalls — execve, ptrace, kexec, namespace and setuid changes, bpf, userfaultfd. Applied via raw syscalls, with no elevated privileges required.
Network egress
External access is policy-gated in one place: enforced at the Python layer and, on Linux, in the kernel through per-cgroup iptables rules. External media is fetched through a backend proxy, never directly by the client.
Audit trail
Runtime activity is correlated with the originating action, task, model call, and storage mutation, so policy decisions leave evidence.
Landlock and seccomp apply without elevated privileges. Kernel-level network enforcement (cgroup v2 + iptables) requires host privileges; without them the Python-level guard remains in effect.
Practical security
Security claims should map to visible controls.
The goal is not to promise invisible guarantees. The goal is to expose boundaries, checks, and audit evidence.
Import boundaries
Extension code should depend on public SDK modules instead of core implementation paths.
Approval points
Actions or tools that cross sensitive boundaries can require explicit confirmation.
Inspectable failures
Policy failures should be visible as runtime errors and audit events rather than silent behavior.
Next
Related pages
Use these pages to move from the concept to adjacent parts of the runtime.