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
| 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 |
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.shPrerequisites: 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.envasCORDUM_ADMIN_PASSWORD; change it before exposing the stack). - Gateway at http://localhost:8081 with a generated
CORDUM_API_KEYin.env. - TLS CA, server, and client keypairs under
./certs/. - A working approval-gate workflow proven by the built-in
platform_smoke.shrun.
Full walkthrough, platform notes, and troubleshooting: docs/quickstart.md.
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 neededDashboard: 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:8082Deploy 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.
| 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
.envfile before starting the stack.
# 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| 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.
Once the stack is up, install the demo-quickstart pack and run the
governance demo:
cordumctl pack install ./demo/quickstart/pack
cordumctl demo run quickstartA 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.
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 claudeThe 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.
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,THROTTLEorALLOW_WITH_CONSTRAINTS. The gateway, scheduler and Edge evaluate path treat an unknown verdict asDENY. - Hash-bound approvals. A gated action's approval is looked up by tenant and
approval_refand must carry the same SHA-256action_hashas the action being run; a changed payload is rejected asapproval_mismatch. Self-approval, expired and already-consumed approvals are rejected too. - Declarative YAML policies. Rules in
config/safety.yamlmatch 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_tagson any plan. Agent identities, which carry the risk tier thatagent_risk_tiersrules match, require an Enterprise license. - Cordum Edge. A local hook evaluates coding-agent tool calls (Claude Code today) against the gateway before they run. See Edge Quickstart.
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
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 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.
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 downdocker-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. |
| 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. |
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
| 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 |
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.
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
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/messageand/mcp/sse(whenmcp.enabled=true)
See docs/mcp-server.md for setup, auth headers, and client configuration examples.
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.
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 |
- Discord: Join the conversation
- GitHub Discussions: Ask questions
- Twitter/X: @Cordum_io
- Email: See SECURITY.md for contact details
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.
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
See ROADMAP.md for the full feature roadmap, completed milestones, and planned work.
See CHANGELOG.md for a detailed log of all changes by version.
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. |
We welcome contributions! See CONTRIBUTING.md for guidelines. Check out our good first issues to get started.
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.
Cordum core and CAP release independently, each with its own tags (VERSIONING.md):
- Cordum core (
v<major>.<minor>.<patch>tags, currently 1.x). Av*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 buildscordum-hook,cordum-agentdandcordum-claude; publication requires its signed-manifest gate to pass.cordumctlis built from source (make build). The defaultdocker composestack runs api-gateway, scheduler, safety-kernel, workflow-engine, context-engine and dashboard with NATS and Redis. Cordum's own Python and TypeScript SDKs use separatesdk-python-v*andsdk-ts-v*tags. - CAP (
v2.xtags). The protocol and its SDKs release from cordum-io/cap. Cordum consumes a pinned CAP release throughgo.mod(github.com/cordum-io/cap/v2 v2.17.0at 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.
Ready to govern your AI agents?
CAP Protocol · Integrations · Discord
If Cordum helps you deploy agents safely, give it a ⭐


