Cordum

Know What Your AI Agents Are Doing. Before They Do It.
The Source-Available Agent Control Plane for Governance, Safety, and Trust.
Includes Cordum Edge — a Compliance Firewall for Claude Code and other local AI-agent actions.

Discord · Discussions · Docs

Quickstart

First Time?

Goal	Path
Just want to try it?	`./tools/scripts/quickstart.sh` — one-command install from source (Option A below)
Run the full stack from pre-built images?	`docker compose pull && docker compose up -d` (Option B below)
Developing Cordum?	See Development

Option A: Install from source

One command stands up the full stack — API gateway, scheduler, safety kernel, workflow engine, context engine, dashboard, NATS, and TLS-secured Redis — with auto-generated secrets, auto-provisioned certificates, and a post-deploy smoke test that exercises a real approval workflow:

git clone https://github.com/cordum-io/cordum.git
cd cordum
./tools/scripts/quickstart.sh

Prerequisites: Docker Desktop v4+ (or Engine v20.10+ with Compose v2, ≥ 4 GB RAM allocated), Go 1.26.3+ (for first-run cert generation), and curl. On Windows use MSYS2 / Git Bash / WSL.

What you get at the end:

Dashboard at http://localhost:8082 — log in as admin / ChangeMe123! (the default dev password, also saved to .env as CORDUM_ADMIN_PASSWORD; change it before exposing the stack).
Gateway at http://localhost:8081 with a generated CORDUM_API_KEY in .env.
TLS CA, server, and client keypairs under ./certs/.
A working approval-gate workflow proven by the built-in platform_smoke.sh run.

Full walkthrough, platform notes, and troubleshooting: docs/quickstart.md.

Option B: Run the published images

Prerequisites: Docker Desktop v4+ or Docker Engine v20.10+ with the Compose v2 plugin (≥ 4 GB RAM allocated), jq (recommended, for parsing API responses), and Go 1.26.3+ (for one-time local cert generation — docker compose mounts ./certs but does not create it).

git clone https://github.com/cordum-io/cordum.git
cd cordum
go run ./cmd/cordumctl generate-certs   # writes ./certs/{ca,server,client}
export CORDUM_API_KEY=$(openssl rand -hex 32)
export REDIS_PASSWORD=$(openssl rand -hex 16)
docker compose pull         # pulls every Cordum service from ghcr.io
docker compose up -d        # starts the stack — no image build needed

Dashboard: http://localhost:8082 Login: this path leaves user auth off by default — sign in on the dashboard with your CORDUM_API_KEY. To enable admin password login instead, set CORDUM_USER_AUTH_ENABLED=true and a policy-compliant CORDUM_ADMIN_PASSWORD (≥ 12 chars, with an uppercase letter, a digit, and a special character) in .env, then docker compose up -d. (The quickstart script in Option A does this for you.)

Pin a specific release by exporting CORDUM_VERSION=1.2.3 before docker compose pull. Defaults to :latest, which only moves on stable release tags (pre-release suffixes such as -rc.1 never promote :latest).

Verifying image signatures

Every release-tag image is signed with cosign keyless OIDC. The example below verifies api-gateway; repeat the same command (swapping the image name) for each of the seven Cordum images before deploying to production — verifying one image does not attest the rest:

cosign verify ghcr.io/cordum-io/cordum/api-gateway:1.2.3 \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp 'https://github\.com/cordum-io/cordum/\.github/workflows/docker\.yml@refs/tags/v.*'

See docs/deployment/images.md for the full image catalogue, a verify-all-images snippet, multi-arch pull instructions, and tag policy.

Manual setup (without docker compose)

cp .env.example .env
# Edit .env: set CORDUM_API_KEY (or generate: openssl rand -hex 32)
export CORDUM_API_KEY="your-key-here"
go run ./cmd/cordumctl up
open http://localhost:8082

Deploy to Kubernetes

helm install cordum oci://ghcr.io/cordum-io/cordum/charts/cordum \
  --namespace cordum --create-namespace \
  --set secrets.apiKey=$(openssl rand -hex 32) \
  --set redis.auth.password=$(openssl rand -hex 32) \
  --set ingress.enabled=true \
  --set ingress.className=nginx \
  --set ingress.api.host=api.cordum.example.com \
  --set ingress.dashboard.host=cordum.example.com

