Hassas eylemleri meşru agent'ları engellemeden nasıl korursunuz

Neden agent'ları hassas eylemlerden doğrudan engellemeyelim?

Uygulamanızdaki bazı eylemler diğerlerinden daha önemlidir. Bir parolayı değiştirmek, bir ekip üyesi eklemek, veri dışa aktarmak, bir projeyi silmek, bir siparişi onaylamak: bunlardan herhangi biri doğru yetki olmadan gerçekleşirse, zarar gerçektir.

Aynı zamanda, uygulamanızdaki meşru işlerin giderek daha fazlası otomasyon tarafından yapılır. Bir kullanıcı bir asistandan ayarlarını güncellemesini ister. Bir iş ortağı entegrasyonu belirli bir takvimle kayıt oluşturur. Bir dahili agent destek talepleri açar. Her otomatik istemciyi hassas yollardan engellemek bu işi bozar ve insanları yeniden manuel çalışmaya ya da güvenliği daha zor olan geçici çözümlere iter.

Cevap "agent'ları engelle" ya da "agent'lara güven" değildir. Cevap, eylemin riski, isteğin arkasındaki yetki ve actor hakkındaki kanıtın ayrı roller üstlendiği bir modeldir. Bu kılavuz bu modeli kurar. Bunun arkasındaki daha geniş yaklaşım için uygulama düzeyi politikaları insanlar ve AI agent'ları için tasarlama bölümüne bakın.

Adım 1: Yollarınızı riske göre katmanlara ayırın

İstemcileri değil, eylemleri sınıflandırarak başlayın. Basit bir üç katmanlı şema çoğu uygulama için işe yarar:

Katmanı, kod incelemesinde görünür olacak şekilde yol yapılandırmasına yazın:

type Tier = "low" | "medium" | "high";

export const routeTier: Record<string, Tier> = {
  "GET /projects": "low",
  "POST /projects": "medium",
  "POST /projects/:id/members": "medium",
  "POST /account/password": "high",
  "POST /exports": "high",
  "DELETE /projects/:id": "high",
};

Katmanlar yavaş değişir ve üzerinde düşünmesi kolaydır. Bu kılavuzdaki diğer her şey onların üzerine kurulur.

Adım 2: Kimlik, kimlik bilgileri ve yetkilendirme nasıl ayrılır?

Üç soru sıklıkla birbirine karışır:

1. Kim veya ne eylemde bulunuyor? Bu, actor kanıtıdır: etkileşimde bulunan bir kişi, AI desteği alan bir kişi, bir agent veya Unknown, verified ya da declared gibi bir dayanakla.
2. Hangi kimlik bilgisi sunuldu? Bir session cookie, bir API key, bir OAuth access token.
3. Bu kimlik bilgisi, bu kaynağa karşı bu eylemi yapmaya yetkili mi? Bu, yetkilendirmedir.

Doğrulanmış bir agent imzası (RFC 9421) ilk soruyu iyi yanıtlar. Üçüncü soruya dair hiçbir şey söylemez, bu nokta imzalı AI agent isteklerinin neyi kanıtladığı ve neyi kanıtlamadığı bölümünde ayrıntılı olarak ele alınır. Doğru scope'a sahip bir OAuth token üçüncü soruyu yanıtlar. İlk soru hakkında ise çok az şey söyler. Yüksek katmanlı bir eylem için kararınızın her zaman üçüncü soruya iyi bir yanıtı olmalıdır ve ilk soruyu, ne kadar ek güvence isteyeceğinizi seçmek için kullanır.

interface Context {
  actor: { actor: "human" | "human_ai" | "agent" | "unknown"; basis: "verified" | "declared" | "inferred" | "unknown" };
  credential: { type: "session" | "oauth" | "api_key"; scopes: string[]; subject: string };
}

function authorized(ctx: Context, action: string, resourceOwner: string): boolean {
  return ctx.credential.subject === resourceOwner && ctx.credential.scopes.includes(action);
}

Olumlu bir actor sonucu nedeniyle yetkilendirme asla gevşetilmez. Actor bağlamı yalnızca ek gereksinimler getirir ya da eşit derecede güvenli yollar arasında seçim yaptırır.

Adım 3: İnsanlar adına hareket eden agent'lar için devredilmiş yetki kullanın

Bir agent bir kullanıcı adına hareket ettiğinde, kullanıcının session'ını yeniden kullanmasına izin vermek yerine, sınırlı yetkiye sahip kendi kimlik bilgisini verin. OAuth 2.0 bunun standart aracıdır: kullanıcı belirli bir istemci için belirli scope'ları onaylar ve token bu istemciyi kaydeder. RFC 9700, OAuth 2.0 Security Best Current Practice, bunun güvenli şekilde nasıl uygulanacağını açıklar. MCP server'lar da aynı modeli izler: MCP authorization specification, korumalı bir MCP server'ı OAuth 2.1 resource server olarak ele alır. MCP server'nızı kim çağırıyor? yazımız bunu araç çağrılarına uygular.

Bu, hassas eylemler için tam olarak ihtiyacınız olan şeyi üretir:

