Monofor ile yapay zekâ güvenliği: Gateway'ler, korumalar ve makine kimlik bilgileri
Neler değişti
Her içerik güncellemesi sürümlenir. Bir sürümü seçerek öncekiyle karşılaştırın.
Sürüm 8 → 9
GüncellemeDört yeni ders MCASP sınavıyla aradaki boşluğu kapatıyor: uygulamada onaylayanlar ve kaybolan kimlik bilgileri, Gateway'leri işletmek (zaman sınırları, akış, token audience), işletimde AI flows ve makine kimliğini seçip kapsamını belirlemek. Her modül sınavına iki yeni soru eklendi. Yeni derslere diyagramlar eklendi.
4 ders güncellendisüre
İçerik güncellemesi. Kayıtlı öğrenciler bilgilendirildi.
Süre 66 dakikadan 67 dakikaya değişti.
Bir onay politikası kâğıt üzerinde basit görünür. Günlük işte tutup tutmayacağını üç soru belirler: gerçekte kime soruluyor, bunu nasıl öğreniyorlar ve bir kimlik bilgisinin sırrı kaybolduğunda ne yapıyorsunuz. Bu ders her birini tek bir örnek ajan üzerinden anlatır.
### Örnek: iade başlatan bir ajan
`refund-bot` ajanı iade başlatabiliyor. Güvenlik lideri, adı belli iki finans yöneticisinin birlikte onay vermesini ve her kararı gerekçelendirmesini istiyor. Ajanı ve `Approvers` sekmesini açın:
| Ayar | Değer | Neden |
| --- | --- | --- |
| Mod | `Use the default` yerine `Choose for this agent` | Kiracı varsayılanı önce yöneticilere, sonra yönetişim sahiplerine sorar. Bu ajan için fazla geniştir |
| Adım kutusu | `These people`, iki yönetici | Ajanı o an kim yönetiyorsa o değil, adı belli kişiler |
| `How many must approve` | `Everybody asked` | `Any one` ile tek bir yönetici tek başına karar verebilirdi |
| `Approvers must write why` | Açık | Gerekçesiz karar kabul edilmez |
| `Also tell them by` | `Push to the authenticator app` | Varsayılan budur. `E-mail with approve and deny links` de işaretlenebilir |
`Also tell them by` altında ne işaretlerseniz işaretleyin, Management içindeki konsol zili her zaman kullanılır. Yani varsayılanlarında bırakılan bir adım onaylayanlara iki yoldan ulaşır: zil ve Authenticator uygulamasına push. E-posta ise bilerek eklediğiniz kanaldır.
Her değişiklikten sonra `Right now a request would go to` panelini okuyun. Panel, politikanın o anda bulduğu kişileri listeler.
### Kim onaylayan sayılır
Yalnızca **etkin** kişiler sayılır ve ajanın adına çalıştığı kişi listeden çıkarılır. Bu yüzden bir ajanın kâğıt üzerinde sahibi olabilir ama soracak kimsesi olmayabilir.
Örnek: bir ajan `Detected` durumundan terfi ettirildi ve tek bir yönetişim sahibi atandı. Hiç Direct Manager eklenmedi. Sahip şirketten ayrıldı ve hesabı devre dışı bırakıldı. Bu ajan için gelen bir sonraki istek bekletilmez. Hemen reddedilir, çünkü kimsenin yanıtlayamayacağı bir istek, çağıran dakikalar kaybettikten sonra aynı sonuçla zaten sona erecekti.
İki alışkanlık bunu önler: `Add a fallback: who to ask when nobody above is found` ile ikinci bir adım ekleyin ve insanlar görev değiştirdiğinde paneli kontrol edin.
### Bir istek ne kadar bekler
Adımdaki `A request waits for` varsayılan olarak 10 dakikadır. İstek açan bir API çağıranı kendi `ExpirationSeconds` değerini gönderebilir. Pozitif bir değer politikanın önüne geçer ve en fazla 86400 saniye, yani bir gün olabilir. Gönderilmezse politika karar verir.
### Kaybolan kimlik bilgisi sırrı
Bir ajan kimlik bilgisinin sırrı, oluşturulduğu anda bir kez gösterilir. Yeniden görüntülenemez, yönetici için bile. Geliştirici onu saklamadıysa:
1. Ajanın `Credentials` sekmesini açın ve kimlik bilgisini `Revoke` ile iptal edin.
2. `Create Credential` ile yenisini oluşturun ve yeni sırrı güvenli biçimde teslim edin.
Önce iptal edin, çünkü eski sırrın bir kopyasının nerede olabileceğini kimse bilmez. Bir kimlik bilgisini iptal etmenin, daha önce verilmiş token'ları sonlandırmadığını unutmayın. Kötüye kullanımdan şüpheleniyorsanız `Kill Switch` kullanın.
::diagram ais-lost-credential
### Çağrılara değil, token'lara bütçe
`Budget & Quotas` altındaki `Token issuances / hour`, ajanın ne sıklıkla token alabileceğini sınırlar. İstek sınırları ise çağrıları sınırlar. Token'ı reddedilen bir ajan, `Audits` sekmesine gerekçesiyle birlikte `AGENT_TOKEN_DENIED` yazar. Bir sınırı yükseltmeden önce o gerekçeyi okuyun.
Trafik Gateway'lerden geçmeye başlayınca sorular değişir. İnsanlar artık "buna izin var mı" diye değil, "neden böyle davranıyor" diye sorar. Bu soruların çoğunu beş davranış açıklar.
| İnsanların fark ettiği | Neden | Nerede görürsünüz |
| --- | --- | --- |
| Uzun işler yaklaşık beş dakika sonra başarısız oluyor, kısa olanlar çalışıyor | Sağlayıcının `Timeout (seconds)` değeri | Çağrıda HTTP 504 sonucu |
| Yanıt kelime kelime değil, tek parça geliyor | Gateway önce yanıtın tamamını okumak zorundaydı | Çağrıda `translated` veya `cache`, ya da yanıt üzerinde bir AI flow |
| Bearer token ile HTTP 401, ajan anahtarları çalışıyor | Token bu rota için verilmemiş | `DENIED (audience)` sonucu |
| Yetki devri açık olduğu halde devredilen çağrı reddediliyor | Zincir çok uzun ya da bir ajanı iki kez adlandırıyor | Token isteği reddedilir |
| İstenenden daha küçük bir model yanıt veriyor | `Cheaper model close to a limit` | `X-Monosign-Downgraded-From` başlığı |
### Bir sağlayıcının zaman sınırı
Her sağlayıcının bir `Timeout (seconds)` değeri vardır. Varsayılan 300'dür ve 5 ile 3600 arasını kabul eder. İlk baytın beklenmesini ve akışla gelen her satırın beklenmesini kapsar.
Örnek: bir akıl yürütme modeli herhangi bir şey göndermeden önce altı dakika düşünüyor. Varsayılan değerle Gateway 300 saniye sonra vazgeçer ve HTTP 504 `The AI provider did not answer within {n} seconds.` yanıtını verir. Aynı sağlayıcıdaki kısa prompt'lar çalışır, bu da sorunu rastgeleymiş gibi gösterir. Çözüm sağlayıcıdadır: `Timeout (seconds)` değerini yükseltin. Aynı çağrıyı yeniden denemek yalnızca beklemeyi tekrarlar.
### Akışla gelen yanıt neden tek seferde ulaşabilir
Normalde Gateway akışla gelen bir yanıtı geldikçe iletir. Üç durumda önce yanıtın tamamını elinde tutmak zorundadır:
- yanıt sağlayıcı biçimleri arasında çevriliyorsa (`Let clients of the other format in`),
- yanıt yanıt önbelleğinden geliyorsa,
- `Response` aşamasındaki bir AI flow yanıtı inceliyorsa.
Bu durumda Gateway yanıtı bütün olarak alır ve istemciye akış olarak yeniden oynatır. Bu beklenen davranıştır, arıza değildir. Bir flow, çoktan gönderilmiş metindeki bir kart numarasını gizleyemez; yani bir yanıtı incelemek, onu önce sonuna kadar okumak demektir. Böyle bir flow'u açmadan önce kullanıcılara haber verin.
### Token'lar rota için verilmiş olmalıdır
Bir rota varsayılan olarak `Only tokens issued for this route` kabul eder. Bu yüzden bir OAuth istemcisi Monosign'dan token isterken rotayı adlandırır: `resource` parametresini kayıtlı Gateway rotasına ayarlayarak gönderir (RFC 8707).
- `resource` yoksa: HTTP 401 `The token names no resource. Request it with the resource parameter set to this gateway route.`
- Başka bir şey için verilmiş token: `The token was issued for another resource.`
Denetimi değil, çağıranı düzeltin. `Which tokens are accepted` ayarını gevşetmek, bir servis için üretilmiş token'ın başka bir serviste kullanılmasına izin verirdi. Ajan anahtarları bu denetime tabi değildir ve rota için token verilebilmesi için önce `Register` ile kaydedilmiş olması gerekir.
::diagram ais-route-token-resource
### Yetki devri zincirlerinde bir tavan
`Agent to agent delegation depth`, bir kişinin işinin ne kadar ileri devredilebileceğine karar verir. Bu ayarın üstünde sabit bir tavan vardır: 8 ajandan derin olan ya da aynı ajanı iki kez adlandıran bir zincir her zaman reddedilir. Bu, iki ajanınZaten zincirde yer alan bir işi sonsuza kadar birbirine devretmesini durdururajana iş yeniden devredilemez.
### Daha ucuz bir model yanıt verdiğinde
`Cheaper model close to a limit` bir çağrıyı daha ucuz bir modele taşıdığında, yanıt istenen modeli içeren `X-Monosign-Downgraded-From` başlığını taşır ve çağrı kaydı da aynı bilgiyi tutar. Geliştiriciler başlığı okuyup kullanıcılara yanıtın neden farklı göründüğünü gösterebilir.
Bir flow kurmak dakikalar alır. Onu iyi işletmek ise gözden kolayca kaçan ayrıntılara bağlıdır: güvenle nasıl denenir, onaydan sonra gönderen ne yapmalıdır, hangi bulgular gizlenebilir ve bir flow hangi trafiğe hiç dokunmaz.
### Bir flow'u denemenin üç yolu
| | `Test this flow` | `Watching` | `Enforcing` |
| --- | --- | --- | --- |
| Girdi | Tasarımcıda yazdığınız örnek metin | Gerçek trafik | Gerçek trafik |
| Koruma servisleri, webhook'lar, hakem model | Çağrılmaz | Çağrılır | Çağrılır |
| Bir kişiye sorulur | Asla | Asla | Evet |
| Bir iş akışı başlatılır | Asla | Asla | Evet |
| Mesaj değiştirilir veya durdurulur | Hayır | Hayır | Evet |
`Test this flow` kuru servislerle çalışır: adımlarınızın ve desenlerinizin bir metne nasıl tepki verdiğini gösterir ama kimseyihiçbir koruma servisini, webhook'u, hakem modeli ya da onaylayanı çağırmaz. İzleyen bir flow gerçek trafiği görür ve ne yapacak olduğunu `Runs` altına `would block`, `would ask for approval` ve `would start a workflow` gibi notlarla yazar. `Start enforcing` seçmeden önce bu notları okuyun.
### `Ask a person` sonrası: yeniden gönderin
Monosign, bir kişi karar verirken mesajı açık tutmaz. Gönderene `This message needs approval before it can go on. Send it again once it is approved.` denir.
Monosign ikinci mesajın onaylanan mesaj olduğunu nasıl bilir? Flow, adım, yüzey, hedef, araç, kişi, ajan ve metinden oluşan bir parmak izini karşılaştırır.
Örnek: saat 10:00'da bir ajan bir sözleşme özeti gönderir ve flow onu tutar. 10:10'da onaylayan onaylar. 10:11'de ajan aynı mesajı gönderir ve mesaj geçer. Buradan üç kural çıkar:
- 30 dakika içinde aynı mesaj mevcut isteği yeniden kullanır. İkinci bir istek açmaz.
- Onaylanmış bir istek mesajın bir kez geçmesine izin verir.
- Değişen metin yeni bir mesajdır ve yeni onay gerektirir. Reddedilen istek engeller.
Ajan geliştiricileri bunu yazılıma koymalıdır: mesajı sakla, bekle ve değiştirmeden yeniden gönder.
::diagram ais-flow-approval-resend
### Hangi bulgular gizlenebilir
`Hide what was found`, bir bulgunun metnin **neresinde** olduğunu bilmek zorundadır. Yalnızca iki kaynak konum verir:
| Bulgunun kaynağı | Engelleyebilir | `Hide what was found` adımını besleyebilir |
| --- | --- | --- |
| Hazır `Find patterns` | Evet | Evet |
| `Microsoft Presidio` ile `Ask a guard service` | Evet | Evet |
| Diğer koruma servisleri | Evet | Hayır |
Yani zaten Presidio çalıştıran bir müşteri bir `Ask a guard service` adımı ve altına bir `Hide what was found` adımı koyar. Yalnızca "bu mesaj zararlı" diyen bir koruma servisi mesajı durdurabilir ama maskeleyemez.
### Kapsam: `automation` istisnası
`Where does it apply?` altında sınırı olmayan bir flow her yerde uygulanır, tek bir istisnayla: Monosign'ın kendi `automation` özelliğinin prompt'ları. Bunlara yalnızca `Only in these Monosign features` altında `automation` adını veren bir flow dokunur. Denetim, automation prompt'larının neden hiç incelenmediğini sorarsa ilk bakılacak yer burasıdır.
### API üzerinden oluşturulan flow'lar
| | Tasarımcı | Alan gönderilmeden API |
| --- | --- | --- |
| Mod | İzleme olarak başlar | `Enforce` |
| Kaydedilen çalıştırma metinden ne tutar | Bulguları karartılmış kısa bir alıntı | Hiçbir şey |
Bu yüzden API üzerinden `Mode` gönderilmeden oluşturulan bir flow, durumu `Active` olur olmaz gerçek trafik üzerinde işlem yapar. Flow'ları bir işlem hattından dağıtan ekipler `Mode` ve `RetentionMode` alanlarını her zaman açıkça göndermelidir.
### Politikaya sürekli takılan kişiler
Uygulayan flow'ların engellemeleri `AI Policy Violations` algılamasına sayılır; varsayılan 60 dakikada 5 engellenen mesajdır. Algılama o kişi için `user.hasActiveThreat` değerini ayarlar. Flow koşulları `user.hasActiveThreat` değerini okuyabildiği için başka bir flow tam olarak bu kişilere daha sıkı davranabilir, örneğin diğerleri geçerken onlar için bir kişiye sorabilir.
Önceki ders makine kimliklerini tanıttı. Bu ders seçenekler arasında karar vermenize yardım eder, çünkü her seçim bir riski bir yerden başka bir yere taşır.
### Hangi kimlik doğrulama yöntemi
| Yöntem | İş yükünde sır saklanır mı | Gereksinim | Uygun olduğu yer |
| --- | --- | --- | --- |
| Universal Auth | Evet, bir client secret | Başka bir şey gerekmez | Daha iyisi yoksa her yer |
| OIDC | Hayır | Herkese açık keşfedilebilir bir issuer | GitHub Actions ve GitLab gibi CI işlem hatları, OIDC issuer'ı olan yönetilen kümeler |
| Kubernetes | Hayır | Monopam kümenin API sunucusuna erişebilmelidir | Kendi yönettikleriniz dahil, erişilebilen her küme |
Issuer'ı yalnızca küme içinde bilinen, kendi yönettiğiniz bir kümede OIDC ile oturum açma çalışmaz. Orada Kubernetes kimliği kullanın.
::diagram ais-machine-auth-choice
### İşlem hattı için OIDC: bağlı claim
Bir yapay zekâ kodlama ajanı bir CI işinde çalışıyor. CI platformu her işe zaten imzalı bir token verir, bu yüzden işlem hattında hiçbir Monopam sırrının durması gerekmez. Kimliğin üç alanı vardır:
- `Issuer`: CI platformunun token issuer'ı, örneğin `https://token.actions.githubusercontent.com`.
- `Audience`: ayarlandığında denetlenir.
- `Bound claim (sub)`: hangi iş yükünün oturum açabileceği. Sonda joker desteklenir, örneğin `repo:my-org/*`.
En önemlisiBağlı claim'i doldurun. Giriş, token'ı issuer'ın anahtarlarına, tanımlıysa audience değerine ve bağlı claim'dire göre denetler. Herkese açık bir CI platformu bütün müşterileri içinmüşterilerinin token üretir; yalnızca issuer'a güvenmek çok fazla işlem hattına güvenmek olurdu.larını aynı issuer ile imzalar; kimliği kendi depolarınıza bağlayan alan `Bound claim (sub)` claim'i güveni kendi depolarınıza daraltıralanıdır.
### Kubernetes: token'ı kim inceler
Monopam bir service account token'ını kendisi doğrulamaz. Token'ı TokenReview için kümeye gönderir. Bu inceleme bir kimlik bilgisi gerektirir ve hangisinin kullanılacağını siz seçersiniz:
| | `Reviewer Token` ayarlı | `Reviewer Token` boş (kendi kendini inceleme) |
| --- | --- | --- |
| `system:auth-delegator` rolüne kim bağlanır | Tek bir inceleyici service account | Bağlı her iş yükü service account'u |
| İş yüklerine ek hak | Yok | Her birine küme genelinde bir izin |
| Monopam'da saklanan | Şifrelenmiş tek bir küme token'ı | Hiçbir şey |
Öncelik ajan iş yüklerinin kümede ek hak almaması ise Reviewer Token seçin. Öncelik Monopam'ın hiçbir küme token'ı saklamaması ise kendi kendini incelemeyi seçin ve daha geniş bağlamayı kabul edin.
### Grant'lar: proje, ortam, yol, yazma
Bir grant `Project`, `Environment`, `Path` ve `Write` anahtarından oluşur.
- Bir ortam seçmezseniz `Environment` değeri `All environments` olur. Bu, sonradan oluşturulan ortamları da kapsar.
- `Path` bir önektir: `/db`, `/db` yolunu ve altındaki her şeyi kapsar.
- Siz açmadıkça `Write` kapalıdır.
Örnek: bir raporlama ajanının `staging` ortamında `billing` projesinin veritabanı ayarlarına yalnızca okuma için ihtiyacı var. Grant şöyle olur: proje `billing`, ortam `staging`, yol `/db`, `Write` kapalı. Ortamı boş bırakmak ona üretimi de verirdi.
### Okuma denetim penceresi nerede
`Machine read audit window (minutes)`, `System → Secrets API` altında, `Audit` kartındadır. Makine API'si, MCP aracı `get_secret` ve Vault uyumlu API üzerinden yapılan okumalara uygulanır. 0 ile her okuma kendi kaydını alır.
### MCP sunucusu üzerinden oturumlar
Bir sunucudaki iş için, kullanıcı token'ı olan bir ajan parola yerine şu araçları kullanır:
| Araç | Amaç |
| --- | --- |
| `open_session` | Aracılı bir oturum açar. Hesap onay gerektiriyorsa `approval_pending` yanıtını verir |
| `session_exec` | Bir SSH oturumunda komut satırı çalıştırır |
| `session_query` | Bir veritabanı oturumunda sorgu çalıştırır |
| `close_session` | Oturumu sonlandırır |
Kimlik bilgisi Monopam'da kalır, yani model onu hiç görmez. Bir SSH oturumu kaydedilir, bir operatörün devralabildiği veya sonlandırabildiği Live Sessions içinde görünür ve her komut satırı ayrıcalıklı komut denetiminden geçer.