--set values land in the Helm release's stored values (and your shell history) — fine for a quick eval, but for production prefer redis.auth.existingSecret (see cordum-helm/values.yaml) over redis.auth.password, and patch secrets.apiKey into the rendered Secret out-of-band rather than passing it on the command line; that chart doesn't yet have an existingSecret equivalent for the API key.

See cordum-helm/ for the full Helm chart reference. The chart is also available on Artifact Hub.

Container images (multi-arch: linux/amd64 + linux/arm64):

Image	GHCR	Docker Hub
`api-gateway`	`ghcr.io/cordum-io/cordum/api-gateway`	`cordum/api-gateway`
`scheduler`	`ghcr.io/cordum-io/cordum/scheduler`	`cordum/scheduler`
`safety-kernel`	`ghcr.io/cordum-io/cordum/safety-kernel`	`cordum/safety-kernel`
`workflow-engine`	`ghcr.io/cordum-io/cordum/workflow-engine`	`cordum/workflow-engine`
`context-engine`	`ghcr.io/cordum-io/cordum/context-engine`	`cordum/context-engine`
`mcp`	`ghcr.io/cordum-io/cordum/mcp`	`cordum/mcp`
`dashboard`	`ghcr.io/cordum-io/cordum/dashboard`	`cordum/dashboard`

Full catalogue, tag policy, cosign verification recipe, and multi-arch notes: docs/deployment/images.md.

Ports

Port	Service
8082	Dashboard
8081	API Gateway (HTTPS)
9080	gRPC Gateway
4222	NATS
6379	Redis
9092	Gateway Metrics
9093	Workflow Engine Health
50051	Safety Kernel (gRPC)
50400	Context Engine (gRPC)

Port conflicts? If any port is already in use, either stop the conflicting service or override ports in your .env file before starting the stack.

After Setup

# Load the generated API key into this shell (skip if already exported)
export CORDUM_API_KEY=$(grep CORDUM_API_KEY .env | cut -d= -f2)

# Submit a test job
curl -sS --cacert ./certs/ca/ca.crt \
  -X POST https://localhost:8081/api/v1/jobs \
  -H "X-API-Key: $CORDUM_API_KEY" -H "X-Tenant-ID: default" \
  -H "Content-Type: application/json" \
  -d '{"topic":"job.default","prompt":"hello"}'

# Stop the stack
docker compose down

# View logs
docker compose logs -f api-gateway

Troubleshooting

Issue	Fix
Port already in use	`docker compose down` then retry, or check `lsof -i :8082`
Docker out of memory	Allocate at least 4 GB RAM to Docker Desktop
Can't login to dashboard	Default is `admin` / `ChangeMe123!` (in `.env` as `CORDUM_ADMIN_PASSWORD`); ensure `CORDUM_USER_AUTH_ENABLED=true`. Custom passwords must be ≥12 chars + uppercase + digit + special
TLS/SSL cert errors	Remove `./certs/` and re-run — certs auto-regenerate
`openssl` not found	Not needed — quickstart.sh auto-generates keys without it
Go build fails	Requires Go 1.26.3+ — check with `go version`
Stale config after changes	`redis-cli DEL cfg:system:default` then restart

For detailed troubleshooting, see docs/troubleshooting.md.

See a 3-verdict demo

Once the stack is up, install the demo-quickstart pack and run the governance demo:

cordumctl pack install ./demo/quickstart/pack
cordumctl demo run quickstart

A single hello, operator! workflow fans out to three topics and exercises every safety-kernel decision class in under 30 seconds:

  +--------------------+--------------------------+--------------------+---------
  | Step               | Topic                    | Verdict            | Reason
  +--------------------+--------------------------+--------------------+---------
  | greet              | job.demo-quickstart.greet           | ALLOW              | Safe…
  | attempt_delete     | job.demo-quickstart.delete-all      | DENY               | Block…
  | escalate_admin     | job.demo-quickstart.admin           | REQUIRE_APPROVAL   | Sign…
  +--------------------+--------------------------+--------------------+---------

Full walkthrough, rule-by-rule explanation, and extension recipe: demo/quickstart/README.md.

Edge Quickstart (Compliance Firewall for Claude Code)

Cordum Edge governs Claude Code tool calls in the developer's terminal — the hook denies risky actions before they run, requires approval on edits, and exports a redacted evidence bundle for every session. Once the platform stack is up (above), point Claude Code at Cordum:

