AI Agent’lara Repository Erişimi Verirken Hangi Yetkiler Sınırlandırılmalı?

Kısa özet: AI coding agent’a repository erişimi vermek yalnızca “kodu okuyabilsin mi, yazabilsin mi?” sorusundan ibaret değildir. Güvenli kullanımda en az şu sınırlar ayrı ayrı düşünülmelidir: hangi repository’lere erişebileceği, hangi dosyalara yazabileceği, shell komutları, Git işlemleri, branch ve merge yetkileri, secrets, network erişimi, MCP araçları, CI/CD ve production sistemleri. GitHub Copilot cloud agent, OpenAI Codex ve Claude Code gibi güncel agent araçlarının güvenlik modelleri de aynı temel prensibe dayanıyor: rutin geliştirme işlemlerine izin verirken yüksek etkili eylemleri sandbox, permission policy, branch protection, network policy ve insan onayıyla sınırlandırmak. En önemli prensip: AI agent’a geliştiricinin sahip olduğu bütün yetkileri otomatik olarak aktarmayın. Görev için gereken minimum yetkiyi verin.

Kısa doğrudan cevap

AI coding agent için önerilen varsayılan erişim modeli:

• Repository read
• Workspace write
• Test / lint / build
• Kısıtlı Git işlemleri
• Kısıtlı network

olabilir.

Buna karşılık şu işlemler daha yüksek güven sınırında tutulmalıdır:

• Main branch'e doğrudan yazma
• Production deploy
• Secret okuma
• Database production erişimi
• Permission değiştirme
• Cloud resource silme
• DNS değiştirme
• Release yayınlama
• Destructive migration

Bu işlemler mümkünse: `Agent önerir → CI doğrular → İnsan inceler → Yetkili sistem uygular` modelinde yürütülmelidir.

Repository erişimi neden yeni bir güvenlik sınırı oluşturuyor?

Klasik kod asistanı `Developer yazıyor → AI öneri veriyor` modelindeydi. Agentic coding modeli ise `AI repository okuyor → Dosya değiştiriyor → Terminal çalıştırıyor → Test çalıştırıyor → Git branch oluşturuyor → PR hazırlıyor → Harici araçlara bağlanıyor` seviyesine geldi.

Bu nedenle AI agent artık yalnızca “kod üreten model” değil, belirli sınırlar içinde çalışan bir yazılım otomasyonu kimliği gibi değerlendirilmelidir. GitHub, Copilot cloud agent’ın repository koduna erişebildiğini ve değişiklik push edebildiğini açıkça belirtiyor; bu nedenle erişimi tek branch ile sınırlandırma, branch protection, required checks ve human review gibi kontroller uyguluyor. OpenAI de Codex’i gerçek iş akışlarında kullanırken sandbox, approval policy, network policy, credential yönetimi, kurallar ve telemetry katmanlarını birlikte kullanıyor.

En önemli hata: “Developer erişebiliyorsa agent da erişebilir”

Bir geliştiricinin bilgisayarında GitHub token, AWS credential, database bağlantısı, SSH key, npm token, cloud CLI session, production `.env` bulunabilir. Agent’ın aynı kullanıcı hesabı altında çalışması, teorik olarak bu kaynakların tamamına erişmesi gerektiği anlamına gelmez. Daha doğru prensip: `Developer'ın maksimum yetkisi ≠ Agent'ın gerekli yetkisi`.

AI agent repository izinlerini 9 ayrı katmanda düşünün

1. Hangi repository’lere erişebilir?

İlk sınır repository seçimidir. Agent’a "all repositories" vermek yerine gerçekten gerekli repository’ler seçilmelidir. GitHub kuruluş yöneticileri Copilot cloud agent erişimini tüm repository’ler, yalnızca seçilen repository’ler veya hiçbir repository şeklinde yönetebiliyor. Kurumsal ilke: Agent, kullanıcının yetkisini genişleten arka kapı olmamalıdır.

2. Repository içinde hangi dosyalara yazabilir?

Bir agent’ın çoğu görev için `src/`, `tests/`, `docs/` alanlarına yazabilmesi yeterlidir. Buna karşılık `.github/workflows/`, `terraform/`, `Dockerfile`, `CODEOWNERS`, `package.json`, `lockfile`, `next.config.*`, `.env*` gibi alanlar daha hassastır. OpenAI Codex ve Claude Code varsayılan olarak workspace-write veya dar sandbox yaklaşımları sunar. `Read geniş olabilir, Write dar olmalı` kuralı uygulanmalıdır. `.env` ve secret dosyaları çalışma alanından ayrılmalıdır.

3. Terminal ve shell yetkisi ne kadar geniş olmalı?

`npm test`, `npm run lint`, `npm run build` gibi komutlar rutin development parçasıdır. Ancak shell aynı zamanda `rm -rf`, `curl`, `ssh`, `terraform destroy`, `aws`, `kubectl` gibi tehlikeli komutları çalıştırabilir. Komutlar üç seviyeye ayrılabilir:

• Düşük Risk (Otomatik): `npm test`, `npm run lint`, `git diff`
• Orta Risk (İzlemeli): `npm install`, `git commit`, `local docker`
• Yüksek Risk (İnsan Onaylı): `production deploy`, `terraform destroy`, `database migrate prod`

4. Git yetkileri nasıl sınırlandırılmalı?

Agent’ın source code değiştirebilmesi için doğrudan `main` branch write yetkisine ihtiyacı yoktur. Model: `Agent branch → Pull Request → CI → Code Review → Merge`. GitHub Copilot cloud agent yalnızca tek bir çalışma branch’ine (`copilot/...`) push eder, kendi PR’ını approve veya merge edemez. CODEOWNERS ile hassas dosya değişikliklerinde ilgili insan mühendisler otomatik incelemeye çağrılmalıdır.

5. Network erişimi neden varsayılan olarak sınırsız olmamalı?

Agent terminal kullanabiliyorsa açık network erişimi data exfiltration, prompt injection ve zararlı dependency indirme risklerini artırabilir. OpenAI Codex kullanımında açık uçlu outbound network yerine domain allowlist uygulanır. Network seviyeleri: Offline (yalnızca local), Domain Allowlist (npm, github, approved APIs) veya Açık Network (Approval gerektiren).

6. Secrets nasıl verilmelidir?

Agent’a tüm environment variable’ları vermek yerine yalnızca görev için gerekli kısıtlı ve mümkünse read-only token’lar sağlanmalıdır. Secret’lar repository koduna yazılmamalı ve loglanmamalıdır.

7. MCP araçları ayrı bir permission yüzeyidir

Repository agent’ları MCP sayesinde Jira, database, cloud, CRM gibi dış araçlara ulaşabilir. Repository access ile MCP access aynı permission değildir. MCP tool’larında read ve write ayrılmalı, destructive işlemler onay gerektirmelidir.

8. GitHub Actions ve CI yetkileri ayrıca sınırlandırılmalı

Agent `.github/workflows/` içindeki bir workflow dosyasını değiştirebiliyorsa dolaylı olarak CI secrets ve production deploy yetkisi elde edebilir. Bu nedenle workflow dosyaları protected code kabul edilmeli ve insan onayı arkasında tutulmalıdır.

9. Production erişimi repository erişiminden ayrılmalı

Production koda yazabilmek ile production sistemini yönetebilmek farkıdır (`Agent → Kod → PR → CI → İnsan Onayı → Deployment`). Production erişimi gerekiyorsa bu assistant değil, yüksek yetkili operasyon agent'ı olarak tasarlanmalıdır.

Repository talimat dosyaları güvenlik kontrolü değildir

`AGENTS.md` veya `CLAUDE.md` içine “Production'a deploy etme” yazmak policy guidance’dır; teknik güvenlik sınırı değildir. Gerçek engel credential olmaması, sandbox, network kısıtı ve branch protection’dır.

Prompt injection repository üzerinden gelebilir mi?

Evet. Agent repository içindeki issue, README, test data veya dokümanları okurken zararlı prompt injection talimatlarıyla karşılaşabilir. Network sınırı ve secret izolasyonu prompt injection’ın etki alanını (blast radius) düşürür.

Örnek erişim matrisi

Bu tablo InoviqLab önerisidir.

AI Agent Repository Güvenlik Kontrol Listesi

• Repository: Agent yalnızca gerekli repolarda aktif, kullanıcının yetkisi üzerinde erişim yok.
• Filesystem: Write erişimi workspace ile sınırlı, `.env` ve credential dosyaları korumada.
• Git: Ayrı agent branch'i kullanılıyor, main branch push engelli, CODEOWNERS aktif.
• Terminal: Düşük riskli komutlar otomatik, destructive komutlar insan onaylı.
• Network & Secrets: Domain allowlist uygulanıyor, yalnızca gerekli read-only secret'lar veriliyor.
• MCP & CI/CD: MCP araçlarında read/write ayrımı var, CI workflow değişikliği insan onayında.
• Audit: Agent session ve commit logları izlenebilir durumda.

InoviqLab teknik değerlendirmesi

Bu bölüm InoviqLab değerlendirmesidir; GitHub, OpenAI veya Anthropic dokümantasyonundan ayrıdır. AI coding agent güvenliğinde ana soru “Agent ne kadar akıllı?” değil; “Yanlış karar verdiğinde maksimum ne yapabilir?” olmalıdır.

• Blast radius küçültün: Sınırlı repo, workspace write, no prod secrets, allowed network, agent branch.
• Enforcement kurgulayın: Prompt talimatı yetmez, teknik engel koyun.
• Agent branch + human merge: Kod üreten kimlik ile merge eden kimlik ayrı olmalıdır.
• Production ayrı trust zone: Dev agent production'a doğrudan erişmemelidir.

Sonuç

AI agent’a repository erişimi vermek tek bir permission değildir. Repository, filesystem, shell, Git, network, secrets, MCP, CI/CD ve production katmanları ayrı yönetilmelidir. Temel kural: AI agent’a “işini yapabileceği kadar” erişim verin; “teknik olarak verebildiğiniz kadar” değil.