DEV Community: yaron torjeman

Every AI agent framework focuses on making agents smarter. None of them ask what happens when agents screw up.

yaron torjeman — Sun, 08 Feb 2026 21:59:04 +0000

New agent framework drops every week. CrewAI. LangChain. AutoGen. OpenAI Agents SDK.

They all compete on the same axis: how smart can we make the agent?

Nobody's competing on: how do we stop it from deleting prod?

I work in DevOps. I manage Kubernetes clusters, CI/CD pipelines, and cloud infrastructure for a living. I've watched teams build incredible AI agent demos that can manage infrastructure, write code, push deployments.

Then the security review happens.

"So this thing can just… run kubectl delete namespace production?"

"Well technically"

"No."

Demo stays in staging. Forever. I've seen this three times this year alone.

The gap nobody's filling

Here's the thing. Airflow, Temporal, n8n — they're great at running stuff. But they don't care what they're running. Safety is your problem.

Agent frameworks? They care about reasoning, tool selection, memory. They don't care what happens when the reasoning is wrong.

There's a gap between "the agent decided to do X" and "X actually happened in production." Nobody owns that gap.

So I built something to own it.

Cordum

Cordum is an open-source control plane that sits between AI agents and infrastructure. Every intent gets intercepted and evaluated before execution.

Agent: "I want to run kubectl delete namespace production"
    ↓
Cordum Safety Kernel: evaluates against policy
    ↓
Decision: DENY — "Destructive operations on production are not allowed"
    ↓
Result: Command never reaches your cluster.

That's the entire idea. Policy-as-code, evaluated pre-dispatch, with a full audit trail.

What it looks like in practice

You write policies in YAML:

rules:
  - id: block-destructive-prod
    match:
      risk_tags: [destructive, production]
    decision: deny
    reason: "Destructive prod operations blocked"

  - id: approve-prod-writes
    match:
      risk_tags: [production, write]
    decision: require_approval
    reason: "Production writes need human sign-off"

Four possible outcomes:

Decision	What happens
`allow`	Action proceeds, fully logged
`deny`	Blocked. Never reaches infrastructure
`require_approval`	Human gets pinged. Action waits
`constrain`	Allowed, but with enforced limits

The kernel evaluates every action in under 5ms. Not a sidecar. Not a webhook. It's in the execution path.

Architecture

┌─────────────────────────────────────────┐
│  Agent (Claude, GPT, CrewAI, whatever)  │
└─────────────────┬───────────────────────┘
                  ↓
┌─────────────────┴───────────────────────┐
│  Cordum Control Plane                   │
│  ┌──────────────────────────────────┐   │
│  │  Safety Kernel (policy gate)     │   │
│  │  → allow / deny / approve / cap  │   │
│  └──────────────────────────────────┘   │
│  ┌──────────────────────────────────┐   │
│  │  Scheduler + Workflow Engine     │   │
│  └──────────────────────────────────┘   │
└─────────────────┬───────────────────────┘
                  ↓
┌─────────────────┴───────────────────────┐
│  Infrastructure (K8s, AWS, GitHub, etc) │
└─────────────────────────────────────────┘

Built in Go. NATS JetStream for durable messaging. Redis for state. Not a Python wrapper around an LLM API call.

What Cordum is NOT

This matters:

It's not an agent framework. It doesn't replace CrewAI or LangChain. It governs them. Use whatever agent framework you want — Cordum sits underneath.

It's not a workflow engine. Airflow runs DAGs. Cordum decides whether a step in your DAG is allowed to run.

It's not post-hoc logging. By the time you're reading logs, the damage is done. Cordum blocks bad actions before they execute.

The pack system

Want to add capabilities? Install a pack:

cordum pack install slack
cordum pack install kubernetes
cordum pack install github

16 packs available. Each ships as a signed OCI container. Installs with policy overlays — so new capabilities come with governance built in.

Rough edges

It's v0.1.0. I'm not going to pretend otherwise.

The docs need work. Some error messages are cryptic. The dashboard is functional, not pretty. I'm one developer building this between my day job and too much coffee.

But the core — the Safety Kernel, the CAP protocol, the policy engine — that works. It's in production. The architecture decisions are ones I'd make again.

Why I think this matters

We're in a weird moment. Everyone's racing to give agents more autonomy. More tool access. More decision-making power. And the governance story is basically: "we'll figure it out later."

Later is a kubectl delete away from being too late.

⭐ GitHub: github.com/cordum-io/cordum
🌐 Website: cordum.io
📖 Docs: cordum.io/docs

If you've ever had an agent demo killed by a security review — I built this for you.

What's your team's approach to agent governance? Genuinely curious. I keep hearing "we just don't deploy them to prod" and that can't be the final answer.

[Boost]

