Derbent'i neden yaptım

Aynı repolarda birden fazla coding agent kullanıyorum. Claude Code bir işi yaparken Codex başka bir işi yapıyor, arada Copilot CLI'a bir şey soruyorum. Hepsi işini iyi yapıyor ama hiçbiri diğerlerinin ne yaptığını bilmiyor.

Claude Code'un bir saat önce "bu tablo neden böyle" diye öğrendiğini Codex bilmiyor. Hangi agent'ın hangi komutu çalıştırdığının tek bir kaydı yok. Her CLI'ın kendi MCP server listesi var; GitHub'ı dört kez bağlıyorum. Bir agent'ın git push'tan önce bana sormasını istesem, bunu dört ayrı yerde dört ayrı biçimde ayarlamam gerekiyor.

Derbent bu dağınıklığı toplamak için yazdığım, ücretsiz ve açık kaynak bir araç.

Ne yapıyor?

Derbent, coding agent'larla araçları arasında duran bir kapı. Claude Code, Codex, GitHub Copilot CLI ve Antigravity CLI ona sıradan bir MCP server olarak bağlanıyor; sizin MCP server'larınız onun arkasına geçiyor. Her tool çağrısı kapıdan geçiyor ve kapıda dört şey oluyor.

Ortak hafıza. Agent'ların memory_write, memory_search ve memory_read araçları var. Bir agent'ın bir repoda yazdığı notu, aynı repoda çalışan başka bir agent bulabiliyor. Arama tam metin; bir git worktree'si eklendiği repoyla aynı hafızayı paylaşıyor.

Kurallar. Agent, tool ve argümana göre izin ver, reddet ya da sor. Kurallar sırayla deneniyor, ilk eşleşen kazanıyor. Bir agent'ın kullanamayacağı tool ona hiç listelenmiyor; ismini bilip çağırsa da reddediliyor.

Onay. "Sor" kuralına takılan çağrı siz karar verene kadar bekliyor. Ayrı bir terminalde derbent çalıştırınca bekleyen çağrılar en üstte: bir kez onaylarsınız, o agent'ın oturumunun geri kalanı için onaylarsınız ya da reddedersiniz. Aynısı herhangi bir shell'den derbent approve 12 ile de oluyor. Kimse cevap vermezse süre dolunca çağrı reddediliyor ve agent'a nedeni söyleniyor.

Makbuz. Kapıdan geçen her çağrı bir makbuz bırakıyor: hangi agent, hangi tool, hangi argümanlar, ne karar verildi, sonuç ne oldu. Makbuzlar bir hash zinciri oluşturuyor; derbent verify bir kaydın değiştirilip değiştirilmediğini ya da silinip silinmediğini söylüyor. Secret'lar kaydedilmeden önce maskeleniyor.

Agent'ların kendi araçları, yani shell komutları ve dosya düzenlemeleri, MCP'den geçmiyor. Ama dört CLI'ın da her tool çağrısından önce sizin belirlediğiniz bir komutu çalıştırabildiği bir hook mekanizması var. O komutu derbent gate yapınca bir git push da aynı kurallardan, aynı onaydan ve aynı makbuz zincirinden geçiyor.

İsim

Türk tarihinde derbent, dağ geçitlerindeki ve tehlikeli yollardaki muhafızlı karakollardı. Buraları bekleyen derbentçiler geçidin güvenliğinden sorumluydu, karşılığında bazı vergilerden muaf tutulurlardı. Geçitten kimin geçeceğine karar verir, geçenleri kayda geçirirlerdi.

Denediğim her İngilizce kelime (gatekeeper, warden, checkpoint, bastion) ya başka bir güvenlik ürününün adıydı ya da fazla genel kalıyordu. Derbent hem yaptığı işi birebir anlatıyor hem de kimsenin kullanmadığı bir isim.

Nasıl yapıldı?

En önemli karar: daemon yok. Akla ilk gelen şekil, bütün agent'ların bağlandığı merkezi bir süreç. Ama o merkez her agent'tan önce başlatılmak, ayakta tutulmak, çökünce yeniden başlatılmak zorunda; dinlediği port da ayrıca korunmalı. Derbent'te her agent oturumu kendi kapı sürecini başlatıyor ve hepsi aynı SQLite dosyasını açıyor. Önceden çalışması gereken hiçbir şey yok, açık port yok, bir süreç çökerse sadece o agent'ın kapısı düşüyor.

Bunun bir bedeli var ve dokümanda açıkça yazıyor: her agent oturumu kapının arkasındaki server'ların kendi kopyasını başlatıyor, onaylar da anında değil yoklamayla fark ediliyor.

Go ile yazıldı. Claude Code her tool çağrısında derbent gate sürecini yeniden başlatıyor; yani her shell komutu bir sürecin açılıp karar verip kapanmasını bekliyor. Go binary'si bir yorumlayıcı yüklemeden başlıyor; Windows, macOS ve Linux için tek bir dosya ve makinede başka hiçbir şey istemiyor.

Neyi yapmıyor?

Derbent'in yapmadıklarını yazmak, yaptıklarını yazmak kadar önemliydi.

• Agent ismi bir etiket, kimlik doğrulama değil. Sizin kullanıcınızla çalışan her süreç kendine istediği ismi verebilir.
• Zaten sizin yetkinizle shell'i olan bir agent'a karşı sınır değil. Böyle bir agent derbent approve komutunu kendisi çalıştırabilir ya da veritabanına yazabilir. Onaylar hatalara ve MCP içinde kalan prompt injection'a karşı koruyor.
• Zincir her şeyi tek başına yakalamaz. Ortadaki değişiklikleri buluyor; sondan kesilmiş kayıtlar ya da baştan yeniden yazılmış bir zincir, ancak başka bir yerde sakladığınız son hash ile karşılaştırınca ortaya çıkıyor.
• Glob kuralları shell sözdizimini anlamaz. git push* kuralı cd repo && git push komutunu yakalamaz.

Bir güvenlik aracının yapabileceği en kötü şey, olduğundan fazlasını vaat etmek. Sınırlarını bilerek kullanılan Derbent çok işe yarar; sınırları bilinmeden güvenilen Derbent zarar verir.

Denemek için

go install github.com/tunahanaliozturk/derbent/cmd/derbent@latest

claude mcp add derbent -- derbent mcp --agent claude
codex mcp add derbent -- derbent mcp --agent codex

Bu kadarıyla iki agent aynı hafızayı paylaşmaya başlıyor ve her çağrı kayda geçiyor. Kurallar, onaylar ve hook'lar için dokümantasyona bakabilirsiniz.

Birden fazla coding agent kullanıyorsanız fikrinizi çok isterim; özellikle hangi çağrıların onaya düşmesini istediğinizi merak ediyorum. Issue'lar ve fikirler için GitHub.