OpenClaw 2.0 ve Sigil: Otonom Yapay Zeka Ajanları İçin Doğrulanabilir Yetki Oluşturma

Bir süre sessiz kalan «Yengeç» OpenClaw, 30 Ağustos'ta 2.0 sürümünü yayınladı.

Resmi açıklamaya göre, bu, OpenClaw tarihinin en büyük güncellemesi olup, 16.000'den fazla Pull Request birikmiş ve kurulum, mesajlaşma, bellek, Beceriler, modeller, Otomasyonlar, tarayıcı, yerel uygulamalar, Eklentiler ve güvenlik mekanizmaları dahil olmak üzere tüm ürün yığınına dokunmuştur.

Ancak bu karmaşık fonksiyon listesine kıyasla, daha da önemli olan OpenClaw 2.0'ın ardında giderek daha netleşen gelişim rotası: Agent'lar artık giderek daha fazla «gerçek işler yapma» yeteneğine sahip oluyor.

Aynı zamanda, agenterin giderek daha fazla "nasıl yapılacağını" kendi karar verebilmesiyle sektörü, her kritik işlemin kullanıcının gerçekten yetki verdiği sınırları aşmadığından nasıl emin olunacağına dair kaçınılmaz bir güven sorununa götürüyor.

Geçen yıl, AI Agent'ların en belirgin değişimi, temel modellerin daha akıllı hale gelmesinden ibaret değil.

MCP, Beceri, Eklentiler, tarayıcı kontrolü ve kod yürütme gibi altyapılar olgunlaştıkça, Ajanlar bilgiyi değiştirmek, düğmelere tıklamak veya computer use aracılığıyla tarayıcıyı doğrudan kontrol etmek gibi dış dünyaya gerçek etki edebilecek giderek daha fazla “el ve ayak” kazanmaya başlıyor (Daha fazla bilgi için Agentic AI拐点已至？当 AI 学会「自己行动」，如何重构 Web3 的安全边界？’e bakın).

Ancak sorun tam olarak burada ortaya çıkıyor, mevcut etkileşim paradigmaları altında genellikle iki aşırıya kaçılır.

Birisi, özel anahtarı veya yeterince geniş yetkilere sahip, uzun süre geçerli bir Session Key'i Agent'e doğrudan vererek, onun kendi kararına göre işlem yapmasını sağlamaktır.

Bu modelin otomatik deneyimi elbette en iyidir, ancak risk de aynı ölçüde odaklanmıştır; bir kez sözcük enjeksiyonu, kötü niyetli bir web sayfası veya çevre kirliliğiyle karşılaşıldığında ya da modelin kendisi anlama hatası yaparsa, hata tüm yürütme zinciri boyunca yayılabilir ve nihayetinde gerçek işlemlere dönüşebilir (Daha fazla bilgi için Sign sadece imza değil: AI Agent sizin yerinize imza attığında, kim hâlâ kontrolü elde tutuyor?).

Aslında genel internet senaryolarında bu, sadece yanlış bir e-posta göndermek veya yanlış bir dosyayı silmek olabilir, ancak zincir üzerinde bir hata işlemi genellikle geri alınamaz.

Diğeri ise tamamen yetki vermemek, her işlem ve her alt çağrıda imza onay penceresini göstererek onay istemektir; güvenlik artar ancak otomasyonun anlamı büyük ölçüde azalır.

Bir Agent, kullanıcıya karmaşık bir DeFi stratejisi tamamlamada yardımcı olurken, arada birçok adım yer alır; eğer her adımda kullanıcı telefonu eline alıp tek tek «Onayla» butonuna basmak zorunda kalırsa, kullanıcı aslında «kendi butonlarına basmak»ten ziyade, Agent için sürekli onay damgası basan «insanlı bir onay makinesi» haline gelir.

Yani, ortadaki esneklik, hem Ajantın verimliliğini artırmanın kaynağıdır, hem de yeni bir risk kaynağıdır.

Bu bakış açısıyla sorunun özü, "Agent'e yetki verilip verilmemesi" değil, yetki verme düzeyinin ve doğrulama mekanizmasının dinamik esnekliğe sahip olup olmamasıdır, çünkü geleneksel yetki yönetimi ikili bir yapıdadır (ya izin verilir ya da reddedilir), oysa Agent'in karşılaştığı görevler çok daha karmaşıktır.

