Cordum puts an approval gate between an agent and the command it wants to run

A firewall that gates actions rather than screening text

Cordum is described as an action firewall for AI agents. The distinction matters for what it actually inspects: policy and human approval sit in front of risky tool calls, shell commands, workflows and production changes, and the outcome is recorded as auditable evidence. Nothing about the design is about filtering what a model says.

It is packaged as a source-available agent control plane aimed at governance, safety and trust, and it ships alongside a component called Cordum Edge, which is positioned as a compliance firewall for Claude Code and other local agent actions. That pairing covers two different deployment shapes: a central plane that agents call into, and a local enforcement point for actions taken on a developer machine.

The repository is Go, with the module named github.com/cordum/cordum. It is not archived, the last push to main is dated 2026-09-30, and the most recent published release is v1.1.0 from 2026-06-03.

One script stands up eight services and proves the gate works

The shortest path in runs a single script after cloning:

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

That one command brings up an API gateway, a scheduler, a safety kernel, a workflow engine, a context engine, a dashboard, NATS, and a Redis secured with TLS. Secrets are generated automatically, certificates are provisioned automatically, and a post-deploy smoke test exercises a real approval workflow rather than only checking that ports answer.

Prerequisites are Docker Desktop v4 or later, or Docker Engine 20.10 or later with Compose v2 and at least 4 GB of RAM allocated, plus Go 1.26.3 or later for first-run certificate generation and curl. On Windows the script expects MSYS2, Git Bash or WSL.

What you end up with is a dashboard on port 8082 reachable with a default development password that is also written into the environment file, a gateway on port 8081 with a generated API key, and CA, server and client keypairs written under a certs directory.

The two install paths disagree about who owns certificates and login

Running the published images instead of building from source is four extra lines, but the responsibilities move to you:

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

The certificate step exists because Compose mounts the certs directory but will not create it, so on this path generating them is your job rather than the script's.

Login differs too. The source path enables an admin account with a default development password, also written to the environment file, and the documentation is explicit that it must be changed before the stack is exposed. The image path leaves user authentication off by default and expects you to sign in with the API key. Enabling password login there requires an explicit flag plus an admin password of at least 12 characters containing an uppercase letter, a digit and a special character.

Latest moves on stable tags, and signatures are per image

Image tagging has a deliberate rule. The version is pinned by exporting a specific release before pulling, and without that the stack tracks latest, which only advances on stable release tags. Pre-release suffixes carrying a release candidate marker never promote latest.

There are seven Cordum images, published for linux/amd64 and linux/arm64, and mirrored on both GHCR and Docker Hub under a shortened path.

Verification is per image rather than per stack. Every release-tag image is signed with keyless OIDC through cosign, and the documented procedure verifies one service by name and then says to repeat the same command for each of the seven before going to production. The stated reason is blunt: verifying one image does not attest the rest. A deployment that checks a single signature has verified a single artefact.

Helm values passed on the command line outlive the command

The Kubernetes path installs from an OCI hosted chart, but the documentation spends most of its space on a warning rather than the command. Values supplied with set flags are written into the Helm release's stored values and into your shell history, which is described as acceptable for a quick evaluation and wrong for production.

Two consequences follow. For Redis, prefer an existing secret reference over passing the password directly, because the chart offers that option. For the API key there is no such alternative, so the recommendation is to patch the value into the rendered secret out of band rather than passing it on the command line.

That asymmetry is the real finding here. The chart is mature enough to accept an existing secret for one credential and not the other, so an operator following the safe pattern for Redis has no safe pattern to follow for the API key and has to do it manually.

Redis listens on TLS only and skips client certificate checks

The Compose file is more revealing about posture than the summaries are. The Redis service sets the plain TCP port to zero and moves to 6379 over TLS, loading the server certificate, key and CA from the mounted certs directory. It then sets client authentication off, so the client keypairs generated during setup are not actually demanded of connecting clients.

The password is still mandatory, and it is enforced by Compose rather than by Redis: the requirepass argument references an environment variable with a substitution that fails the whole deployment when unset, so a stack cannot come up without it. The health check pings over TLS using the CA certificate and the password.

NATS runs as an Alpine image with its configuration and certificates mounted read only, and its health check hits a monitoring endpoint on port 8222. Everything is TLS terminated at the service rather than at a proxy in front.

The Go module is pinned twice for security reasons

The manifest declares a language version and a separate toolchain version, and the comment between them is the security rationale. The toolchain line requests a newer patch release carrying fixes for several standard library advisories, covering crypto and x509 certificate handling, MIME parsing, net and textproto, a TLS encrypted client hello privacy leak, and a path symlink escape in the os package.

The comment is careful about its own limits. Under the default toolchain resolution the build fetches and uses that release, but it is advisory rather than enforced: a builder pinned to local toolchain resolution with an older patch release ignores it. The stated consequence is that continuous integration must itself run on the newer release for the fixes to apply at all. That is an operational trap worth reading before assuming a green build means a patched binary.

The Dockerfile builds with cgo disabled for a static Linux target, requires a service build argument that must match a directory under cmd, and drops the Go build cache mount after BuildKit was found persisting stale object files across builds.

Editorial conclusion

Cordum is worth the operational weight if you are letting agents touch production and need an auditable record of what was proposed, what was approved and by whom, because the approval gate is the product rather than a feature bolted onto it. It is overkill for a single local agent on a machine you already trust, where eight services and a certificate tree cost more than the risk. Before exposing any of it, change the default admin password, pin CORDUM_VERSION rather than tracking latest, verify all seven image signatures individually, and pass the API key to Helm out of band, since the chart has no existingSecret equivalent and the command line will keep it.

Frequently asked questions

Official sources

1. cordum-io/cordum on GitHub
2. Issues
3. README
4. Releases