• Token size hangi istemcinin ve kimin adına hareket ettiğini söyler.
• Scope'lar ne yapabileceğini sınırlar. calendar:write sahibi bir planlama agent'ı parolayı değiştiremez.
• Kullanıcı, kendi kimlik bilgilerini değiştirmeden yetkiyi iptal edebilir ve OAuth 2.0 Token Revocation (RFC 7009), bir istemcinin yetkilendirme sunucusuna token'ın artık geçerli olmaması gerektiğini nasıl bildireceğini tanımlar.
• Denetim kayıtları, eylemi kullanıcının değil agent'ın yaptığını gösterir.

Uygulamanız henüz devredilmiş kimlik bilgilerini desteklemiyorsa, agent'ların en sık ihtiyaç duyduğu eylemler için bunu önceliklendirin. Otomatik erişim için tek başına en etkili kontroldür.

Adım 4: Ne zaman step-up kontrolü istemelisiniz?

Step-up, hassas bir eylem anında ek güvence istemek demektir. OAuth ile korunan API'ler için RFC 9470, resource server'ın istemciye mevcut token'ın kimlik doğrulamasının yeterince güçlü ya da yeterince güncel olmadığını nasıl söyleyeceğini tanımlar. Doğru step-up, kimin eylemde bulunduğuna bağlıdır:

• Etkileşimde bulunan kişi (Human, Human + AI): yeniden kimlik doğrulama (NIST SP 800-63B içindeki yeniden kimlik doğrulama gereksinimlerine bakın), WebAuthn üzerine kurulu bir passkey istemi veya tek kullanımlık kod.
• Devredilmiş kimlik bilgisine sahip agent: kullanıcı tarafından açıkça verilmiş, yüksek katmanlı eyleme ayrılmış bir scope ya da kullanıcıya kanal dışı gönderilen bir onay.
• Unknown: yolun mevcut güçlü kontrolü, değişmeden.

type Requirement = "none" | "reauth" | "explicit_scope" | "user_confirmation" | "review";

function stepUp(tier: Tier, ctx: Context): Requirement {
  if (tier !== "high") return "none";
  const { actor } = ctx.actor;
  if (actor === "human" || actor === "human_ai") return "reauth";
  if (actor === "agent" && ctx.credential.type === "oauth") return "explicit_scope";
  if (actor === "agent") return "user_confirmation";
  return "reauth";
}

Dikkat edin, Human sonucu step-up'ı atlamaz. Etkileşimde bulunan bir kişiye uygun step-up'ı seçer. Inferred sonuçlar yanlış olabilir, bu nedenle kontrolün şeklini değiştirmeli, onu kaldırmamalıdır.

Adım 5: Karar gerektiren yerlerde insan incelemesine yönlendirin

Bazı eylemler nadirdir, yüksek etkilidir ve güvenli şekilde otomatikleştirilmesi zordur: müşteri verilerinin toplu dışa aktarımı, kayıp kimlik bilgileri sonrası hesap kurtarma veya bir organizasyonu silme. Bu durumlarda, bir inceleme kuyruğu çoğu zaman herhangi bir otomatik kuraldan daha iyidir.

Actor bağlamı, inceleyene kanıtı vererek incelemeyi daha hızlı ve daha adil hale getirir: sınıf, dayanak, kullanılan kimlik bilgisi, benzer isteklerin geçmişi. İnceleyen karar verir. Sınıflandırma bilgi sağlar.

function shouldReview(route: string, ctx: Context): boolean {
  const reviewRoutes = new Set(["POST /exports", "POST /account/recover"]);
  if (!reviewRoutes.has(route)) return false;
  return !(ctx.credential.type === "oauth" && ctx.credential.scopes.includes("export:bulk"));
}

Adım 6: Başarısızlık davranışını katman başına seçin

Actor değerlendirmesi zaman aşımına uğrayabilir veya kanıttan yoksun kalabilir. Ne olacağını önceden belirleyin.

• Düşük katman: fail open. İstek normal şekilde devam eder.
• Orta katman: normal yetkilendirme yerinde kalacak şekilde fail open.
• Yüksek katman: mevcut güçlü kontrole fail closed. Eksik actor kanıtı korumayı asla zayıflatmaz ve normal kontrollerinizden geçecek bir isteği asla engellemez.

Temel özellik simetridir. Actor değerlendirmesindeki bir hata, eylemi actor bağlamını eklemeden önce olduğu kadar güvenli ve tam olarak o kadar kullanılabilir bırakmalıdır.

Adım 7: Inferred sonuçlara dayanarak insanlar hakkında sonuç doğuran kararlar vermeyin

Inferred bir sınıflandırma, bir kişi hakkında bir olgu değil, bir etkileşime dair kanıttır. Bir iş başvurusunu, kredi kararını, sınav sonucunu, konutu veya temel bir hizmete erişimi, bir oturum otomatik ya da AI destekli görünüyordu diye reddetmeyin. Bu akışlarda, actor bağlamını insan incelemesi veya alternatif bir doğrulama yolu gibi bir süreç seçmek için kullanın ve kişinin bunu tamamlayabildiğinden emin olun.