export CORDUM_GATEWAY=https://localhost:8081
export CORDUM_API_KEY=$(grep CORDUM_API_KEY .env | cut -d= -f2)
export CORDUM_TENANT_ID=default
./bin/cordumctl edge claude

The wrapper renders a temporary settings.json, spawns cordum-agentd on a local loopback nonce, and starts Claude Code with the command hook installed. Read .env is denied; Edit/Write requires approval; safe reads pass through untouched. The dashboard shows the live session timeline at /edge/sessions.

For approved destructive actions, Edge does not trust the approval store alone: the ProvenanceGate also requires a resolved approval audit event for the same tenant, approval_ref, and action_hash. An approval-requested event by itself does not satisfy provenance, and raw prompts, transcripts, and tool payloads are kept out of audit evidence.

Full 30-minute walkthrough: docs/quickstart-edge.md. Reference: docs/edge/README.md.

Why Pre-Dispatch Action Governance?

Agents act with real authority: cloud credentials, database connections, authenticated MCP sessions. Common controls each sit at a different boundary, and none of them is the point where a specific action is dispatched:

Runtime sandboxes isolate the host, not the authority. A container or microVM limits what a process can do to the machine it runs on. It does not limit what an agent can do with credentials or sessions it legitimately holds.
Observability records an action after it runs. Logs and traces explain an incident; they do not hold the call that caused it.
Model and prompt guardrails sit at the LLM boundary. They check what goes into and comes out of a model. Executing the resulting tool call or job happens in the code that dispatches it.

Cordum puts a policy decision at that dispatch boundary:

Normalized, hashed actions. Approval-gated CAP jobs, action descriptors, MCP tool calls (tenant, server, tool, target path) and Cordum Edge evaluate requests are each reduced to a canonical form and hashed with SHA-256.
Explicit verdicts. Policy evaluation yields ALLOW, DENY, REQUIRE_APPROVAL, THROTTLE or ALLOW_WITH_CONSTRAINTS. The gateway, scheduler and Edge evaluate path treat an unknown verdict as DENY.
Hash-bound approvals. A gated action's approval is looked up by tenant and approval_ref and must carry the same SHA-256 action_hash as the action being run; a changed payload is rejected as approval_mismatch. Self-approval, expired and already-consumed approvals are rejected too.
Declarative YAML policies. Rules in config/safety.yaml match on tenant, topic, capability, risk tags, actor and labels; the shipped policy denies anything no rule matches (default_decision: deny).
Risk tags and agent risk tiers. Rules can match risk_tags on any plan. Agent identities, which carry the risk tier that agent_risk_tiers rules match, require an Enterprise license.
Cordum Edge. A local 10BC8 hook evaluates coding-agent tool calls (Claude Code today) against the gateway before they run. See Edge Quickstart.

The Solution: Cordum Agent Control Plane

Cordum is an Agent Control Plane that provides a deterministic governance layer for probabilistic AI minds. It allows you to define, enforce, and audit the behavior of your Autonomous AI Agents across any framework or model.

graph TB
    subgraph CP [AGENT CONTROL PLANE]
        direction LR
        G[API Gateway] --- S[Scheduler] --- SK[Safety Kernel]
        S --- WE[Workflow Engine]
    end
    
    subgraph AGENTS [AUTONOMOUS AGENT POOLS]
        direction LR
        A1[Financial Ops]
        A2[Data Science]
        A3[Customer Service]
    end
    
    CP -->|Governed Jobs| AGENTS
    AGENTS -->|Audit Trail| CP

Governance Across the Lifecycle

Cordum's Before/During/Across framework provides exhaustive control over your agent operations:

graph LR
    subgraph BEFORE [1. BEFORE - Governance]
        P[Policy Evaluation] --> S[Safety Gating]
        S --> H[Human Approval]
    end
    subgraph DURING [2. DURING - Safety]
        M[Real-time Monitoring] --> C[Circuit Breakers]
        C --> A[Live Approvals]
    end
    subgraph ACROSS [3. ACROSS - Observability]
        F[Fleet Health] --> T[Audit Trail]
        T --> O[Optimization]
    end
    BEFORE --> DURING
    DURING --> ACROSS