yaron torjeman — Mon, 26 Jan 2026 21:02:47 +0000

# MCP vs CAP: Why Your AI Agents Need Both Protocols

yaron torgeman ・ Jan 26

#ai #mcp #agents #programming

[Boost]

yaron torjeman — Fri, 16 Jan 2026 20:37:55 +0000

Why I Spent 6 Months Building Guardrails for AI Agents

yaron torjeman ・ Jan 16

#programming #ai #opensource #github

What Happens When You Give an AI Agent Root Access?

yaron torjeman — Fri, 16 Jan 2026 20:33:43 +0000

It deletes your production database. Merges a broken PR. Sends 10,000 Slack messages. Spins up $50K worth of EC2 instances.

I'm kidding. Mostly.

But here's the thing: AI agents are getting root access everywhere, and we're pretending guardrails will magically appear later.

They won't.

So I spent the last few months building Cordum - an open-source governance layer for AI agents. Every action goes through a policy check before it executes.

Here's why I built it, how it works, and what I learned.

The Problem: AI Agents Are Powerful but Terrifying

I've been obsessed with AI agents - not chatbots, but agents that actually do things. Agents that can:

Merge pull requests
Deploy to Kubernetes
Update database records
Send Slack messages on your behalf

The technology is ready. But every time I tried to deploy one to production, the same thing happened:

Security said no.

And honestly? They were right.

Think about it: you're giving an AI the ability to write to production systems, and there's no audit trail, no approval workflow, no way to enforce policies. It's like giving an intern root access and hoping for the best.

I kept seeing teams stuck in what I call "PoC Purgatory" - amazing demos that never ship because there's no governance story.

The Solution: Policy-Before-Dispatch

What if every AI action had to pass through a policy check before it executed?

That's the core idea behind Cordum.

┌─────────────┐     ┌──────────────┐     ┌─────────────┐
│   AI Agent  │ --> │ Safety Kernel │ --> │   Action    │
└─────────────┘     └──────────────┘     └─────────────┘
                           │
                    ┌──────┴──────┐
                    │   Policy    │
                    │  (as code)  │
                    └─────────────┘

Before ANY job executes, the Safety Kernel evaluates your policy and returns one of:

✅ Allow - proceed normally
❌ Deny - block with reason
👤 Require Approval - human in the loop
⏳ Throttle - rate limit

Show Me the Code

Here's what a policy looks like:

# policy.yaml
rules:
  - id: require-approval-for-prod
    match:
      risk_tags: [prod, write]
    decision: require_approval
    reason: "Production writes need human approval"

  - id: block-destructive
    match:
      capabilities: [delete, drop, destroy]
    decision: deny
    reason: "Destructive operations not allowed"

  - id: allow-read-only
    match:
      risk_tags: [read]
    decision: allow

When an agent tries to do something dangerous, Cordum intervenes:

{
  "job_id": "job_abc123",
  "decision": "require_approval",
  "reason": "Production writes need human approval",
  "matched_rule": "require-approval-for-prod"
}

The job waits until a human approves it in the dashboard. Full audit trail. Compliance happy.

Architecture

Cordum is a control plane, not an agent framework. It orchestrates and governs agents - it doesn't replace LangChain or CrewAI.

┌─────────────────────────────────────────────────────────┐
│                    Cordum Control Plane                  │
├─────────────────────────────────────────────────────────┤
│  ┌───────────┐  ┌──────────────┐  ┌─────────────────┐  │
│  │ Scheduler │  │ Safety Kernel │  │ Workflow Engine │  │
│  └───────────┘  └──────────────┘  └─────────────────┘  │
├─────────────────────────────────────────────────────────┤
│  ┌───────────────┐  ┌───────────────────────────────┐  │
│  │  NATS Bus     │  │  Redis (State)                │  │
│  └───────────────┘  └───────────────────────────────┘  │
└─────────────────────────────────────────────────────────┘
         │                    │                    │
    ┌────┴────┐          ┌────┴────┐          ┌───┴────┐
    │ Worker  │          │ Worker  │          │ Worker │
    │ (Slack) │          │ (GitHub)│          │ (K8s)  │
    └─────────┘          └─────────┘          └────────┘

Tech stack:

Go - Core control plane (~15K lines)
NATS JetStream - Message bus with at-least-once delivery
Redis - State store for jobs, workflows, context
React - Dashboard with real-time updates

Performance:

< 5ms policy evaluation latency
10k+ events/sec per node
100% deterministic replay

The Protocol: CAP

I also built a protocol called CAP (Cordum Agent Protocol). Think of it as MCP (Model Context Protocol) but for distributed orchestration.

MCP is great for tool calling within a single model. But it doesn't cover:

