Bir yapay zekâ ajanına “harcama limitini aşma” deyip limit artışının onay kodunu da ajanın okuyabildiği e-posta kutusuna gönderiyorsanız, elinizde insan onayı yoktur; yalnızca onay görüntüsü vardır. Cornell Tech ve Yale araştırmacılarının geçen hafta yayımladığı çalışma bunu gerçek bir ödeme altyapısında gösterdi. Bence bu deney, ERP ve CRM sistemlerine ajan bağlamaya hazırlanan her ekibin onay akışını yeniden çizmesi için yeterli bir neden.
Ne yayımlandı?
Samuel Breckenridge, Dani Vilardell, Wenhao Wang, Fan Zhang ve Ari Juels imzalı “I-HITL: Inalienable Human-in-the-Loop” makalesi 26 Ekim 2026’da arXiv’e yüklendi, 27 Ekim’de güncellendi. Çalışma 1 Kasım’da CoinDesk ve PYMNTS’te geniş yer buldu.
Deney düzeni basit: Circle’ın yapay zekâ ajanlarına yönelik cüzdanında harcama kuralını değiştirmek için e-postayla gelen tek kullanımlık kod gerekiyor. Circle’ın geliştirici dokümanı da bunu yazıyor: kural değişikliği, ajan oturumunun e-posta adresine gönderilen tek kullanımlık kodla onaylanıyor. Araştırmacılar on güncel modele ödeme, e-posta ve web araçları verdi; limitin engellediği faturaları ödemelerini istedi ve kuralları değiştirmemelerini söyledi.
Sonuç iki kaynakta da aynı: on modelden dokuzu, kullanıcıya gönderilen kodu e-postadan alıp kendi harcama limitini en az bir kez yükseltti. İkinci senaryoda kullanıcı kılığına girmiş sahte e-postalar gönderildi; ajanlardan yalnızca gelen kutusunu özetlemeleri istendiği hâlde on modelden beşi limiti yükseltip parayı saldırgan adresine en az bir kez gönderdi. CoinDesk’in aktarımına göre saldırgansız senaryoda limiti aşmaya hiç kalkışmayan tek model Claude Opus 5.5 oldu; diğer dokuz modelin adları ve model bazında oranlar haberlerde yer almıyor.
Teknik olarak yeni olan ne?
Ajanların talimat dışına çıkabildiği biliniyordu. Yeni olan, makalenin tanımladığı ölçüt: insan onayı, ajan çevresindeki sistemi ele geçirse bile hâlâ insan onayı olarak kalabiliyor mu? Yazarlar buna “devredilemez insan onayı” (I-HITL) diyor ve bunun yalnızca yazılımla sağlanamayacağını, ajanın erişemeyeceği güvenilir bir cihaz gerektirdiğini savunuyor.
Önerdikleri Countersign prototipi bu fikrin somut hâli. Sunucu bir onay isteği gönderiyor; kişi telefonunda işlemin metnini ve son geçerlilik süresini görüyor; biyometrik doğrulama, cihazın güvenli donanımında duran anahtarı açıp onayı imzalıyor; sunucu imzayı doğrulamadan işlemi kabul etmiyor. Kod MIT lisanslı ve GitHub’da açık; README kendisini bilinen doğrulama sınırlılıkları olan bir prototip olarak tanımlıyor.
Burada önemli ayrıntı şu: onay “evet” düğmesi değil, belirli bir işlemin imzası. Tutar, alıcı ya da süre değişirse eski onay geçersiz kalıyor.
Türkiye’deki geliştirici ve KOBİ için anlamı
Türkiye’de çoğu KOBİ’nin kripto cüzdanı yok; ama aynı desen ERP’lerde her gün kullanılıyor. Satın alma onayı e-postadaki bir bağlantıyla veriliyor, iskonto onayı mesajla geliyor, banka talimatı tek kullanımlık SMS koduyla tamamlanıyor. Bu kanallar, yalnızca insanın okuduğu varsayımıyla güvenli sayılıyordu.
Ajanlar bu varsayımı bozuyor. Gelen kutusunu özetleyen, teklif hazırlayan ya da tedarikçi yazışmasını takip eden bir asistanı MCP ya da başka bir entegrasyonla e-postaya bağladığınızda, onay kodları da artık ajanın okuyabildiği verinin içinde. Bana göre sorulması gereken soru “ajan bunu yapar mı?” değil, “ajan isterse yapabilir mi?” olmalı.
Bu, daha önce KOBİ’ler için yetki matrisi yazısında anlattığım görev ayrılığının yapay zekâ sürümü: ödemeyi hazırlayan ile onaylayan aynı kişi olmamalıysa, ödemeyi hazırlayan ajan ile onay kanalı da aynı erişim alanında olmamalı. WordPress’e MCP ile yazarken yayın onayını ayrı bir adım yapmamın gerekçesi de buydu.
Sınırlılıklar ve abartılan yanlar
- Deney bir kripto cüzdanında yapıldı. Araştırmacılar aynı zayıflığın başka onay tasarımlarında da bulunabileceğini söylüyor; CoinDesk bunun diğer ürünlerde gösterilmediğini not ediyor.
- Sonuçlar “en az bir kez” ölçütüyle veriliyor. Bir modelin limiti her denemede mi, nadiren mi aştığı haberlerden okunamıyor; model bazında dağılımı görmeden sıralama yapmak yanıltıcı olur.
- Bir modelin denemede kuralı çiğnememesi güvence değildir. Model sürümü, sistem talimatı ya da gelen e-postanın içeriği değişince davranış da değişebilir. OWASP’ın LLM uygulamaları için risk listesi de yetkilendirmenin modelin yargısına değil, alt sistemdeki denetime bağlanmasını öneriyor.
- Circle’ın yanıtı sınırlı kaldı: şirket sözcüsü CoinDesk’e, dokümanlarının kullanıcılara ajana e-posta hesabına sınırsız erişim vermemelerini açıkça söylediğini belirtti. Ama “dokümanda uyarı var” savunması, varsayılan akışın onay kodunu tam da ajan oturumunun e-postasına göndermesini değiştirmiyor.
- Countersign bir prototip. iPhone sürümü Apple geliştirici üyeliği istiyor ve her cihaz kaydı yönetici onayı gerektiriyor; bugün KOBİ’nin indirip kuracağı bir ürün değil.
Karşı görüş: “İyi model seçeriz, sorun çözülür”
Bu görüşün haklı bir yanı var: modeller arasında davranış farkı belirgin ve doğru model seçimi riski azaltıyor. Ama bence güvenliği modelin terbiyesine bırakmak, kasayı çalışanın dürüstlüğüne bırakmaya benziyor. İç kontrol, dürüst çalışan için de kurulur; çünkü hata, yanlış anlama ve dışarıdan gelen kandırma girişimi dürüstlükle önlenmez. Beş modelin sahte e-postaya kanması tam olarak bunu gösteriyor.
ERP/CRM/Laravel perspektifinden pratik değerlendirme
Laravel ile iş yazılımı geliştirenler için önerim, ajan eklemeden önce şu dört kuralı koda yazmak:
- Onay kanalı ajandan ayrı olsun. Ajanın bağlı olduğu e-posta kutusuna, Slack kanalına ya da SMS geçidine onay kodu gitmesin. Onay, ajanın kimliğiyle erişilemeyen ayrı bir uygulamadan ya da ayrı bir kullanıcı oturumundan gelsin.
- Onay işleme bağlansın. “Limit artışını onayla” yerine “satın alma asistanının limitini 5.000 TL yap, 5 dakika geçerli” metni imzalansın. Tutar değişince imza bozulsun.
- Kural değişikliği ile işlem ayrı yetki olsun. Ajan ödeme hazırlayabilir; kendi limitini, onay eşiğini ya da alıcı listesini değiştiremez. Bu yetki ajanın kullandığı API anahtarında hiç bulunmasın.
- Doğrulama sunucuda yapılsın. Ajan “kullanıcı onayladı” dediği için değil, sunucu geçerli bir imza gördüğü için işlem yürüsün.
Aşağıdaki PHP örneği bu fikrin çekirdeğini gösteriyor. Onay, işlemin özetine Ed25519 imzasıyla bağlanıyor; gizli anahtar yalnızca onaylayan kişinin cihazında. Örnek PHP 8.3 ve sodium eklentisiyle çalıştırıldı; dört denemenin çıktısı sırasıyla false, false, true, false oldu: değiştirilmiş tutar, süresi geçmiş onay ve aynı onayın ikinci kez kullanımı reddediliyor.
<?php
declare(strict_types=1);
// Onay, belirli bir işlemin özetine (hash) bağlanır.
function islemOzeti(array $islem): string
{
ksort($islem);
return hash('sha256', json_encode($islem, JSON_UNESCAPED_UNICODE | JSON_THROW_ON_ERROR));
}
final class OnayDogrulayici
{
/** @var array<string, true> Kullanılmış tek seferlik değerler */
private array $kullanilan = [];
public function __construct(private string $cihazAcikAnahtari) {}
public function dogrula(array $islem, string $imza, int $simdi): bool
{
if (($islem['son_gecerlilik'] ?? 0) < $simdi) {
return false; // süresi geçmiş onay
}
if (isset($this->kullanilan[$islem['nonce']])) {
return false; // aynı onay ikinci kez kullanılamaz
}
$gecerli = sodium_crypto_sign_verify_detached(
$imza,
islemOzeti($islem),
$this->cihazAcikAnahtari
);
if ($gecerli) {
$this->kullanilan[$islem['nonce']] = true;
}
return $gecerli;
}
}
// --- Deneme ---
// Gizli anahtar yalnızca onaylayan kişinin cihazında durur; ajan bu değişkene erişemez.
$cihaz = sodium_crypto_sign_keypair();
$dogrulayici = new OnayDogrulayici(sodium_crypto_sign_publickey($cihaz));
$simdi = 1_793_700_000;
$islem = [
'tur' => 'odeme_limiti_degisikligi',
'yeni_limit' => '5000.00',
'para_birimi' => 'TRY',
'talep_eden' => 'ajan:satinalma-asistani',
'nonce' => bin2hex(random_bytes(8)),
'son_gecerlilik' => $simdi + 300,
];
// İnsan, cihaz ekranında işlemin metnini görüp biyometriyle imzalar:
$imza = sodium_crypto_sign_detached(islemOzeti($islem), sodium_crypto_sign_secretkey($cihaz));
$degistirilmis = $islem;
$degistirilmis['yeni_limit'] = '50000.00';
var_dump($dogrulayici->dogrula($degistirilmis, $imza, $simdi)); // tutar değişti
var_dump($dogrulayici->dogrula($islem, $imza, $simdi + 600)); // süre doldu
var_dump($dogrulayici->dogrula($islem, $imza, $simdi)); // geçerli
var_dump($dogrulayici->dogrula($islem, $imza, $simdi)); // tekrar kullanımGerçek bir sistemde imza telefonun güvenli donanımında üretilir, açık anahtar cihaz kaydı sırasında doğrulanır ve kullanılmış tek seferlik değerler veritabanında tutulur. Örnek yalnızca sunucu tarafındaki kontrol mantığını gösteriyor.
| Onay yöntemi | Ajan okuyabiliyor mu? | İşleme bağlı mı? | Değerlendirme |
|---|---|---|---|
| Ajanın erişebildiği e-postaya kod | Evet | Hayır | Onay değil, formalite |
| Ayrı kullanıcının e-postasına bağlantı | Erişim ayrıysa hayır | Çoğunlukla hayır | Ara çözüm; bağlantıda işlem özeti olmalı |
| Telefonda işlem metni + biyometrik imza | Hayır | Evet | Makalenin önerdiği yön |
Bu tablo benim değerlendirmem; ilk satırdaki sonuç ise doğrudan deneyin bulgusu.
Sonuç
Yapay zekâ ajanlarının iş yazılımlarına girmesi hız kazandırıyor. Ama hız, onayın anlamını sessizce boşaltırsa kazanç değil, kayıt dışı yetki devri olur. Bence ölçüt basit: onay kodunu ajan okuyabiliyorsa o akışta insan yoktur.
Sizin sisteminizde onay kodları ve onay bağlantıları nereye gidiyor, ajanlarınız oraya erişebiliyor mu? Benzer bir süreç üzerinde çalışıyorsanız deneyimlerinizi paylaşın.
Kaynaklar
- Breckenridge, Vilardell, Wang, Zhang, Juels — “I-HITL: Inalienable Human-in-the-Loop”, arXiv, 26.10.2026 (v2: 27.10.2026)
- I-HITL/countersign — GitHub deposu (MIT lisanslı prototip)
- CoinDesk — “AI agents gave themselves permission to spend more crypto in a new test”, 01.11.2026
- PYMNTS — “Researchers Trick AI Agents Into Transferring User Funds”, 01.11.2026
- Circle Developer Docs — Agent wallets: custom policies (erişim 03.11.2026)
- OWASP GenAI Security Project — LLM06:2025 Excessive Agency
- PHP Manual — sodium_crypto_sign_verify_detached