MCP Sunucularına Kim Erişebilmeli? Kurumsal AI Entegrasyonlarında Yetki ve Allowlist Rehberi

Kısa özet: Bir MCP sunucusunu şirket içinde kullanıma açarken yalnızca “hangi MCP server’lara izin veriyoruz?” sorusunu cevaplamak yeterli değildir. Güvenli mimaride en az beş ayrı sınır bulunmalıdır: izin verilen MCP sunucuları, kullanıcı veya servis kimliği, OAuth scope’ları, kullanılabilecek MCP tool’ları ve erişilebilecek gerçek veri/tenant sınırı. 23 Ağustos 2026 itibarıyla güncel MCP 2026-07-28 spesifikasyonu OAuth tabanlı authorization modelini güçlendiriyor; access token’ların hedef MCP server’a bağlı olmasını, token passthrough yapılmamasını ve mümkün olan en düşük scope’ların kullanılmasını öngörüyor. Yeni Mcp-Method ve Mcp-Name header’ları da gateway, WAF ve rate limiter katmanlarında tool seviyesine kadar politika uygulanmasını kolaylaştırıyor.

Kısa doğrudan cevap

Kurumsal bir MCP entegrasyonunda önerilen erişim modeli: ```text Onaylı MCP server ↓ Doğrulanmış kullanıcı / servis ↓ Minimum OAuth scope ↓ İzin verilen tool ↓ İzin verilen tenant / kayıt / kaynak ↓ Gerekirse kullanıcı onayı ``` şeklinde olmalıdır.

MCP server allowlist tek başına yeterli değildir. Örneğin bir kullanıcının `company-crm-mcp` sunucusuna erişebilmesi: bütün CRM araçlarını, bütün müşterileri, bütün tenant’ları, silme veya değiştirme işlemlerini kullanabilmesi anlamına gelmemelidir.

MCP server neden normal bir API entegrasyonu gibi korunmalı?

Model Context Protocol, yapay zekâ istemcilerinin dış sistemlerle standart biçimde iletişim kurmasını sağlar. Bir MCP server:

• dosyalara erişebilir,
• CRM verisi okuyabilir,
• GitHub repository’sine erişebilir,
• database sorgusu çalıştırabilir,
• deployment başlatabilir,
• ticket oluşturabilir,
• finansal kaydı değiştirebilir,
• harici API çağrısı yapabilir.

Dolayısıyla `AI Agent → MCP Server → İş sistemi` akışı yalnızca “AI özelliği” değildir. Gerçekte bir yetkilendirilmiş sistem entegrasyonudur. MCP spesifikasyonu da tools üzerinden keyfî veri erişimi ve kod çalıştırma yollarının mümkün olduğunu, kullanıcı kontrolü, authorization ve data protection katmanlarının implementasyon tarafından sağlanması gerektiğini açıkça belirtir.

Güncel MCP authorization modeli ne durumda?

MCP’nin güncel 2026-07-28 spesifikasyonu 28 Temmuz 2026’da yayımlandı. Bu sürüm stateless protocol core, authorization hardening, header-based routing, yeni extension framework ve client registration değişiklikleri getirdi. Authorization açısından korunan bir HTTP MCP server OAuth Resource Server gibi davranır. MCP client ise OAuth Client rolünü üstlenir. Authorization server da access token üretir.

MCP’de authorization zorunlu mu?

Protokol açısından her MCP implementasyonu için zorunlu değildir. Güncel spesifikasyona göre:

• HTTP transport kullanan ve authorization sunan implementasyonlar MCP authorization spesifikasyonunu izlemeli,
• stdio tabanlı local server’lar bu OAuth akışını kullanmamalı ve credential’ları environment üzerinden almalı,
• diğer transport’lar kendi güvenlik pratiklerini uygulamalıdır.

Ancak bu “Kurumsal MCP server’da authentication olmadan çalışmak güvenlidir” anlamına gelmez. İnternetten, şirket ağından veya çok kullanıcılı AI istemcilerinden ulaşılabilen bir MCP server’ın kimlik ve yetki kontrolü olmadan çalışması ciddi risk oluşturabilir.

Server allowlist neyi çözer?

