Policy-as-code for AI workflows

Why policy-as-code matters

AI workflows touch production data and systems. You need a policy decision point that is deterministic and auditable. Policy-as-code makes the decision logic a first-class artifact that can be reviewed, tested, and versioned.

A policy shape that scales

The exact syntax can vary, but the shape should be simple: match on context and return a decision with optional constraints.

rules:
  - name: prod-writes-require-approval
    match:
      environment: prod
      risk_tags: [write]
    decision: REQUIRE_APPROVAL
  - name: allow-safe-read
    match:
      environment: prod
      risk_tags: [read]
    decision: ALLOW
    constraints:
      max_runtime_sec: 120

Decisions and constraints

Decisions should be explicit: ALLOW, DENY, REQUIRE_APPROVAL, or ALLOW_WITH_CONSTRAINTS. Constraints cap runtime, limit diffs, and enforce allowlists so risky actions are bounded even when approved.

Simulate before publish

Simulations let you run policies against representative jobs before you ship them. The output should show the matched rule, decision, and constraints.

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

200 OK
{
  "decision": "REQUIRE_APPROVAL",
  "reason": "prod write requires approval",
  "constraints": {
    "max_runtime_sec": 600
  },
  "matched_rule": "prod-writes-require-approval"
}

Review and rollout

Treat policy changes like code. Review them, simulate them against real traffic, and publish snapshots. This prevents accidental loosening and keeps approvals tied to a specific policy version.

• - Publish snapshot v42 after review and simulation.
• - Detect an unintended allow rule in production.
• - Rollback to snapshot v41 in seconds.
• - Audit trail records the publish and rollback events.

When policy changes mid-run

Runs bind to the policy snapshot hash captured at evaluation time. If policy changes later, the run still references the original snapshot, keeping approvals and audit records consistent.

This prevents drift: you always know which policy version approved or denied a specific job.

How Cordum handles policy

Cordum evaluates every job in the Safety Kernel and returns an explicit decision with a reason. The decision is bound to a policy snapshot and recorded in the run timeline.

Learn more in the Safety Kernel docs.