BEFORE (Governance): Define declarative policies that evaluate job requests before an agent executes. Trigger safety kernel checks, throttle risky actions, or flag operations for human approval.
DURING (Safety): Real-time visibility into active agent runs. Monitor progress, handle step-level approvals, and enforce timeouts or circuit breakers on the fly.
ACROSS (Observability): Manage your entire fleet from a single control plane. Aggregate audit trails, track capability-based routing, and observe agent pool health in real-time.

Cordum Edge: Compliance Firewall for AI agents

Cordum Edge extends the control plane to local AI-agent actions. For Claude Code, cordumctl edge claude launches the real P0 path — command hook, local cordum-agentd, Gateway Edge APIs, Safety Kernel policy/evaluate, approvals, artifact pointers, and dashboard evidence.

Cordum stays quiet until governance matters. Developers see Cordum exactly when it protects them, their team, and production: before risky tools run, when an action needs approval, and when evidence must be exported. The wrapper is the developer/demo path; enterprise enforcement requires managed Claude settings and endpoint controls.

Approval provenance is resolved-only: destructive retries must have a matching approved approval record and a canonical resolved approval audit event for the same tenant/ref/hash. Requested-only audit rows are lifecycle context, not proof that the action was approved.

Start here: Edge overview, Claude Code guide, manual demo, and Edge API.

Development

The published-images path above pulls Cordum binaries from ghcr.io. Contributors who need to rebuild from source use the development override file:

make dev-up      # docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build
make dev-logs    # tail compose logs
make dev-down    # docker compose down

docker-compose.dev.yml re-pins every Cordum service to a local cordum/<name>:dev tag and forces the build: context, so source changes are reflected on the next --build. Upstream images (NATS, Redis) are untouched. See Makefile and docker-compose.dev.yml for full details.

Other useful contributor commands:

Command	Purpose
`make build`	Build every service binary into `bin/` (wraps `make proto` first).
`make build SERVICE=cordumctl`	Build a single service.
`make test`	Run the full Go test suite.
`make smoke`	Quick post-deploy smoke against a running stack.

Key Features

Governance Feature	Why It Matters for Enterprise
Safety Gating	Prevents agents from executing destructive or unauthorized actions before they occur.
Output Quarantine	Automatically blocks PII leaks, secrets, or hallucinated results from reaching the client.
Human-in-the-Loop	Mandates human oversight for high-risk operations (e.g., financial transfers, prod access).
Pool Segmentation	Ensures sensitive data only reaches agents in trusted environments.
Deterministic Audit	Prove exactly why a decision was made with a full chain-of-thought audit trail.
Governance Policies	Declarative YAML-based rules that map enterprise risk to agent behavior.
Policy Simulator	Test your governance rules against historical data before rolling them out to production.
Cordum Edge	Compliance Firewall for local AI-agent actions (Claude Code today, more agents next): hook → local agentd → Gateway evaluate → resolved approval provenance → redacted evidence export. See docs/edge/README.md.

Architecture

cordum/
├── cmd/                          # Service entrypoints + CLI
│   ├── cordum-api-gateway/       # API gateway (HTTP/WS + gRPC)
│   ├── cordum-scheduler/         # Scheduler + safety gating
│   ├── cordum-safety-kernel/     # Policy evaluation
│   ├── cordum-workflow-engine/   # Workflow orchestration
│   ├── cordum-context-engine/    # Optional context/memory service
│   └── cordumctl/                # CLI
├── core/                         # Core libraries
│   ├── controlplane/             # Gateway, scheduler, safety kernel
│   ├── context/                  # Context engine implementation
│   ├── infra/                    # Config, storage, bus, metrics
│   ├── protocol/                 # API protos + CAP aliases
│   └── workflow/                 # Workflow engine
├── dashboard/                    # React UI
├── sdk/                          # SDK + worker runtime
├── cordum-helm/                  # Helm chart
├── deploy/k8s/                   # Kubernetes manifests
└── docs/                         # Documentation

Documentation

Doc	Description
System Overview	Architecture and data flow
Core Reference	Deep technical details
Docker Guide	Running with Compose
Agent Protocol	CAP bus + pointer semantics
Authenticated Worker Trust	Worker enrollment, challenge/proof sessions, rollout, and rotation
MCP Server	MCP stdio + HTTP/SSE integration
Pack Format	How to package agent capabilities
Local E2E	Full local walkthrough
Edge Quickstart	New-engineer 30-min path: clone → live stack → governed Claude session
Edge Reference	Cordum Edge product, API, CLI, demo, runbook
Production Guide	TLS, HA, backups, incident runbooks

