Skip to content
Blog

LLM safety kernel

The deterministic decision layer that keeps LLM actions bounded, explainable, and auditable.

Jan 20, 20268 min readSafety Kernel
TL;DR

A safety kernel evaluates every job before execution. It returns a deterministic decision and optional constraints so LLM-driven actions stay safe and predictable.

  • - LLMs can be probabilistic, but the control plane must be deterministic.
  • - A safety kernel is the policy decision point for every job.
  • - Constraints turn approvals into bounded, predictable execution.
Definition

A safety kernel is the policy decision point that sits between autonomous execution and runtime. It evaluates the request and returns a decision that is recorded and enforceable.

It is a service, not a library. Every job flows through it before dispatch.

Why a safety kernel

LLMs are probabilistic. The control plane cannot be. A safety kernel makes decisions deterministically and logs the outcome so approvals and audits remain consistent.

Decision flow

Every job takes the same path: request, evaluation, decision, and enforced execution.

Job request
  |
  v
Safety Kernel
  |
  +--> ALLOW -> dispatch
  +--> REQUIRE_APPROVAL -> pause -> resume
  +--> ALLOW_WITH_CONSTRAINTS -> dispatch with bounds
  +--> DENY -> stop + record

Decision matrix

Most systems need the same four outcomes:

ALLOW
DENY
REQUIRE_APPROVAL
ALLOW_WITH_CONSTRAINTS

Policy example

Policies match on context and return decisions with constraints. The policy is versioned and tied to a snapshot hash for approvals.

tenants:
  default:
    rules:
      - match:
          risk_tags: ["prod", "write"]
        decision: REQUIRE_APPROVAL
      - match:
          capability: "incident.remediate"
        decision: ALLOW_WITH_CONSTRAINTS
        constraints:
          max_lines_changed: 500
          max_runtime_sec: 900

Constraint examples

  • - max_runtime_sec to cap long-running tasks
  • - max_lines_changed to bound patches
  • - network_egress_allowlist for outbound calls
  • - deny_paths for sensitive repositories

Simulate and explain

Simulations let you test policy changes before they go live. Explanations show which rule matched and why.

POST /api/v1/policy/simulate
{
  "tenant_id": "default",
  "job": {
    "topic": "job.incident.remediate",
    "risk_tags": ["prod", "write"],
    "capability": "incident.remediate"
  }
}

200 OK
{
  "decision": "REQUIRE_APPROVAL",
  "reason": "prod write requires approval",
  "constraints": {
    "max_lines_changed": 500,
    "max_runtime_sec": 900
  },
  "snapshot_hash": "7f3d...9c2b"
}

Deterministic core, autonomy at the edges

The safest architecture keeps the orchestration deterministic and pushes autonomy to the edges. The control plane decides, the worker executes within constraints, and the audit trail records the result.

How Cordum implements it

Cordum runs the Safety Kernel as a dedicated service. It evaluates every job, binds decisions to a policy snapshot, and enforces constraints during execution. Decisions appear in the run timeline and are available for audit.

Learn more in the Safety Kernel overview.

Next steps

Request source access to inspect the Safety Kernel implementation, or run the quickstart to see decisions in the run timeline.