Scheduling across worker pools
Policy enforcement
State machine (pending → running → succeeded)
Heartbeats and worker liveness

CAP fills those gaps. It's a separate repo with SDKs for Go, Python, Node, and C++.

// Hello World worker in Go
worker := cordum.NewWorker(cordum.Config{
    Pool:     "my-workers",
    Subjects: []string{"job.hello.*"},
})

worker.Handle("job.hello.greet", func(ctx cordum.JobContext) error {
    name := ctx.Input["name"].(string)
    return ctx.Succeed(map[string]any{
        "message": fmt.Sprintf("Hello, %s!", name),
    })
})

worker.Run()

Pre-Built Packs

Nobody wants to write integrations from scratch. Cordum comes with 16 pre-built packs:

Category	Packs
Communication	Slack, MS Teams, Webhooks
DevOps	GitHub, GitLab, Jira
Infrastructure	Kubernetes, Terraform, Vault
Monitoring	Prometheus, Sentry, OpenTelemetry
AI/LLM	MCP Bridge, MCP Client

Install with one command:

cordumctl pack install slack

Quick Start

Want to try it? Here's the 60-second version:

git clone https://github.com/cordum-io/cordum
cd cordum
docker compose up -d

Open http://localhost:8082 - that's your dashboard.

What I Learned Building This

1. Safety as a feature, not a constraint

I initially thought of governance as a "necessary evil" - something enterprises need for compliance. But I've come to see it as a feature.

When you can prove that every AI action was evaluated against policy and logged, you unlock use cases that were previously impossible. Banks can use AI agents. Healthcare can use AI agents. The "permission to write" becomes a competitive advantage.

2. The protocol matters more than I expected

I spent a lot of time on CAP, and it paid off. Having a clean protocol means:

Workers can be written in any language
The control plane can evolve independently
Third parties can build compatible tools

3. Open source is a distribution strategy

I could have built this as a closed SaaS from day one. But open source:

Builds trust (you can read the code)
Enables self-hosting (enterprises love this)
Creates a community funnel

The business model is open core: self-hosted is free forever, cloud/enterprise features are paid.

What's Next

The roadmap includes:

Helm chart for Kubernetes deployment
Cordum Cloud - managed version
Visual workflow editor in the dashboard
More packs - AWS, GCP, PagerDuty, etc.

Try It Out

🌐 Website: https://cordum.io
📦 GitHub: https://github.com/cordum-io/cordum
📋 Protocol: https://github.com/cordum-io/cap
📚 Docs: https://cordum.io/docs

If you're building AI agents and want governance built in, give it a try. Star the repo if you find it useful ⭐

I'd love feedback - what's missing? What would make this useful for your projects?

Thanks for reading! I'm happy to answer questions in the comments.

Why I Spent 6 Months Building Guardrails for AI Agents

yaron torjeman — Fri, 16 Jan 2026 20:23:00 +0000

Here's why I built it, how it works, and what I learned.

The Problem: AI Agents Are Powerful but Terrifying

I've been obsessed with AI agents - not chatbots, but agents that actually do things. Agents that can:

Merge pull requests
Deploy to Kubernetes
Update database records
Send Slack messages on your behalf

The technology is ready. But every time I tried to deploy one to production, the same thing happened:

Security said no.

And honestly? They were right.

I kept seeing teams stuck in what I call "PoC Purgatory" - amazing demos that never ship because there's no governance story.

The Solution: Policy-Before-Dispatch

What if every AI action had to pass through a policy check before it executed?

That's the core idea behind Cordum.

┌─────────────┐     ┌──────────────┐     ┌─────────────┐
│   AI Agent  │ --> │ Safety Kernel │ --> │   Action    │
└─────────────┘     └──────────────┘     └─────────────┘
                           │
                    ┌──────┴──────┐
                    │   Policy    │
                    │  (as code)  │
                    └─────────────┘

Before ANY job executes, the Safety Kernel evaluates your policy and returns one of:

✅ Allow - proceed normally
❌ Deny - block with reason
👤 Require Approval - human in the loop
⏳ Throttle - rate limit

Show Me the Code

Here's what a policy looks like:

# policy.yaml
rules:
  - id: require-approval-for-prod
    match:
      risk_tags: [prod, write]
    decision: require_approval
    reason: "Production writes need human approval"

  - id: block-destructive
    match:
      capabilities: [delete, drop, destroy]
    decision: deny
    reason: "Destructive operations not allowed"

  - id: allow-read-only
    match:
      risk_tags: [read]
    decision: allow

When an agent tries to do something dangerous, Cordum intervenes:

{
  "job_id": "job_abc123",
  "decision": "require_approval",
  "reason": "Production writes need human approval",
  "matched_rule": "require-approval-for-prod"
}

The job waits until a human approves it in the dashboard. Full audit trail. Compliance happy.

