Introducing Cordum: The Control Plane for AI Agent Governance

Why now: Autonomous AI agents are already touching production, but most teams do not have a reliable way to govern them. The risk is not the model; the risk is uncontrolled execution. That is the gap Cordum closes.

Why we built Cordum

Operations teams are moving faster than ever, and autonomous AI agents are already automating work that used to require a human. But most of these agents are held together by scripts and ad-hoc approvals that do not scale.

Cordum is built for a single purpose: make autonomous AI agents safe and auditable without slowing the safe path. We want teams to ship autonomy to production without losing control.

What top governance posts miss

We reviewed top-ranking governance references before updating this launch post. Most explain governance principles well. The missing piece is operational: what exactly gets checked before dispatch, and what exact evidence proves that check happened.

Source	Strong coverage	Missing piece
TechTarget: 8 agentic AI governance strategies	Strong governance fundamentals: permission boundaries, privacy, data lineage, and compliance assessments.	No concrete runtime decision contract for what blocks execution at dispatch time.
McKinsey: Agentic AI security playbook	Enterprise risk framing and security governance priorities for scaling agentic deployments.	Limited implementation detail for approval binding, policy snapshots, and operator-facing evidence trails.
IMDA: Model AI Governance Framework for Agentic AI	Lifecycle structure: risk bounding, accountable human oversight, staged rollout, and continuous monitoring.	No executable schema teams can plug directly into job dispatch and audit pipelines.

Here is the minimum runtime evidence object we think every production agent platform should emit before a high-risk job executes.

decision-evidence.json

JSON

{
  "job_id": "job_7f84d",
  "topic": "job.incident.remediate",
  "policy_snapshot": "v1:3a71f2d",
  "policy_decision": "REQUIRE_APPROVAL",
  "approval": {
    "required": true,
    "approver_id": "ops-oncall-17",
    "approved_at": "2026-04-01T08:41:12Z"
  },
  "constraints": {
    "max_runtime_sec": 900,
    "max_lines_changed": 500
  },
  "dispatch": {
    "allowed": true,
    "dispatched_at": "2026-04-01T08:41:18Z"
  }
}

What it is

Cordum is the control plane for autonomous AI agents. It runs on NATS for the bus and Redis for state, with a Safety Kernel that evaluates every job before dispatch, and a workflow engine that orchestrates runs, approvals, and retries.

The core is intentionally boring: schedules, state, approvals, and audit trail. Domain logic lives in packs, not in the core.

Safety Kernel

The Safety Kernel is the policy decision point. It returns ALLOW, DENY, REQUIRE_APPROVAL, or ALLOW_WITH_CONSTRAINTS. Decisions are bound to a policy snapshot and recorded with a reason.

Approvals are explicit and tied to the exact job hash. Constraints keep risky actions within safe bounds like max runtime, diff size, or network egress allowlists.

Workflow Engine

Workflows are explicit DAGs. Runs emit a timeline of step states, approvals, and results. The engine can pause, retry, or resume a run without losing context.

workflow.yaml

name: incident-triage
steps:
  triage:
    type: worker
    topic: job.incident.enrich
    
  approval:
    type: approval
    depends_on: [triage]
    reason: "Review before remediation"
    
  remediate:
    type: worker
    topic: job.incident.remediate
    depends_on: [approval]
    constraints:
      max_lines_changed: 500
      max_runtime_sec: 900

Packs

Packs are how domain logic ships. Packs install workflow definitions, schemas, and policy overlays. Install does not execute code; you deploy workers separately on your own schedule.

This keeps the core stable while letting teams iterate on domain logic quickly. It is safe to upgrade core without rewiring every workflow.

BUSL-1.1 by default

Cordum uses the Business Source License (BUSL-1.1) so you can inspect the control plane before it touches production. You can run and modify it for internal use. Hosted or resale use cases require a commercial agreement.

See /legal/license for full terms.