Protocol: CAP — The Open Standard for Agent Governance

Cordum implements CAP (Cordum Agent Protocol), an open protocol specifically designed for distributed AI agent governance. CAP provides a unified interface for defining agent capabilities, submitting jobs, and enforcing safety policies across heterogeneous agent pools.

CAP vs. MCP: Why You Need Both

While both are essential, they solve different parts of the agent stack:

Protocol	Focus	Level	Responsibility
MCP (Model Context Protocol)	Tool Calling	Local	How a model interacts with a tool.
CAP (Cordum Agent Protocol)	Governance	Network	How an agent is governed within an enterprise.

MCP is for within the agent — it defines how a model calls local tools.
CAP is for above the agent — it defines the governance control plane for the entire agent fleet.

Use CAP for high-level orchestration and safety gating, and MCP inside your agents for fine-grained tool integration.

Read the full deep dive: MCP vs CAP: Why Your AI Agents Need Both Protocols

MCP Server

Cordum includes an MCP server framework with:

Standalone stdio mode via cmd/cordum-mcp (for Claude Desktop/Code local integration)
Gateway HTTP/SSE mode via /mcp/message and /mcp/sse (when mcp.enabled=true)

See docs/mcp-server.md for setup, auth headers, and client configuration examples.

SDK

The Go SDK makes it easy to build CAP-compatible workers:

import (
    "log"

    "github.com/cordum/cordum/sdk/runtime"
)

type Input struct {
    Prompt string `json:"prompt"`
}

type Output struct {
    Summary string `json:"summary"`
}

func main() {
    // AllowUnsigned is required when the worker holds no signing keys;
    // CAP fails closed at startup otherwise. Provision worker trust keys
    // for anything beyond local development -- see docs/sdk/handshake.md.
    agent := &runtime.Agent{Retries: 2, AllowUnsigned: true}

    runtime.Register(agent, "job.summarize", func(ctx runtime.Context, input Input) (Output, error) {
        // Your agent logic here
        return Output{Summary: input.Prompt}, nil
    })

    if err := agent.Start(); err != nil {
        log.Fatal(err)
    }
    select {}
}

SDKs: Go (stable, this repo) | Python (pip install cap-sdk-python) | Node (npm install cap-sdk-node)

Stable CAP Go, Python, and Node runtimes implement the same authenticated protobuf worker-trust contract. A legacy capability handshake or heartbeat is telemetry, not identity proof, unless it is bound into an accepted session. Deployments remain at the explicit compatibility default CORDUM_SDK_HANDSHAKE=off + CORDUM_HEARTBEAT_MODE=authority until worker proof keys and control-plane signing authorities are provisioned. Follow the authenticated worker trust guide before enabling warn or enforce.

Integration Packs

Extend Cordum with integration packs for Slack, GitHub, AWS, Jira, Terraform, Datadog, PagerDuty, and more. Each pack is an installable overlay of workflows, schemas and config/policy fragments (docs/pack.md); Core does not deploy pack workers, which run as separate deployments.

Pack	Category	Description
Slack	Communication	Approval notifications and agent alerts
GitHub	DevOps	Govern agent actions on repositories
AWS	Cloud	Policy-gated cloud operations
Kubernetes	DevOps	Governed incident remediation
Terraform	DevOps	Pre-apply governance for IaC
Datadog	Monitoring	Alert-triggered governed workflows
LangChain	AI Framework	Governance for LangChain tool calls
MCP Bridge	AI Framework	Gateway governance for MCP tools

Browse all integrations →

Community

Discord: Join the conversation
GitHub Discussions: Ask questions
Twitter/X: @Cordum_io
Email: See SECURITY.md for contact details

Enterprise

Cordum Enterprise features (shipped in core, unlocked by license entitlement):

SSO/SAML/OIDC integration + SCIM provisioning
Advanced RBAC with role hierarchy
SIEM export (webhook, syslog, Datadog, CloudWatch)
Legal hold + velocity rules + agent identity
Priority support

See docs/enterprise.md for the full entitlement matrix. The formerly separate cordum-enterprise repo was retired 2026-04-23.

Governance

