The scenario
Picture a team that builds payment infrastructure. Their security policy forbids any agent process that can make arbitrary outbound network calls or access files outside the project directory. Standard Python AI frameworks do not enforce this at the OS level: they rely on the developer not calling the wrong API, which is not a control that passes a SOC 2 audit. Vendor evaluations of agent tooling in environments like this tend to end the same way: “the security team will not approve this.”
This reference architecture describes how Kernex is designed to change that conversation.
The design
kernex-sandbox wraps macOS Seatbelt and Linux Landlock. The agent process declares its required filesystem paths at startup and the OS enforces the boundary; the sandbox roadmap extends the same model to network endpoints, so that a hallucinated call outside the allowlist fails at the syscall level before a packet leaves the machine.
The difference from application-level controls is the auditor’s question. Instead of “how do you prevent the agent from leaking data?”, the architecture is built so the answer can be “here is the syscall policy.”
Pipeline structure
Three sequential stages defined in a TOML topology file:
[[pipeline.stages]]
name = "static-analysis"
prompt_file = "prompts/static.md"
[[pipeline.stages]]
name = "security-review"
prompt_file = "prompts/security.md"
depends_on = ["static-analysis"]
[[pipeline.stages]]
name = "summary"
prompt_file = "prompts/summary.md"
depends_on = ["static-analysis", "security-review"]Each stage runs as an isolated agent turn. The summary stage receives the outputs from both prior stages as context. The wall-time design target per PR is under 30 seconds for a typical diff.
Audit trail
Every LLM call is logged to SQLite via kernex-memory: timestamp, provider, model, input hash, output hash, latency. The log is append-only from the agent’s perspective, which is what makes it usable as compliance evidence rather than just debugging output.
The target outcome
A review tool that a security team can approve on first review, because the controls are provable properties of the tool rather than policy promises. That is the bar this architecture is designed against.