Bu hem bir adalet ilkesi hem de pratik bir ilkedir. Inferred sonuçlarda yanlış pozitifler vardır ve bu akışlardaki yanlış pozitifin maliyeti, yanlış bir şey yapmamış bir kişiye düşer.

Adım 8: Önce gözlem ile yayına alın

Bunlardan herhangi biri gerçek istekleri etkilemeden önce, gözlem ve önizleme modunda çalıştırın:

1. Katmanı, actor sınıfını, dayanağı, kimlik bilgisi türünü ve politikanızın gerektireceği step-up'ı kaydedin.
2. Yüksek katmanlı isteklerden örnekleri sınıfa göre inceleyin. Meşru agent'lar devredilmiş kimlik bilgileri mi kullanıyor, yoksa kullanıcı session'larını mı yeniden kullanıyor?
3. Bulduğunuz boşlukları, çoğu zaman kapsamı sınırlandırılmış kimlik bilgileri sunarak, uygulamaya koymadan önce giderin.
4. Tek bir yolun küçük bir bölümünde enforce edin, tamamlanma oranlarını ölçün, sonra genişletin.

Adım 9: "Kim ve kimin adına" sorusunu yanıtlayan bir denetim izi tutun

Her yüksek katmanlı eylem için, daha sonra ne olduğunu yeniden oluşturabilecek kadar veri kaydedin:

• isteğin anındaki actor sınıfı ve dayanak,
• kimlik bilgisi türü, verildiği istemci ve temsil ettiği özne (OAuth 2.0 Token Exchange, RFC 8693, tam olarak bu tür bir "onun adına hareket eden" ilişkiyi kaydetmek için bir act claim tanımlar),
• eylemi yetkilendiren scope'lar,
• uygulanan step-up veya inceleme gereksinimi ve sonucu.

audit.write({
  action: "project.export",
  actor: ctx.actor,
  client: ctx.credential.type === "oauth" ? clientIdFromToken(req) : undefined,
  subject: ctx.credential.subject,
  scopes: ctx.credential.scopes,
  requirement,
  outcome: "approved",
  at: new Date().toISOString(),
});

Bu iz ile "bu projeyi bir kişi mi yoksa bir yardımcı mı sildi ve bunu kim onayladı" gibi bir sorunun net bir cevabı olur. Bu, olay müdahalesini hızlandırır ve kullanıcıların uygulamanızdaki otomatik yardımın hesap verebilir olduğuna güvenmesini sağlar.

Çalışılmış bir örnek

Bir proje yönetimi uygulaması, bir asistanın kullanıcılar için görev son tarihlerini güncellediğini ve ara sıra tüm projeleri dışa aktarmaya çalıştığını görür.

• Bir görevi güncellemek orta katmandır. Asistan tasks:write içeren bir OAuth token kullanır. Yetkilendirilmiş, step-up yok. İzin verilir.
• Bir projeyi dışa aktarmak yüksek katmandır. Asistanın token'ında export:bulk yoktur. Uygulama kullanıcıya bir onay isteği gönderir. Kullanıcı onay verir ve uygulama bu istemci için scope'u tanımlar.
• Unknown bir istemci, yeniden kullanılan bir session cookie ile aynı dışa aktarma işlemini dener. Mevcut yeniden kimlik doğrulama istemi, daha önce olduğu gibi uygulanır.

Hiç kimse agent olduğu için engellenmedi. Her yüksek etkili eylem açık yetki taşıdı.

Proof of Actor burada nereye oturur?

Proof of Actor, bu modelin actor tarafını sağlar: kim veya ne eylemde bulunuyor ve hangi dayanakla. Kimlik doğrulama, yetkilendirme ve nihai karar uygulamanızda kalır. Actor'ü Detect edin, her sınıfın hassas yollarınızı nasıl kullandığını Understand edin ve her isteği doğru güvence düzeyine Route edin.

Bunu ekibimizle uygulamanız için tasarlamak üzere erken erişim için başvurun. Daha ayrıntılı SaaS senaryoları için SaaS Apps & Websites bölümüne bakın.

Kaynaklar

• RFC 6749: The OAuth 2.0 Authorization Framework: istemciler için kapsamlı, devredilmiş kimlik bilgileri
• RFC 9700: Best Current Practice for OAuth 2.0 Security: OAuth dağıtımları için güncel güvenlik rehberi
• RFC 7009: OAuth 2.0 Token Revocation: kullanıcının kimlik bilgilerini değiştirmeden bir yetkiyi iptal etme
• RFC 9470: OAuth 2.0 Step Up Authentication Challenge Protocol: daha güçlü veya daha güncel kimlik doğrulamasının gerektiğini bildirme
• RFC 8693: OAuth 2.0 Token Exchange: devretme için act (actor) claim'i
• MCP specification 2026-07-28: Authorization: OAuth 2.1 resource server olarak MCP server'lar
• NIST SP 800-63B: Authentication and Authenticator Management: yeniden kimlik doğrulama rehberi
• W3C Web Authentication (WebAuthn) Level 3: passkey istemlerinin arkasındaki standart
• RFC 9421: HTTP Message Signatures: doğrulanmış bir agent imzasının neyi kurduğu