Cordum: an approval gate between an AI agent and the command it wants to run
The action firewall for AI agents. Enforce policy and human approval before risky tool calls, shell commands, workflows, and production changes, with auditable evidence.
At a glance
- What is it?
- Cordum is a Go control plane that sits in front of agent tool calls, shell commands and production changes, enforcing policy and human approval and recording evidence. It is source-available under BUSL-1.1, and the README's own quickstart is the clearest statement of what it does and does not yet do.
- Who is it for?
- Adopt Cordum if you already run agents that can reach a shell, a cluster or a production API and you need an approval record for those actions; the compose quickstart and the Helm chart both give you a running stack, and the platform_smoke.sh run that ships with the quickstart is the fastest way to see whether the approval flow matches how your team actually signs off on changes.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Cordum is built to close: an agent that can act but cannot be stopped
Most agent frameworks give the model a tool list and trust it. The README frames Cordum as the answer to a different question: knowing what your agents are doing before they do it. That phrasing matters, because the product is positioned as an interception layer rather than an observability layer. Logging what an agent did is a solved problem. Blocking a specific call, or parking it until a person approves, is not.
The audience is implied by the prerequisites. The quickstart asks for Docker Desktop v4+ or Engine v20.10+ with Compose v2 and at least 4 GB of RAM, plus Go 1.26.3+ and curl. That is a platform or infrastructure team, not an individual developer experimenting on a laptop. The Kubernetes path assumes the same team already runs a cluster and has opinions about ingress class and secret handling. Cordum Edge, described in the README as a compliance firewall for Claude Code and other local AI-agent actions, extends the same idea down to a developer's own machine.
What it is not: a sandbox. Nothing in the supplied material suggests Cordum contains the blast radius of a command that has already been approved. It decides whether an action proceeds, not what the action can reach once it does.
Seven services, NATS in the middle, and a policy decision that happens before execution
The quickstart names the components: API gateway, scheduler, safety kernel, workflow engine, context engine, dashboard, NATS, and a TLS-secured Redis. The safety kernel is where policy evaluation lives, and the workflow engine is what makes an approval gate a first-class object rather than an ad hoc prompt. NATS carries messages between them, which is consistent with the nats topic tag on the repository and with a design where the gateway does not call the kernel directly.
The data flow implied by that layout is: an agent or client sends a tool call to the gateway, the gateway hands the decision to the safety kernel, the kernel applies policy, and anything that needs a person becomes a workflow that the workflow engine tracks until it is resolved. The context engine is not described in the README beyond its name, so what it contributes to a decision cannot be confirmed from this material.
The repository also references a separate protocol project, cordum-io/cap, badged as CAP v2. The README links to it but does not explain the wire format, so treat the protocol as an integration surface you would need to read separately before writing your own client.
Running it: one script, or compose plus a cert generator
Option A is a single command. Clone the repository, then run ./tools/scripts/quickstart.sh. The script stands up the full stack with auto-generated secrets and auto-provisioned certificates, then runs a post-deploy smoke test that the README says exercises a real approval workflow via platform_smoke.sh. You end up with a dashboard at http://localhost:8082, a gateway at http://localhost:8081, a generated CORDUM_API_KEY in .env, and a TLS CA plus server and client keypairs under ./certs/. The default dev login is admin with the password ChangeMe123!, also written to .env as CORDUM_ADMIN_PASSWORD. The README says plainly to change it before exposing the stack, and that instruction is not boilerplate.
Option B runs published images instead of building. It still needs Go, because docker compose mounts ./certs but does not create it, so you run go run ./cmd/cordumctl generate-certs first. Then export CORDUM_API_KEY and REDIS_PASSWORD, run docker compose pull and docker compose up -d. Note the difference in authentication between the two paths: Option B leaves user auth off by default and you sign in with the API key, while enabling admin password login requires CORDUM_USER_AUTH_ENABLED=true plus a CORDUM_ADMIN_PASSWORD of at least 12 characters with an uppercase letter, a digit and a special character. Pin a release with CORDUM_VERSION before the pull; the README states that :latest only moves on stable release tags and that pre-release suffixes such as -rc.1 never promote it.
The Helm path is a single helm install against oci://ghcr.io/cordum-io/cordum/charts/cordum with --namespace cordum --create-namespace and a set of --set flags for secrets, Redis password and ingress hosts. The README is unusually direct about the weakness here: --set values land in the Helm release's stored values and in your shell history, and while the chart supports redis.auth.existingSecret, there is no existingSecret equivalent for the API key, so you have to patch secrets.apiKey into the rendered Secret out of band.
Supply chain: cosign verification is per-image, and there are seven images
Every release-tag image is signed with cosign keyless OIDC. The README gives the verification command for api-gateway and then states the constraint that matters: repeat it for each of the seven Cordum images, because verifying one image does not attest the rest. The identity regexp pins the workflow file and the tag pattern, so a verification failure is meaningful rather than cosmetic.
This is a real operational cost. If you deploy from the Helm chart, you are pulling seven images, and a policy of verifying before deploy means seven invocations with the image name swapped. The README points to docs/deployment/images.md for a verify-all-images snippet, which suggests the project knows this is tedious.
The images are multi-arch, linux/amd64 and linux/arm64. The README does not state a support window or how long old tags stay on ghcr.io, so the practical question of whether you can still pull the tag you pinned six months from now is unanswered in this material.
Where Cordum is the wrong tool
Cordum governs actions, not code. If your agent runs untrusted generated code, an approval gate does not make that code safe; it only decides whether the code runs. A container sandbox, a seccomp profile or a network egress policy addresses a different problem, and Cordum does not replace any of them. The README's own framing, an action firewall, should be read literally.
The second boundary is operational weight. The stack is eight named components including NATS and a TLS-secured Redis, with certificates to generate and rotate. For a single developer running one agent against a local repository, that is a large amount of infrastructure to stand up before the first useful decision is made. Cordum Edge exists for the local case, but the README describes it in one sentence and gives no install path, so whether it is lighter in practice is not something this material can establish.
The third is policy authoring. The README describes a safety kernel and a policy engine but does not show a policy file, a rule syntax or an example rule in the material provided. You can stand the stack up in one command; you cannot learn from the README what a useful policy looks like, and that is the part that determines whether the product does anything for you.
The alternative most teams already have: a static allowlist in the agent loop
The comparison that matters is not another control plane. It is the pattern most agent codebases use today: a hardcoded list of permitted commands in the tool wrapper, plus a confirmation prompt in the terminal. That approach is fast to write and has no infrastructure. Its difference from Cordum is not sophistication but where the decision lives. An allowlist is evaluated inside the agent process, by code the agent's own runtime controls, and it produces no artifact afterward. Cordum moves the decision out of the process, into a gateway that the agent calls, and turns the outcome into a workflow record.
That relocation is the whole product. It means the agent cannot edit its own permissions by changing a file in its working directory, and it means an approval is attributable to a person rather than to a y/N keystroke in a log nobody keeps. It also means the gateway becomes a dependency: if the safety kernel or NATS is unavailable, the question of whether actions fail open or fail closed is a design decision you need to confirm, and the supplied material does not say which way Cordum defaults.
If your agents only read data, or run in a disposable environment where the worst outcome is a deleted scratch directory, the allowlist wins on cost and you should keep it.
Licence, maintenance and what a version bump actually costs
The repository metadata reports the licence as NOASSERTION, while the README badge and the LICENSE link both state BUSL-1.1. Those two signals disagree, and this review cannot resolve which is authoritative. Treat that as the first thing to check, because Business Source License terms typically restrict production or competing use and convert to an open licence after a change date. Nothing in the supplied material states the change date, the licensor, or the additional use grant, so the practical question of whether your company can run Cordum in production is unanswered here. This is not legal advice; read the LICENSE file in the repository.
On maintenance, the release history in the supplied material shows v1.0.0 in May 2026, v1.0.1 two weeks later, and v1.1.0 in June 2026, with the last push to main in September 2026. Three releases across roughly a month, then a gap before the most recent commit. That is a normal early cadence, and it also means the API surface is young. The README already documents one concrete migration hazard: the Helm chart has redis.auth.existingSecret but no equivalent for the API key, so a future chart change that adds one is a values migration you would have to perform by hand.
Upgrade cost is dominated by the images rather than the code. Seven multi-arch images, each cosigned, each needing verification at the new tag. The CORDUM_VERSION variable makes the pinning itself trivial; the verification does not scale down.
Editorial conclusion
Adopt Cordum if you already run agents that can reach a shell, a cluster or a production API and you need an approval record for those actions; the compose quickstart and the Helm chart both give you a running stack, and the platform_smoke.sh run that ships with the quickstart is the fastest way to see whether the approval flow matches how your team actually signs off on changes. Do not adopt it as a sandbox for untrusted code, and do not adopt it if your agents only ever read data. Before you commit, verify three things on your own hardware: that the approval-gate workflow completes end to end with your identity provider rather than the default dashboard login, that cosign verification passes for all seven images at the tag you intend to pin, and that the BUSL-1.1 terms permit your specific deployment, since the repository metadata reports NOASSERTION while the README and badge both state BUSL-1.1 and this review cannot resolve that discrepancy.
Community notes