Cordum follows a transparent governance model with a protocol stability pledge, maintainer structure, and clear decision-making process. See GOVERNANCE.md for details including:

Protocol Stability: CAP v2 wire format frozen until February 2027
Security: SECURITY.md for vulnerability reporting
Versioning: Semantic versioning with deprecation policy

Roadmap

See ROADMAP.md for the full feature roadmap, completed milestones, and planned work.

Changelog

See CHANGELOG.md for a detailed log of all changes by version.

Where Cordum Fits in the Agent Stack

Each layer below enforces at a different boundary, and they can be combined. Cordum is the action control plane layer; it is meant to run alongside the others, not to replace them. Descriptions of other projects paraphrase their own documentation.

Layer	Enforcement boundary	Examples
Model and prompt guardrails	Inputs to and outputs from an LLM	Guardrails AI runs Input/Output Guards in your application. NeMo Guardrails adds programmable guardrails to LLM-based conversational applications. Llama Guard is a family of input and output moderation models.
Traffic and MCP gateways	The network path between clients, models, tools and APIs	IBM ContextForge is a registry and proxy that federates MCP, A2A and REST/gRPC APIs. LiteLLM is an AI gateway with a single interface to many LLM providers.
In-process hooks	Checks inside the agent's own process, such as framework callbacks or function wrappers	—
Action control plane (Cordum)	The point where an action is submitted or dispatched	Gateway submit-time policy checks, scheduler pre-dispatch safety checks, the MCP server policy pipeline, and the Cordum Edge hook.
Runtime sandboxes	The process, OS or VM the action runs in	Docker runs applications in a loosely isolated environment called a container. gVisor is an application kernel that isolates applications from the host OS. Firecracker runs workloads in lightweight virtual machines called microVMs. E2B runs AI-generated code in isolated cloud sandboxes.

Contributing

We welcome contributions! See CONTRIBUTING.md for guidelines. Check out our good first issues to get started.

License

Cordum ships from three repositories under two licenses. The table follows each repository's LICENSE file and package metadata; the LICENSE files are the authoritative terms.

Component	Repository	License
Control plane services, dashboard, Cordum Edge, and Cordum's own SDKs (the Go `sdk/` module, `cordum-sdk` on PyPI, and the TypeScript `@cordum/sdk` package in `sdk/typescript/`)	cordum-io/cordum	BUSL-1.1
Integration packs	cordum-io/cordum-packs	BUSL-1.1, with the same Additional Use Grant. A pack directory with its own LICENSE is governed by that file; for example, `packs/incident-enricher` is Apache-2.0.
CAP protocol and its published SDKs (Go module `github.com/cordum-io/cap/v2`, `cap-sdk-python` and `cordum-guard` on PyPI, `cap-sdk-node` on npm)	cordum-io/cap	Apache-2.0

The BUSL-1.1 parameters in LICENSE:

Additional Use Grant: You may make use of the Licensed Work for any purpose, including production use and self-hosted deployments, provided that you do not use the Licensed Work to provide a Competitive Offering.

Change Date: 2029-01-01, or the fourth anniversary of a version's first public distribution under the license, whichever comes first.
Change License: Apache License, Version 2.0 (Apache-2.0). On the earlier of those two dates, rights under Apache-2.0 replace the BUSL-1.1 grant for that version.
Other use: "If your use of the Licensed Work does not comply with the requirements currently in effect as described in this License, you must purchase a commercial license from the Licensor, its affiliated entities, or authorized resellers, or you must refrain from using the Licensed Work."

See LICENSE for the full terms.

Runtime entitlements are separate from the license. The control plane enforces plan limits in code. Without a valid Cordum license it runs on the Community defaults in core/licensing/tiers.go: 3 workers, 3 concurrent jobs, 500 requests per second, 7-day audit retention, single approval mode and no custom policy bundles. It also falls back to these defaults when a license cannot be loaded or fails verification (core/licensing/resolver.go). These are product limits, not BUSL-1.1 terms; see Enterprise.

Versioning

Cordum core and CAP release independently, each with its own tags (VERSIONING.md):