Architecture

Cordum is a control plane, not an agent framework. It orchestrates and governs agents - it doesn't replace LangChain or CrewAI.

┌─────────────────────────────────────────────────────────┐
│                    Cordum Control Plane                  │
├─────────────────────────────────────────────────────────┤
│  ┌───────────┐  ┌──────────────┐  ┌─────────────────┐  │
│  │ Scheduler │  │ Safety Kernel │  │ Workflow Engine │  │
│  └───────────┘  └──────────────┘  └─────────────────┘  │
├─────────────────────────────────────────────────────────┤
│  ┌───────────────┐  ┌───────────────────────────────┐  │
│  │  NATS Bus     │  │  Redis (State)                │  │
│  └───────────────┘  └───────────────────────────────┘  │
└─────────────────────────────────────────────────────────┘
         │                    │                    │
    ┌────┴────┐          ┌────┴────┐          ┌───┴────┐
    │ Worker  │          │ Worker  │          │ Worker │
    │ (Slack) │          │ (GitHub)│          │ (K8s)  │
    └─────────┘          └─────────┘          └────────┘

Tech stack:

Go - Core control plane (~15K lines)
NATS JetStream - Message bus with at-least-once delivery
Redis - State store for jobs, workflows, context
React - Dashboard with real-time updates

Performance:

< 5ms policy evaluation latency
10k+ events/sec per node
100% deterministic replay

The Protocol: CAP

I also built a protocol called CAP (Cordum Agent Protocol). Think of it as MCP (Model Context Protocol) but for distributed orchestration.

MCP is great for tool calling within a single model. But it doesn't cover:

Scheduling across worker pools
Policy enforcement
State machine (pending → running → succeeded)
Heartbeats and worker liveness

CAP fills those gaps. It's a separate repo with SDKs for Go, Python, Node, and C++.

// Hello World worker in Go
worker := cordum.NewWorker(cordum.Config{
    Pool:     "my-workers",
    Subjects: []string{"job.hello.*"},
})

worker.Handle("job.hello.greet", func(ctx cordum.JobContext) error {
    name := ctx.Input["name"].(string)
    return ctx.Succeed(map[string]any{
        "message": fmt.Sprintf("Hello, %s!", name),
    })
})

worker.Run()

Pre-Built Packs

Nobody wants to write integrations from scratch. Cordum comes with 16 pre-built packs:

Category	Packs
Communication	Slack, MS Teams, Webhooks
DevOps	GitHub, GitLab, Jira
Infrastructure	Kubernetes, Terraform, Vault
Monitoring	Prometheus, Sentry, OpenTelemetry
AI/LLM	MCP Bridge, MCP Client

Install with one command:

cordumctl pack install slack

Quick Start

Want to try it? Here's the 60-second version:

git clone https://github.com/cordum-io/cordum
cd cordum
docker compose up -d

Open http://localhost:8082 - that's your dashboard.

What I Learned Building This

1. Safety as a feature, not a constraint

I initially thought of governance as a "necessary evil" - something enterprises need for compliance. But I've come to see it as a feature.

2. The protocol matters more than I expected

I spent a lot of time on CAP, and it paid off. Having a clean protocol means:

Workers can be written in any language
The control plane can evolve independently
Third parties can build compatible tools

3. Open source is a distribution strategy

I could have built this as a closed SaaS from day one. But open source:

Builds trust (you can read the code)
Enables self-hosting (enterprises love this)
Creates a community funnel

The business model is open core: self-hosted is free forever, cloud/enterprise features are paid.

What's Next

The roadmap includes:

Helm chart for Kubernetes deployment
Cordum Cloud - managed version
Visual workflow editor in the dashboard
More packs - AWS, GCP, PagerDuty, etc.

Try It Out

🌐 Website: https://cordum.io
📦 GitHub: https://github.com/cordum-io/cordum
📋 Protocol: https://github.com/cordum-io/cap
📚 Docs: https://cordum.io/docs

If you're building AI agents and want governance built in, give it a try. Star the repo if you find it useful ⭐

I'd love feedback - what's missing? What would make this useful for your projects?

Thanks for reading! I'm happy to answer questions in the comments.

Announcing Bridge: Open-Source Resource Management for Terraform and Kubernetes

yaron torjeman — Sat, 20 Jul 2024 18:39:53 +0000

Hey everyone,

I’m excited to share my latest open-source project called Bridge! 🌉 It’s designed to help manage and integrate resources seamlessly across different tools like Terraform and Kubernetes.

I’m looking for feedback and contributions to make it even better. You can find the project on GitHub: Bridge on GitHub.

Any thoughts or contributions are welcome!

OpenSource #DevOps #Terraform #Kubernetes #Cloud