Allowlist “Hangi MCP server’ların kullanılmasına izin veriyoruz?” sorusuna cevap verir. Örneğin ` izinli olabilir; buna karşılık `random-public-mcp.example` engellenebilir. Kurumsal istemci açısından bu önemli bir ilk katmandır. Ancak yalnızca server seçimini kontrol eder.

Allowlist neyi çözmez?

Şu sorular hâlâ cevaplanmalıdır:

• Bu server’a hangi çalışan erişebilir?
• Kullanıcının hangi scope’ları var?
• Hangi tool’ları kullanabilir?
• Tool hangi tenant verisine erişebilir?
• Silme veya yazma işlemi yapabilir mi?
• Production işlemleri için ayrıca onay gerekiyor mu?
• Kullanıcı şirketten ayrıldığında erişim otomatik kapanıyor mu?

Dolayısıyla: `Server allowlist ≠ Authorization sistemi`.

Güvenli MCP erişimi için 5 katman

1. Katman — Hangi MCP server kullanılabilir?

İlk katman Server allowlist olmalıdır. İzin mümkünse tam URL, kontrollü domain veya kesin local command üzerinden verilmelidir. GitHub’ın güncel enterprise managed settings sistemi MCP server’ları `serverUrl`, `serverCommand`, `serverName` üzerinden eşleştirebiliyor: ```json {

"allowedMcpServers": [

{

"serverUrl": "

}, {

"serverCommand": [

"npx", "-y", "@company/internal-mcp" ] } ] }

#### serverName ile allowlist yapmak yeterli mi?
Her zaman değil. GitHub dokümantasyonu `serverName` değerinin kullanıcı tarafından atanabilen bir label olduğunu özellikle belirtiyor. Dolayısıyla gerçek server kimliğini zorlamak istiyorsanız remote server için `serverUrl`, local stdio server için `serverCommand` daha güçlü eşleştirme yöntemleridir.

#### Allowlist'i boş bırakmanın sonucu platforma göre değişebilir
GitHub Copilot enterprise managed settings örneğinde: `allowedMcpServers` hiç tanımlanmazsa non-default MCP server'lar izinli olabilir. Ancak `"allowedMcpServers": []` kullanılırsa built-in default server’lar dışında diğer MCP server’lar bloklanır.

#### Denylist ne zaman kullanılmalı?
Allowlist ana kontrol olmalıdır. Denylist ise belirli riskli server veya command’ları engellemek için kullanılabilir:

{

"deniedMcpServers": [

{

"serverCommand": [

"npx", "-y", "@modelcontextprotocol/server-filesystem", "/" ] } ] } ``` Deny rule, allow rule’dan önceliklidir. Bir server hem allowlist hem denylist ile eşleşirse bloklanır.

2. Katman — MCP server’a kim bağlanıyor?

Server seçildikten sonra ikinci soru: “Bu isteği kim yapıyor?” olmalıdır. Kimlik insan kullanıcı, backend servis, CI job veya AI agent adına çalışan platform olabilir. Remote HTTP MCP entegrasyonlarında OAuth tabanlı authorization bunun için temel mekanizmadır. MCP server access token’ı doğrulamalı ve token’ın özellikle kendisi için üretildiğini kontrol etmelidir.

#### Token'ın yalnızca geçerli olması neden yeterli değil? Çünkü token başka servis için oluşturulmuş olabilir. MCP spesifikasyonu client’ın authorization ve token isteklerinde `resource` parametresini kullanmasını ve hedef MCP server’ı açık biçimde belirtmesini zorunlu tutuyor.

Doğru model: `Token geçerli mi? + Issuer doğru mu? + Audience doğru mu? + Resource MCP server mı? + Scope yeterli mi?`

3. Katman — Kullanıcı hangi scope’lara sahip?

Authentication “Sen kimsin?”, Authorization ise “Ne yapabilirsin?” sorusunu cevaplar. MCP authorization spesifikasyonu scope kullanımında least privilege yaklaşımını öneriyor. Örneğin `crm:read` ile `crm:write` ayrı tutulabilir; hatta `customers:read`, `customers:update`, `customers:delete`, `invoices:create` gibi scope’lar kullanılabilir.

#### Step-up authorization ne işe yarıyor? Güncel MCP 2026-07-28 authorization modeli çalışma sırasında daha yüksek scope gerektiğinde step-up authorization uygulanmasına izin veriyor. Örneğin kullanıcı CRM kayıtlarını görüntüleyebilir (token: `customers:read`). Agent müşteri kaydını silmek istediğinde (`customers:delete` gerekir) server `403 Forbidden` (`insufficient_scope`) döndürür. Client daha yüksek scope için yeniden authorization isteyebilir.

4. Katman — Hangi MCP tool kullanılabilir?

Bir MCP server’ın kendisine erişim verilmesi o server içindeki bütün tool’lara erişim verilmesi anlamına gelmemelidir. Örneğin bir destek personeli yalnızca `search_customer` ve `get_customer` kullanabilmeli; `delete_customer` ise yalnızca belirli roller ve kullanıcı onayı gerektirmelidir. Tool seviyesinde authorization MCP server içinde veya çağırdığı uygulama katmanında uygulanmalıdır. UI’da butonu gizlemek tek başına bir güvenlik kontrolü değildir.

#### Mcp-Method ve Mcp-Name header’ları ne değiştiriyor? MCP 2026-07-28 spesifikasyonu Streamable HTTP isteklerinde `Mcp-Method` ve `Mcp-Name` header’larını getiriyor (Örn. `Mcp-Method: tools/call`, `Mcp-Name: delete_customer`). Gateway, WAF veya rate limiter böylece JSON body’yi parse etmek zorunda kalmadan işlem türünü görebilir ve gateway seviyesinde rate limit veya erişim kısıtlaması uygulayabilir.

5. Katman — Kullanıcı hangi veriye erişebilir?

En kritik fakat kolay atlanan katman budur. Kullanıcı `customers:read` scope’una sahip olabilir, fakat multi-tenant SaaS sisteminde Tenant A kullanıcısı Tenant B müşterilerini görmemelidir. Tenant sınırı istemciden gelen parametreye bırakılmamalı; `organizationId` erişim yetkisi doğrulanmış OAuth context/access token üzerinden türetilmelidir.

MCP token'ını downstream API’ye geçirmek doğru mu?

Hayır. MCP authorization spesifikasyonu token passthrough yapılmasını açık biçimde yasaklıyor. MCP server başka API’ye bağlanacaksa upstream API için ayrı credential/token edinmelidir (`MCP Client → MCP için Token A → MCP Server → CRM için ayrı Token B → CRM API`).

Local MCP server daha mı güvenli?

Her zaman değil. Local MCP server `stdio → npx → filesystem tool` şeklinde çalışabilir. Local MCP server terminal, dosya sistemi, environment variables, SSH key, source code ve local credentials gibi hassas kaynaklara erişebilir. Gerekli kontroller: Command allowlist, Filesystem sınırlandırması (`/` yerine `/workspace/project`), minimum environment variables ve sandbox kullanımı.

Kullanıcı onayı ne zaman gerekli?

Düşük riskli okuma işlemlerinde otomatik çalışabilirken; `delete_customer`, `deploy_production`, `send_payment`, `rotate_secret` gibi yüksek riskli işlemlerde agent önerir, kullanıcı ne yapılacağını görür, açık onay verir ve ardından tool çalışır.

Kurumsal MCP erişim matrisi nasıl oluşturulur?

MCP erişim kontrol listesi

• Server governance: MCP server allowlist uygulanıyor, local/remote URL ve command'lar doğrulanıyor.
• Authentication: Access token, issuer ve audience/resource doğrulanıyor. Expired token reddediliyor.
• Authorization: Minimum scope (least privilege) uygulanıyor, gerektiğinde step-up authorization kullanılıyor.
• Tool: Her tool için yetkili roller tanımlı, yıkıcı işlemler onay gerektiriyor.
• Data: Tenant izolasyonu server-side uygulanıyor, cross-tenant erişim engelleniyor.
• Credential & Local: Token passthrough yapılmıyor, token’lar loglanmıyor, local server’lar sandbox ve dizin sınırı ile çalışıyor.

InoviqLab teknik değerlendirmesi

Bu bölüm InoviqLab değerlendirmesidir; MCP spesifikasyonundaki normative gereksinimlerden ayrıdır. Kurumsal MCP güvenliğinde en büyük hata: MCP server’a erişim izni vermeyi, tool kullanım izni vermekle aynı şey sanmaktır. Erişim zinciri: `SERVER → IDENTITY → SCOPE → TOOL → DATA → ACTION` şeklinde düşünülmelidir.

İkinci hata, tek bir `company-mcp` altında her şeyi toplamaktır. Büyüyen kurumsal sistemlerde `crm-mcp`, `billing-mcp`, `deployment-mcp` gibi ayrı domain bazlı sunucular oluşturmak trust boundary’leri korur.

Üçüncü hata, AI modelinin "kullanıcının yetkisi var" önerisini bir güvenlik kontrolü kabul etmektir. Authorization deterministik server-side kurallarla yapılmalıdır.

Dördüncü hata, read ve write işlemlerini aynı riskte görmektir. Pratik risk sınıflandırması (Tier 1 Read, Tier 2 Low-impact Write, Tier 3 High-impact Write, Tier 4 Critical) uygulanmalıdır.

Sonuç

Kurumsal MCP güvenliği “Hangi MCP server’ı kullanabiliriz?” sorusuyla başlamalı ama orada bitmemelidir. Sağlıklı model: `Allowlisted server → Authenticated identity → Minimum scope → Authorized tool → Authorized tenant/data → Controlled action`. En önemli güvenlik prensibi protokolden bağımsızdır: AI agent’a, insan kullanıcıya vermeyeceğiniz bir yetkiyi yalnızca iş kolaylaştırıyor diye vermeyin.