Mimari ve çalışma modeli
AI ajanı bir araç çağırdığında model çıktısı yetki kararı değildir. Kimlik, token audience, scope, tenant, kaynak sahibi ve eylem parametreleri araç katmanında doğrulanmalıdır. MCP istemcisi ve sunucusu bağlam taşır; uzak MCP sunucusu bir OAuth resource server gibi erişim tokenını doğrular. Yerel stdio sunucusunda güven sınırı, süreci başlatan kullanıcı ve verilen işletim sistemi izinleridir.
Araç açıklaması modele niyet sinyali verir fakat güvenlik kontrolü değildir. Okuma, yazma, silme ve dış iletişim eylemleri ayrı araç/scope olarak tasarlanmalı; geniş `admin` yetkisi yerine kaynak ve eylem bazlı izin kullanılmalıdır. Dolaylı prompt injection, güvenilmeyen belge içeriğinin ajanı araç çağırmaya ikna etmesidir; veri kökeni ile talimat kökeni ayrılmadan model onayı güvenilir değildir.
Yüksek etkili eylemlerde plan ve icra ayrılabilir: ajan değişiklik taslağı üretir, politika motoru parametreyi denetler, gerekiyorsa insan onayı alınır ve idempotency key ile tek kez yürütülür. Audit kaydı kullanıcı, ajan sürümü, araç, parametre özeti, politika kararı, onay ve sonuç kimliklerini bağlamalı; sırları ve ham hassas içeriği loglamamalıdır.
- 1Kullanıcı niyeti ve veri kökeni
- 2Modelin yapılandırılmış araç önerisi
- 3Sunucu kimlik/scope/parametre politikası
- 4Onay, idempotent icra ve audit
Tasarım parametreleri
- Kimlik ve audience
- Token'ın hedef MCP sunucusu için üretildiğini, tenant ve kullanıcı bağını doğrulayın.
- Scope ayrımı
- Read, create, update, delete ve external-send eylemlerini ayrı izinlere bölün.
- Parametre politikası
- Hedef kaynak, alıcı, miktar, zaman aralığı ve veri sınıfı için sunucu tarafı kural uygulayın.
- Onay ve tekrar
- Yüksek etkili eylemde insan onayı, süreli karar ve idempotency key kullanın.
Hesap ve uygulama örneği
Destek ajanı ayda 40.000 ticket okuyor fakat günde en çok 50 yanıt göndermeliyse `tickets.read` ve `tickets.reply` scope'larını ayırın. Gönderme aracında tenant, ticket sahipliği, alıcı domaini ve 50/gün sınırı sunucuda doğrulanır. Prompt'un `tüm müşterilere gönder` demesi scope ve kota kontrolünü aşamaz.
Bir araç çağrısının toplam riski olasılık × etki olarak puanlanıyorsa düşük etkili okuma 0,1×2=0,2 ile otomatik; dış para transferi 0,2×10=2,0 ile insan onaylı olabilir. Bu eşikler iş politikasına örnektir, model güven skoru veya mutlak güvenlik garantisi değildir; yanlış pozitif/negatiflerle kalibre edilir.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
# Sunucu tarafı sözde politika
assert token.aud == MCP_RESOURCE
assert token.tenant_id == resource.tenant_id
require_scope('tickets.reply')
assert request.ticket_id in authorized_ticket_ids(user)
assert recipient_domain in tenant.allowed_domains
assert daily_count(user, 'reply') < 50
result = execute_once(idempotency_key, request)
audit(user_id, agent_version, tool_version, policy_decision, result.id)Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Ajan beklenmeyen aracı çağırıyor | Araç açıklaması çakışıyor, güvenilmeyen içerik talimat gibi işleniyor veya izinler geniş olabilir. | Prompt/veri kökenini, seçilen araç sürümünü ve server-side policy kararını audit ID ile izleyin. |
| 401/403 yalnız bazı kullanıcılarda | Audience, scope, tenant veya kaynak sahipliği farklı olabilir. | Token değerini loglamadan issuer/audience/scope ve policy reason code'u karşılaştırın. |
| Aynı eylem iki kez gerçekleşiyor | Retry ile idempotency bağı kurulmamış olabilir. | İstemci request ID, sunucu idempotency key ve sonuç kaydını eşleyin. |
Kabul ve doğrulama kontrolleri
- Her araç için veri erişimi ve yan etki sınıfını kaydedin.
- Read/write/delete/send scope'larını bağımsız test edin.
- Yanlış audience ve tenant tokenlarının reddedildiğini doğrulayın.
- Güvenilmeyen belgeyle dolaylı prompt injection testi çalıştırın.
- Yüksek etkili eylemde onay süresi ve idempotency testini yapın.
- Audit kaydında kimlik, politika ve sonuç bağını; sırların maskelendiğini doğrulayın.
İlgili kavramlar
Kimlik doğrulama ve oturum
Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.
En az yetki ve görev ayrımı
En az yetki, bir görevin gerektirdiği izinlerin belirli kaynak ve süreyle sınırlandırılmasıdır. Herkese aynı yönetici rolünü vermek, erişim incelemesini ve olay araştırmasını zorlaştırır. Günlük kullanıcı hesabı ile ayrıcalıklı hesabı ayırın; servis hesaplarının etkileşimli kullanımını ve gereksiz ağ erişimini kısıtlayın. Yetki matrisi, kimliğin kaynağa hangi işlemle eriştiğini göstermelidir. Bir izin kaldırıldığında uygulamanın çalışmayı sürdürmesi de test kapsamına girer: gereksiz yetkiler bazen yalnız kontrollü azaltma sırasında ortaya çıkar.
Güven sınırı ve hata alanı
Güven sınırı, aynı erişim kararlarını paylaşan bileşenleri ayırır; hata alanı ise tek bir olayın birlikte etkileyebileceği kaynakları tanımlar. İki VLAN kullanmak, aralarında serbest yönlendirme varsa güçlü bir güven sınırı kurmaz. İki yedek aynı yönetici hesabıyla silinebiliyorsa da farklı klasörlerde bulunmaları ayrı hata alanı sağlamaz. Tasarımda fiziksel yer, kimlik sağlayıcı, yönetim hesabı, ağ yolu ve enerji kaynağını ayrı ayrı değerlendirin. Bir bileşen kaybedildiğinde hangi erişimlerin ve kurtarma seçeneklerinin ayakta kalacağını sınayın.
Dosya izinleri ve servis kimliği
Dosya erişimi kullanıcı/grup, izin bitleri, ACL ve güvenlik politikalarının birleşimine bağlıdır. Bir uygulamanın root olarak çalışması izin sorununu gizleyebilir; üretim için gerekçeli ve sınırlı servis kimliği tercih edilir. Dizin üzerinde arama/geçiş izni ile dosya okuma izni farklıdır. Paylaşım katmanında verilen izin, dosya sistemindeki kısıtı her zaman aşmaz. Hata araştırmasında uygulamanın gerçekten hangi kullanıcıyla çalıştığını, dizin zincirini ve ACL’leri inceleyin. İzinleri topluca açmak yerine gereken erişimi dar kapsamda test edin.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.
Politikanın yaşam döngüsü
Bir politika yalnız etkinleştirildiği anda değil, kapsamı değiştikçe de yönetilmelidir. Taslak, gözlem, pilot, uygulama ve periyodik inceleme aşamalarını ayırın. Her istisnanın sahibi, gerekçesi, kapsamı ve sona erme tarihi olmalıdır. Test verileri gerçek kullanıcı davranışını temsil etmezse başarılı pilot üretimde yanlış engellemelere dönüşebilir. Önce kimin ve hangi uygulamanın etkilenebileceğini belirleyin; sonra ölçülebilir kabul koşullarıyla devreye alın. Geri alma yolu yalnız düğme konumunu değil, değişikliğin kim tarafından ve hangi koşulda geri alınacağını da tanımlamalıdır.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.