Cordum core (v<major>.<minor>.<patch> tags, currently 1.x). A v* tag builds and signs the container images for api-gateway, scheduler, safety-kernel, workflow-engine, context-engine, mcp, dashboard and the demo quickstart worker, and publishes the Helm chart (docker.yml). The separate desktop binary workflow builds cordum-hook, cordum-agentd and cordum-claude; publication requires its signed-manifest gate to pass. cordumctl is built from source (make build). The default docker compose stack runs api-gateway, scheduler, safety-kernel, workflow-engine, context-engine and dashboard with NATS and Redis. Cordum's own Python and TypeScript SDKs use separate sdk-python-v* and sdk-ts-v* tags.
CAP (v2.x tags). The protocol and its SDKs release from cordum-io/cap. Cordum consumes a pinned CAP release through go.mod (github.com/cordum-io/cap/v2 v2.17.0 at the time of writing), so a CAP SDK release does not require a core release, and a core release does not require a CAP release.

Star History

Ready to govern your AI agents?
CAP Protocol · Integrations · Discord

If Cordum helps you deploy agents safely, give it a ⭐

Name		Name	Last commit message	Last commit date
.github		.github
cmd		cmd
config		config
cordum-helm		cordum-helm
core		core
dashboard		dashboard
demo		demo
deploy-artifacts/full-system-20260506-105613		deploy-artifacts/full-system-20260506-105613
deploy		deploy
docs		docs
examples		examples
scripts		scripts
sdk		sdk
tests		tests
tools		tools
wiki		wiki
.dockerignore		.dockerignore
.env.example		.env.example
.gitattributes		.gitattributes
.gitignore		.gitignore
.gitleaks.toml		.gitleaks.toml
.goreleaser.yml		.goreleaser.yml
.lycheeignore		.lycheeignore
ADOPTERS.md		ADOPTERS.md
BENCHMARKS.md		BENCHMARKS.md
CHANGELOG.md		CHANGELOG.md
CODE_OF_CONDUCT.md		CODE_OF_CONDUCT.md
COMMANDS.md		COMMANDS.md
CONTRIBUTING.md		CONTRIBUTING.md
DESIGN.md		DESIGN.md
Dockerfile		Dockerfile
Dockerfile.localcap		Dockerfile.localcap
GOVERNANCE.md		GOVERNANCE.md
LICENSE		LICENSE
Makefile		Makefile
NOTICE		NOTICE
README.md		README.md
RELEASING.md		RELEASING.md
ROADMAP.md		ROADMAP.md
SECURITY.md		SECURITY.md
SUPPORT.md		SUPPORT.md
TESTING.md		TESTING.md
VERSIONING.md		VERSIONING.md
cordum-claude.ps1		cordum-claude.ps1
cordum-dashboard-design-language.md		cordum-dashboard-design-language.md
cordum-dashboard-page-specs.md		cordum-dashboard-page-specs.md
cordum.yaml		cordum.yaml
docker-compose.ci.yml		docker-compose.ci.yml
docker-compose.dev.yml		docker-compose.dev.yml
docker-compose.enterprise.override.yml		docker-compose.enterprise.override.yml
docker-compose.ha.yaml		docker-compose.ha.yaml
docker-compose.porttest.yml		docker-compose.porttest.yml
docker-compose.release.yml		docker-compose.release.yml
docker-compose.yml		docker-compose.yml
go.mod		go.mod
go.sum		go.sum
hello.go		hello.go
lychee.toml		lychee.toml
package-lock.json		package-lock.json
package.json		package.json
pnpm-lock.yaml		pnpm-lock.yaml
security_policy_test.go		security_policy_test.go

Latest commit

History

Folders and files

Repository files navigation

Cordum

Quickstart

First Time?

Option A: Install from source

Option B: Run the published images

Ports

After Setup

Troubleshooting

See a 3-verdict demo

Edge Quickstart (Compliance Firewall for Claude Code)

Why Pre-Dispatch Action Governance?

The Solution: Cordum Agent Control Plane

Governance Across the Lifecycle

Cordum Edge: Compliance Firewall for AI agents

Development

Key Features

Architecture

Documentation

Protocol: CAP — The Open Standard for Agent Governance

CAP vs. MCP: Why You Need Both

MCP Server

SDK

Integration Packs

Community

Enterprise

Governance

Roadmap

Changelog

Where Cordum Fits in the Agent Stack

Contributing

License

Versioning

Star History

About

Topics

Resources

Code of conduct

Contributing

Security policy

Stars

Watchers

Forks

Releases

Packages

Used by

Contributors

Languages