Aynı bir işlem olsa da, 10 dolar ve 100.000 dolar farklıdır; uzun vadeli kullanılan bir protokol ile etkileşim kurmak, aniden bilinmeyen bir sözleşmeye yetki vermekten farklıdır; kullanıcı tarafından açıkça istenen bir Swap işlemi tamamlamak, bir Agent'in varlıkları kendi kararıyla başka bir zincire aktarmasından farklı bir risk seviyesidir.

Yani, Agent ne kadar özgürce hareket edebiliyorsa, yetkileri o kadar basit bir anahtar olamaz.

İçinde serbestçe hareket edebilmesi ve sınırı aştığında otomatik olarak durması için gerekli olan, bir güvenlik mekanizmasıdır.

Aslında, OpenClaw bu sorunu görmezden gelmedi.

Şu anda, eklentilerin belirli işlemler yürütülmeden önce duraklatıp kullanıcı onayı talep etmesi gibi çok katmanlı izin mekanizmaları sunar; ana makine komutları söz konusu olduğunda, bağımsız Exec Approvals ve Allowlist gibi özellikler de mevcuttur.

Tüm araçları ve yetkileri bir seferde Agent'e vermekten çok daha ileriye gidildi. Ancak Agent gerçek bir ödeme, işlem ve varlık yönetimi senaryosuna girdiğinde, daha ayrıntılı bir sorun ortaya çıkar: Bir yeteneği Agent'e kullanma izni vermek, Agent'e belirli bir eylemi tamamlama izni vermekle aynı şey değildir.

Ajan'a tarayıcı kullanma izni vermek, herhangi bir web sitesinde herhangi bir şey satın alma izni vermek anlamına gelmez; Ajan'a e-posta hesabına erişim izni vermek, sizin adınıza herhangi birine e-posta gönderme izni vermek anlamına gelmez; aynı şekilde, Ajan'a cüzdan çağırma izni vermek, herhangi bir miktarı herhangi bir adrese gönderme izni vermek anlamına gelmemelidir.

Bu nedenle, Agent nesil yetki sistemi, iki farklı soruyu ayırt etmek zorunda olabilir. Birincisi, Agent'in tarayıcı, terminal, e-posta veya cüzdan kullanıp kullanamayacağına dair yetki; diğeri ise daha spesifik eylem izni, yani şu anda gerçekleştirmek üzere olduğu şeyin gerçekten kullanıcı tarafından izin verilen bir eylem olup olmadığı.

Agent'in açık sınırlar içinde tamamen otomatikleştirilmesi ve gerçek sınırların dışına çıktığında karar verme yetkisinin tekrar kullanıcıya verilmesi nasıl sağlanır?

Bu, imToken'un Sigil'i araştırmasının nedenidir. Temel amacı, Agent'e geleneksel bir «onay penceresi» eklemek değil, doğrulanabilir imza ve ince düzeyde izin kontrolü aracılığıyla kullanıcı ile Agent arasında açıkça sınırlanabilir bir güvenlik koruması oluşturmayı denemektir.

En önemli ilkelerden biri, "Gördüğünüz şeyi imzalayın"tır.

Kısaca, kullanıcılar, Agent'e belirli bir yetki aralığı vererek düşük riskli ve belirlenmiş stratejiye uygun davranışların otomatik olarak tamamlanmasını sağlayabilir; işlem, tutar sınırlarına, tanımadığı protokollere veya diğer kritik yetki sınırlarına ulaştığında yürütme durdurulur ve özel talep kullanıcıya onay için geri verilir.

Daha önemlisi, bu onay sadece belirsiz bir «Ajan işlemi gerçekleştirmeye hazır, onaylıyor musunuz?» cümlesi olmamalıdır; kullanıcıların gerçekten görmesi gereken, bu işlemde gerçek değişen kritik parametrelerdir: hangi varlık kullanılacak, miktar ne kadar, etkileşim kiminle olacak ve nihayetinde tam olarak ne yapılacaktır.

Bir onay, kullanıcının gördüğü içerik, kullanıcının yetkilendirdiği içerik ve sistemin sonunda gerçekleştirdiği içerik birbirine uyduğunda gerçek anlam kazanır.

