Security engineers often talk about “defense in depth” – the idea that no single control should be the only thing standing between an attacker and damage. coding-ethos and Ethosure apply this principle through a clean architectural separation between two layers with different jobs: the control plane decides whether an action should happen at all, and the data plane limits what an approved action can do once it runs.
Understanding this separation helps explain why Ethosure’s governance is stronger than tools that only do one or the other.
The control plane: making the decision
The control plane is the part of the system that evaluates a proposed action against compiled policy and returns a verdict. In coding-ethos, it consists of two components working together:
Go fact collectors parse the proposed action and produce structured data. If an AI agent wants to run a shell command, the Go evaluator parses that command into its component parts – binary, arguments, flags, environment context. If the agent wants to edit a file, Go computes the current file hash, identifies the target path, and extracts any proposed symbol changes using a code parser. The point is to convert the raw action into clean, typed facts that a policy expression can reason over.
CEL evaluators apply policy rules to those facts. CEL – the Common Expression Language – is a deterministic expression language that evaluates logical conditions without any side effects. It cannot read files, call the network, or invoke an AI model; it just evaluates the expressions in the compiled policy bundle against the supplied facts. The result is one of four decisions: ALLOW, TRANSFORM, ESCALATE, or BLOCK.
A key property of the control plane: it is pure and deterministic. The same action against the same policy always produces the same decision. This is what makes enforcement auditable.
The data plane: confining what is allowed
Here is a question that often goes unasked: what happens *after* an action is approved? If an agent is allowed to run a linter, does that mean it can also make network requests? Read credential files? Spawn child processes that consume all available memory?
Without a data plane, approval is an all-or-nothing gate. Once something is allowed, it can do anything the operating system permits. That is a large attack surface.
The coding ethose runtime sandbox is the data plane. It constrains what an approved process can actually see and do, using Linux kernel capabilities:
- Linux namespaces create an isolated environment – a private process tree, isolated network, and contained filesystem view.
- Landlock filesystem policy enforces which paths the process can read from and write to. The repository and its `.git` directory are read-only by default. Declared write paths (explicitly configured by the tool’s capability declaration) receive write access. Everything else is off-limits.
- Network isolation disconnects ordinary managed tools from the network entirely. A linter has no business making outbound connections. Tools that genuinely need network access must declare that requirement explicitly, and it still requires policy approval.
- Cgroup resource limits cap the process’s CPU time, memory consumption, and execution time. A runaway tool does not consume the host machine.
- Seccomp profile metadata restricts which system calls the process can make.
The target default profile for ordinary managed tools is: no network, read-only repository, no host process visibility, bounded timeout, bounded memory and CPU. If the sandbox cannot be set up – for example because kernel support is missing – the tool fails closed rather than running unsandboxed.
Why the separation matters
The control plane and data plane address different threat categories.
The control plane handles intent: is this action consistent with policy? It catches things like hook-bypass attempts, edits to protected files, dangerous Git commands, and commands that violate naming or structure rules.
The data plane handles confinement: even if the intent is approved, does the execution stay within its declared boundaries? It protects against tools that gain new capabilities over time (a linter that quietly starts making network requests), tools that are compromised or behave unexpectedly, and the general principle that approved processes should not have more access than they need.
The coding-ethos documentation describes this explicitly: “CEL remains pure and deterministic. Go prepares facts, policy decides over those facts, and the sandbox runner enforces the declared runtime capabilities. The two layers are deliberately separate.”
A concrete example
An AI agent wants to run a static analysis tool on the repository. The event reaches the control plane:
- Go collects facts: the command, the tool name, the target files.
- CEL evaluates the applicable policies: does this tool have a registered capability declaration? Is network access requested? Are the target files within scope?
- Decision: ALLOW.
Now the data plane takes over:
- The sandbox launches the tool inside a new Linux namespace.
- The repository is mounted read-only. The tool’s declared output directory receives write access.
- The network namespace is disconnected – no outbound connections possible.
- CPU and memory are capped per the tool’s capability declaration.
- When the tool finishes, the sandbox records its resource usage and any runtime events into the evidence ledger.
If the tool tried to write to `.git` – perhaps to tamper with hook definitions – Landlock would block that write at the kernel level. If it tried to open a network socket, the disconnected network namespace would return an error. The decision to allow the tool to run does not become permission to do anything.
What this means for your organization
The control-plane / data-plane separation gives security teams a straightforward model for reasoning about risk: “We decide what is allowed; we confine what runs.” This maps cleanly onto least-privilege principles that compliance frameworks like NIST AI RMF and ISO/IEC 42001 require organizations to demonstrate. Both layers produce evidence – control plane decisions appear as policy findings in the SARIF record; data plane runtime events appear in sandbox traces. The combined record is the audit trail.
