Herkes için tek bir politika artık yeterli değil
Çoğu uygulama tek bir kullanıcı türü etrafında tasarlandı: bir arayüzde tıklayan, bir hesapta oturum açmış bir kişi. Erişim kontrolü de bu varsayımı izledi. Oturum geçerliyse istek geçer. Otomatik görünüyorsa CAPTCHA veya bir blok görünür.
Bu model artık bozuluyor. Bugün aynı uygulama insanlara, AI asistanlarıyla çalışan insanlara ve birinin adına hareket eden autonomous agent'lara hizmet veriyor. Bazı agent'lar müşterinin kendi entegrasyonlarıdır. Bazıları dokümantasyon çeken AI asistanlarıdır. Bazıları crawler'lardır. Birkaçı ürününüzü kötüye kullanmaya çalışır. Tek bir evet-hayır kuralı bunların hepsine iyi hizmet edemez.
AI agent yönlendirme ve erişim politikaları, bu tek kuralın yerine kasıtlı kararlar seti koyar: hangi actor'lar hangi deneyimi, hangi route'larda ve hangi koşullarda alır. Proof of Actor uygulamanıza bu kararları vermek için gereken kanıtı sağlar ve kararların kendisini sizin elinizde bırakır. Bu yaklaşımın tasarım ilkeleri için insanlar ve AI agent'lar için app politikaları tasarlama yazısını okuyun ve politikaların gerçek ürün workflow'larına nasıl uyduğunu görmek için SaaS apps kullanım senaryosu bölümüne bakın.
İyi bir agent politikası nasıl görünür
Faydalı bir politika nettir. Bir route veya workflow, bir actor class, gerekli evidence gücü ve yanıtı tanımlar. Örneğin:
- Read-only catalog route'ları: verified agent'lara izin verin ve yapılandırılmış bir yanıt sunun; declared agent'lara standart rate limit uygulayın.
- Hesap değiştiren işlemler: herkes için mevcut yeniden kimlik doğrulamayı koruyun; actor Unknown olduğunda ve işlem yüksek etkiliyse review ekleyin.
- Support submissions: ifşa edilmiş AI-assisted içeriği kabul edin ve yönlendirme için etiketleyin.
- Signup: mevcut kontrolleri koruyun; asla yalnızca inferred bir actor sonucuna göre karar vermeyin.
Bunların her biri, her agent'ı kötüye kullanım gibi görmeden ve hiçbir agent'a körü körüne güvenmeden actor'a yanıt verir. Agent-aware erişimin özü budur ve insanlar ve AI agent'lar için app politikaları tasarlama blog yazısı bu dengeyi route route daha fazla örnekle işler.
Beş yanıt
Proof of Actor's Route yeteneği, politikalarınızın seçebileceği beş yanıt etrafında tasarlanmıştır.
Allow
İsteğin normal şekilde devam etmesine izin verin. Public veya düşük riskli route'lardaki agent trafiğinin çoğu, basitçe allow edilmelidir.
Adapt
Deneyimi actor'a uyacak şekilde değiştirin. İnsan biçimli bir arayüz yerine verified bir agent'a yapılandırılmış bir API yanıtı veya bir sayfanın Markdown sürümünü sunun. AI agent'lara yapılandırılmış içerik sunma rehberi bu deseni kapsar.
Challenge
Daha güçlü bir şey isteyin: yeni bir giriş, ek bir credential, hesap sahibinden bir onay. Yanlış bir kararın maliyetinin yüksek olduğu route'larda challenge kullanın.
Review
İşlemi doğrudan tamamlama yerine bir kuyruğa alın ya da bir insanın kontrol etmesi için işaretleyin. Review, engellemenin meşru kullanıcıları zorlayacağı ama gözetimsiz tamamlamanın fazla riskli olduğu durumlarda faydalıdır.
Limit
Actor'a ve route'a göre ayarlanmış bir rate veya hacim limiti uygulayın, böylece otomatik çağrılar insanlar için tasarlanmış bir workflow'u aşırı yükleyemesin.
robots.txt neden bir erişim politikası değildir
Birçok ekip robots.txt ile başlar ve bu crawler'lar için makul bir ilk sinyaldir. Ancak bu, agent'lar için bir erişim politikası değildir. Crawler operatörleri farklı user-agent'lar için farklı davranışı belgeler: Anthropic, bot'larının robots.txt yönergelerine uyduğunu belirtir (Anthropic crawler documentation), OpenAI ise ChatGPT'ye bir soru sorulduğunda çalışan ChatGPT-User için, eylem kullanıcı tarafından başlatıldığı için robots.txt kurallarının uygulanmayabileceğini not eder (OpenAI crawler documentation). robots.txt ayrıca API'ler, MCP araçları veya oturum açılmış workflow'lar hakkında hiçbir şey söylemez.
Bir erişim politikası isteğin ele alındığı yerde çalışmalı, RFC 9421 altında doğrulanmış bir signature gibi evidence okumalı ve her route için bir yanıt seçmelidir. MCP server'lar için MCP authorization specification, client'ların HTTP üzerinden access token elde etme şeklini tanımlar; actor politikaları bunun üzerine bağlam ekler, onun yerini almaz.
Proof of Actor politikalarınızı nasıl besler
Entegrasyonunuzun değerlendirdiği her istek, politikanızın okuyabileceği dört parçalı bir actor sonucu üretir:
- Class: Human, Human + AI, Agent veya Unknown.
- Basis: verified, declared, inferred veya unknown, böylece politikanız doğrulanmış bir signature ile kendi adını beyan eden bir client adını farklı ele alabilir.
- Evidence summary: sonucun neye dayandığını okunabilir biçimde açıklar, logging ve review için kullanışlıdır.
- Context: sonucu hangi entegrasyonun ve hangi route'un ürettiği.
Basis açık olduğu için politikalarınız hassas olabilir. "Agent'lara izin ver" ifadesi, "read route'larda verified agent'lara izin ver, declared agent'lara rate-limit uygula, diğer her şey için Unknown fallback'ini kullan" haline gelir. İstekten karara kadar tam akış Nasıl Çalışır sayfasında anlatılır.
Fallback'ler politikanın parçasıdır
Bir politika, evidence eksik olduğunda nasıl davrandığı kadar iyidir. Proof of Actor bu durumları gizlemek yerine açık hale getirir.
- Unknown: evidence bir sonuca destek vermedi. Politikanız, her route'ta Unknown'un ne anlama geldiğini söyler. Asla Human'a çevrilmez ve varsayılan olarak kötü niyetli sayılmaz.
- Timeout: sonuç zamanında gelmedi. Entegrasyonunuz, o route için seçtiğiniz fallback'i uygular.
- Missing signals: bir collector çalışmadı veya bir header eksikti. Sonuç bunu yansıtır ve politikanız buna göre davranır.
Her route için fail open veya fail closed kullanıp kullanmayacağınızı seçersiniz. Fail open, isteğin Proof of Actor olmadan nasıl davranıyorsa öyle devam etmesi demektir; fail closed ise mevcut daha güçlü kontrolünüzün uygulanması demektir. Düşük riskli route'lar genellikle fail open olur. Hassas işlemler genellikle fail closed olur. Bunu genel değil, risk katmanına göre belirlersiniz.
Identity, credential ve authorization'ı ayrı tutun
Agent erişim politikaları üç ayrı katmanın üzerine oturur ve bunları birbirinden ayırmak en zararlı hataları önler.
- Identity evidence hangi actor'ın çağrı yaptığını ve bunu neyin kanıtladığını yanıtlar. Bunu Proof of Actor sağlar.
- Credentials hangi hesabın sorumlu olduğunu yanıtlar. Bunu oturumunuz, token'ınız veya API key'iniz sağlar.
- Authorization bu çağrıyı yapanın bu işlemi yapıp yapamayacağını yanıtlar. Bunu izin modeliniz sağlar.
Verified bir agent identity'si, agent'ın yetkili olduğu, bir kişinin ona yetki devrettiği veya işlemin güvenli olduğu anlamına gelmez. Actor sonuçlarını yönlendirme ve bağlam eklemek için kullanın. İzin vermek için authorization modelinizi kullanın. Detection & Limitations sayfası her evidence türünün tam olarak neyi ortaya koyabileceğini açıklar.
Hiçbir şeyi kırmadan devreye alın
Agent erişim politikalarını tanıtmanın en güvenli yolu aşamalı ilerlemektir.
- Observe. Proof of Actor'ı observation mode içinde kurun. Kullanıcılar için hiçbir şey değişmez; sonuçlar kaydedilir.
- Understand. Hangi actor'ların hangi route'ları kullandığını, her birindeki unknown oranını ve zaten bildiklerinizle çelişen sonuçları inceleyin.
- Preview. Bir politikayı preview olarak çalıştırın ve enforce etmeden ne yapacağını kaydedin.
- Enforce narrowly. Politikayı evidence'in açık biçimde desteklediği tek bir route'ta etkinleştirin. Sonuçları izleyin.
- Expand. Güven arttıkça daha fazla route'a genişletin.
Actor-aware politikaları güvenli biçimde devreye alma rehberi her aşamayı anlatır ve agent'ları engellemeden hassas işlemleri koruma yüksek riskli route'ları kapsar.
Ekibiniz ne elde eder
Proof of Actor ile ekibiniz tek bir entegrasyon ve üç yetenek kazanır. Detect actor sinyallerini toplar ve verified assertions'ları inferences'tan ayırır. Understand actor analytics, trendler ve her sonucun arkasındaki evidence'i gösterir, Unknown görünür kalır. Route bu sayfada anlatılan politikaları yazmanıza ve seçtiğiniz yerde uygulamanıza izin verir. Private beta sırasında routing politikaları her founding team ile birlikte tasarlanır ve kendi uygulama kodunuzda çalışır, böylece tam kontrol sizde kalır.
Kaçınılması gereken yaygın politika hataları
İlk kez agent erişimi tasarlayan ekipler birkaç hatayı tekrar etme eğilimindedir. Bunlardan kaçınmak haftalarca yeniden çalışma tasarrufu sağlar.
- Varsayılan olarak her agent'ı engellemek. Meşru agent'lar bu durumda sizi aşarak yollar bulur, çoğu zaman insanlar için kurduğunuz arayüzü tarayarak; bu yol, yapılandırılmış bir path'e göre daha zordur korunur.
- Declared bir ada güvenmek. Sadece kendini adlandıran bir client bir iddia sunmuştur, proof değil. Ona, doğrulanmamış bir çağırana vereceğiniz muameleyi verin.
- Her yerde tek fallback kullanmak. Public bir pricing page'deki Unknown ile bir password change'deki Unknown aynı durum değildir. Her route'un kendi yanıtına ihtiyacı vardır.
- İnsanlar hakkında inference üzerinden karar vermek. Actor sonuçları, bir kişi hakkında hüküm değil, yönlendirme için bağlamdır. Sonuç doğuran kararları kendi kontrollerinizde ve review'da tutun.
- Observation'ı atlamak. İlk günden enforce etmek, false positive'leri müşteri şikayetleriyle keşfetmeniz demektir. Önce observe edin, sonra evidence net olduğunda enforce edin.
Her enforcement adımından önce security, product ve support liderlerinizle yapılacak kısa bir politika review'ü bunların çoğunu erkenden yakalar.
Founding developer program ile başlayın
Proof of Actor private beta'dadır. Seçilmiş founding development ekipleri, üzerinde anlaşılmış kullanım limitleri dahilinde 12 aya kadar ücretsiz erişim ve ilk politikalarınızı tasarlarken mühendislerimizden doğrudan destek alabilir.
Uygulamanızın AI agent'lara nasıl davranması gerektiğine karar veriyorsanız, erken erişim için başvurun. Hangi route'ların en önemli olduğunu ve hangi kararları vermek istediğinizi bize anlatın; size uygun politikaları kurmanıza yardımcı olalım. Bunun APIs ve MCP server'lar üzerindeki uygulamasını da görebilirsiniz.
Kaynaklar
- Does Anthropic crawl data from the web, and how can site owners block the crawler?, Anthropic.
- Overview of OpenAI crawlers, OpenAI.
- RFC 9421: HTTP Message Signatures, IETF, February 2024.
- MCP authorization, modelcontextprotocol.io.