Sigil, bu noktaya odaklanarak, ana yetkilendirmenin sadece kullanıcı tarafından anlaşılabilir olmasını değil, aynı zamanda sistem tarafından doğrulanabilir olmasını sağlamak için Passkey, biyometrik, tek seferlik imza, kısa süreli geçerlilik ve istek parametreleri bağlama mekanizmalarını da denedi.

Bu, bir yetkilendirmenin sadece "kimse onayladı" anlamına gelmediğini, aynı zamanda kimin onayladığını, neyin onaylandığını ve sonunda gerçekleştirlenin, o anda görülen şey olup olmadığını da açıklayabileceğini anlamına gelir.

Bu açıdan bakıldığında, Sigil'in gerçekten çözmeye çalıştığı şey, "Agent'ın daha az şey yapmasını sağlamak" değildir.

Tam tersine.

Amaç, kullanıcının nihai kontrolünü elden almadan, Agent'in daha fazla şey yapmasına güvenle izin vermektedir (Daha fazla bilgi için Şu 'Evet'e Basmaktan, İmzalamadan Önce Anlamaya: Sigil, AI Agent'lere Nasıl Güvenlik Bir Koruma Sağlar? başlıklı makaleye bakın).

Daha da geriye çekilirse, bu aslında cüzdanın yaşadığı bir rol değişimi olarak görülebilir.

Ethereum'in doğuşundan beri, imToken cüzdanı iki ana nesli doğrudan yaşadı ve gözlemledi: tek bir özel anahtar yönetimiyle başlayan 1.0 nesli ile, hesap soyutlaması (AA) aracılığıyla etkileşim deneyimini iyileştiren 2.0 nesli.

OpenClaw 2.0 gibi kendi kendine çalışan Agent'ların yaygınlaşmasıyla cüzdanlar, kendisi karar veren ve sürekli çalışan Agent'ları yönetmeye kullanıcılara yardımcı olmak için üçüncü nesil gelişime girmiştir.

Bu, cüzdan endüstrisinin geçmişte birikmiş olan özel anahtar yönetimi, dijital imza, kimlik doğrulama ve izin izolasyonu yeteneklerinin, Agent eraında yeni bir anlam kazanabileceğini de açıklar.

Bu teknolojilerin görünürde «bir zincir üzerindeki işlemi nasıl güvenli bir şekilde imzalayacağım» sorununu çözmeyi amaçladığını düşünürken, aslında daha genel bir sorunu ele alıyorlar: bir eylemin, bir varlığın gerçek yetkisiyle yapıldığını nasıl kanıtlayabiliriz?

Bugün bu eylem 1 ETH çıkarmak olabilir. Gelecekte, bir e-posta göndermek, bir dosyayı değiştirmek, bir dijital kimlik kullanmak, bir hizmet satın almak veya bir Agent'in gelecek hafta boyunca otomatikleştirilmiş bir stratejiyi sürekli olarak uygulamasını izin vermek olabilir.

Bu davranışların tümü blok zinciri üzerinde gerçekleşmeyebilir, ancak temel ilişkiler çok benzerdir: Agent, kullanıcı adına kullanıcıya ait bir yeteneği çağırıyor.

Bu nedenle, Sigil'in anlamı sadece Crypto'ya sınırlı olmayabilir.

OpenClaw, Hermes ve daha fazla kişinin cihazlarında veya bulut ortamında çalışan Agent, e-posta, anlık mesajlaşma, takvim, dosya, tarayıcı, terminal ve ödeme araçlarına bağlandıkça, "bu eylemin gerçekten kullanıcı onayıyla gerçekleştirildiğini nasıl kanıtlarız?" sorusu giderek daha yaygın hale gelecektir.

Bu nedenle Sigil, gelecekte zincir üzerindeki işlemlerden veri erişimi, kimlik kullanımı, dosya değiştirme, içerik yayınlama, hizmet satın alma ve otomasyon görevlerine kadar genişleyebilir.

Genel olarak, imToken ile OpenClaw'un ortak araştırması olarak Sigil, imToken'ın son on yıl içinde kendi kontrolü altında tutma, cüzdan ve dijital imza alanlarında biriktirdiği deneyimleri, kendi kendine çalışan Agent'ların gerçek yürütme ortamına girmeye başladığı yeni aşamaya taşımayı amaçlıyor.

Bu, Agent yerine geçmez veya cüzdanı kaldırmaz.

İkisi arasında duruyor.