Gerçekten İşe Yarayan AI Agent Production Guardrails Oluşturma

AI agent production guardrails, yalnızca kibar bir prompt'tan daha fazlasına dayanabilmelidir. Otonom bir coding agent hedefi yanlış anlayabilir, bir işlemi yeniden deneyebilir, açıklamasında bir credential'ı açığa çıkarabilir veya belirsiz bir yanıttan sonra çalışmaya devam edebilir. Bu nedenle production güvenliği yalnızca talimatlarda değil; çalıştırılabilir interface'te, authorization model'inde ve audit trail'de de bulunmalıdır.

Dockup, Claude Code ve Codex skill'inde yer alan davranışsal yönlendirmeyi CLI düzeyindeki enforcement mekanizmalarıyla birleştirir: secret'lar maskelenir, destructive operation'lar için --yes gerekir, hatalar sabit code'larla döner, deploy'lar terminal state'i bekleyebilir ve mutation'lar audit log'da görünür.

Guardrail'lar neden prompt'un altında enforce edilmelidir?

Prompt faydalı bir policy'dir, ancak security boundary değildir. Agent context'i kısaltılabilir, talimatlar çakışabilir ve model yanlış bir yorum seçebilir. Alttaki tool, güvenli olmayan davranışı zorlaştırmalı veya imkânsız hâle getirmelidir.

Bir silme isteğini ele alalım. Zayıf tasarım, hemen silen bir command sunar ve agent'ın sormayı hatırlamasına güvenir. Daha güçlü tasarım ise ayrı bir confirmation flag'i bulunmadığı sürece operation'ı reddeder.

Dockup daha güçlü olan bu pattern'i kullanır:

dockup up production/api --prune --json

Açık confirmation olmadan destructive cleanup reddedilir ve JSON içinde code:"needs_confirm" yer alır. Hiçbir şey prune edilmez. Agent bu sonucu bir insana iletmeli, approval almalı ve ardından command'ı bilinçli şekilde yeniden çalıştırmalıdır:

dockup up production/api --prune --yes --json

Bu, defense in depth yaklaşımıdır. Dockup skill'i agent'a durmasını söylerken CLI, talimat gözden kaçırılsa bile yanlışlıkla execution yapılmasını engeller.

Secret masking otonom agent'ları nasıl korur?

Agent'lar command output'unu genellikle reasoning süreçlerine veya final response'larına dahil eder. Bir read operation production token'ı döndürürse secret; chat history'ye, log'lara, telemetry'ye, screenshot'lara veya kopyalanmış incident notlarına yayılabilir.

Güvenli bir configuration interface, secret metadata'sını secret value'larından ayırır. Dockup environment variable key'lerini ve isSecret marker'ını döndürür; ancak kayıtlı secret value'ları null veya maskelenmiş olur.

dockup env list -s production/api --json

Agent, secret'ı ayarlayabilir ve daha sonra onu geri almadan çalışabilir:

dockup env set API_KEY="$API_KEY" \
  --secret \
  -s production/api \
  --json

Secret masking, dikkatli process handling ihtiyacını ortadan kaldırmaz. Orijinal value, set operation'ı sırasında shell environment'ında hâlâ bulunur. set -x kullanmayın, variable'ı echo etmeyin ve verbose logging tarafından yakalanan command string'leri oluşturmayın.

Database password'leri, API key'leri, registry token'ları, SSH credential'ları ve Windows RDP credential'ları tek kullanımlık veya erişimi kısıtlanmış output'lar olarak ele alınmalıdır. Agent bunları onaylı bir secret manager'a kaydetmeli veya metin içinde yeniden üretmeden doğrudan sonraki process'e aktarmalıdır.

Daha geniş application-level yaklaşım, security best practices yazısında ele alınmaktadır.

Destructive action approval nasıl çalışmalıdır?

Her mutation aynı ölçüde seremoni gerektirmez. Kullanışlı bir autonomy model'i operation'ları geri alınabilirliklerine ve blast radius'larına göre ayırır:

Seviye	Örnek	Agent'ın varsayılan davranışı
Salt okunur	Service'leri listeleme, status okuma, log'ları görüntüleme	Çalıştır ve özetle
Geri alınabilir write	Variable ayarlama, deploy tetikleme	Onaylı scope içinde çalıştır
Operational recovery	Restart, eski bir deployment'ı yeniden çalıştırma	Runbook izin veriyorsa çalıştır; kanıtı bildir
Destructive	Service'i yok etme, database'i silme, project'ten ayrılma	Açık approval için dur
Geniş kapsamlı destructive	--prune uygulama, ownership devri	Target'a özel human confirmation iste

Açık approval, tam target'ı ve sonucu içermelidir. “Yes, proceed” ifadesi, “staging/old-api ve ilişkili service resource'larını sil” ifadesinden daha zayıftır. Agent, farklı bir command veya target için verilen approval'ı yeniden kullanmamalıdır.

Dockup config as code varsayılan olarak additive çalışır. dockup up, manifest'te bulunmayan environment variable'larını veya domain'leri kaldırmaz. Silme işlemi için açıkça --prune flag'i gerekir:

dockup plan production/api --json
dockup up production/api --prune --json

Plan salt okunurdur ve önce incelenmelidir. --prune kullanılsa bile secret'lar, service'ler, database'ler ve volume'lar bu manifest cleanup path'inde korunur. Tam workflow için dockup.yaml config as code yazısına bakın.

Yapılandırılmış hatalar autonomy'yi nasıl sınırlar?

Bir agent'ın güvenli branch'lerden oluşan sonlu bir kümeye ihtiyacı vardır. Free-form message'lar insanlar için faydalıdır; ancak sabit error code'ları ilk response'u deterministik hâle getirir.

Code	Doğru response
not_logged_in	Dur ve geçerli bir credential edin
not_linked	Target'ı çözümle veya açıkça ilet
no_target	Service discovery çalıştır; hiçbir zaman slug uydurma
needs_confirm	Human approval iste
deploy_trigger_failed	Operation'ın neden başlatılamadığını bildir
deploy_failed	Build log'larını incele
deploy_timeout	Terminal olmayan belirsizliği bildir

Bir deployment, terminal-state waiting kullanmalıdır:

dockup deploy production/api --wait --json

Varsayılan timeout 900 saniyedir. Exit 0, deployment'ın başarıya ulaştığını kanıtlar. Non-zero exit, agent'ın production hazırmış gibi domain değişikliklerine, migration'lara veya duyurulara devam etmesini engeller.

Bu tasarım AI agent CLI design yazısında incelenmektedir. İlke basittir: tool, belirsiz bir sonucu açıkça görünür hâle getirmelidir.

Bir audit log neleri kaydetmelidir?

Attribution olmadan autonomy, operational debt oluşturur. Bir production audit trail; kimin işlem yaptığını, hangi interface'in kullanıldığını, hangi target'ın değiştiğini, bunun read mi yoksa write mı olduğunu, ne zaman gerçekleştiğini ve başarılı olup olmadığını yanıtlayabilmelidir.

Dockup, CLI, UI ve API action'larını kaydeder. Operator'lar yakın zamanda gerçekleşen mutation'ları inceleyebilir:

dockup audit --writes --json
dockup audit --number 30 --json
dockup audit --search domains --json

Agent'ın kendi report'u platform kaydını tamamlamalıdır. Şunları ekleyin:

1. Çözümlenen project/service target'ı.
2. Secret value'ları içermeyen command category'si.
3. Platform tarafından döndürülen deployment veya resource ID'leri.
4. Exit code ve yapılandırılmış status.
5. Mutation sonrasında toplanan kanıt.
6. Destructive work için alınan approval.
7. Kalan belirsizlik veya follow-up.

Audit log'ları yalnızca incident sonrasında suçlu bulmak için kullanılmaz. İkinci bir agent'ın veya insan operator'ın riskli command'ları tekrarlamadan state'i yeniden oluşturmasına olanak tanır.

Ekipler agent autonomy'sini güvenli şekilde nasıl artırabilir?

Read access ve düşük riskli tek bir service ile başlayın. Agent doğru target discovery, secret hygiene, failure branching ve reporting sergilediğini kanıtladıkça kapsamı genişletin.

Uygulanabilir bir ilerleme şu şekildedir:

Aşama 1: Gözlemle

Service listing, status, deployment history, build log'ları, runtime log'ları, uptime, usage ve security scan read işlemlerine izin verin. Agent'ın summary'sini raw JSON ile karşılaştırın.

Aşama 2: Sabit bir target içinde deploy et

Bir service'in --wait ile deploy edilmesine izin verin. Health check ve yapılandırılmış completion report'u zorunlu tutun. Silme veya team permission'ları vermeyin.

Aşama 3: Geri alınabilir configuration'ı yönet

Reviewed bir runbook kapsamında non-secret ve secret variable update'lerine, health-check configuration'ına ve custom-domain setup'ına izin verin. Environment değişikliklerinden sonra redeployment yapılmasını zorunlu tutun.

Aşama 4: Recovery action'larını çalıştır

Restart veya rollback'e yalnızca agent tam olarak bilinen bir deployment ID'si seçtiğinde ve failure evidence'ı koruduğunda izin verin.

Aşama 5: Approval-gated destructive work

Credential teknik olarak izin verse bile destructive flag'leri açık human approval arkasında tutun. Mümkün olduğunda scoped API key'leri kullanın ve audit trail'i düzenli olarak inceleyin.

Agent skill kurulumu bu davranışları pekiştirir:

npm install -g dockup-cli
dockup skill install
dockup skill status --json

Dockup CLI reference, enforce edilen command davranışını belgeler. Agent, hatırlanan bir örneğe güvenmek yerine local schema'sını doğrulamalıdır.

Guardrail review checklist

Production access vermeden önce her soruyu yanıtlayın:

• Agent, tahmin yürütmeden tam target'ları keşfedebiliyor mu?
• Tüm read path'lerinde secret value'ları maskeleniyor mu?
• Her failed mutation non-zero döndürüyor mu?
• Uzun süren operation'lar terminal state'i bekleyebiliyor mu?
• Destructive action'lar açık confirmation olmadan engelleniyor mu?
• Credential'lar scope'landırılmış ve prompt'ların dışında mı sağlanıyor?
• Her mutation bir audit log'da bulunabiliyor mu?
• Test edilmiş bir rollback veya recovery procedure var mı?
• Skill ve executable version'ları birbirinden sapabilir mi?
• Final report, fact ile uncertainty'yi birbirinden ayırıyor mu?

Bir “hayır” yanıtı prompt yazma görevi değil, bir tasarım görevidir. Production autonomy'si yalnızca alttaki garantiler güçlendikçe artırılmalıdır.

Guardrail'ları failure case'leri olarak test edin

Ekip sınırları bilinçli olarak tetikleyene kadar review tamamlanmış sayılmaz. Geçersiz token ile deploy çalıştırın, bilinmeyen bir target isteyin, bir test build'inin fail olmasına izin verin, çok kısa bir timeout belirleyin ve confirmation olmadan destructive bir command çalıştırmayı deneyin. Her case non-zero exit, sabit bir code, secret leakage olmaması ve unintended mutation gerçekleşmemesi sonucunu üretmelidir.

Bu testler AI agent production guardrails kavramını gözlemlenebilir garantilere dönüştürür. Bunları, bir application için authentication ve authorization testlerini tekrarladığınız gibi, CLI veya policy update'lerinden sonra da tekrarlayın. Yalnızca bir slide deck'te bulunan guardrail, unattended bir release'i korumaz.

Workflow'u production'a taşıyın

Skill'i kurun, talimatlarını inceleyin ve production token'ı vermeden önce engellenmiş bir destructive command dahil olmak üzere her guardrail'ı test edin.

npm install -g dockup-cli
dockup skill install

İlk command CLI'ı kurar. İkinci command, Claude Code ve Codex için eşleşen Dockup skill'ini kurar. app.dockup.ai adresinde ücretsiz başlayın.

FAQ

Prompt talimatları bir AI agent'ını production'da güvende tutmak için yeterli midir?

Hayır. Prompt'lar davranışı yönlendirmeye yardımcı olur; ancak secret masking, confirmation, authorization, exit code'lar ve audit logging gibi kritik kontroller tool ve platform tarafından enforce edilmelidir.

Dockup destructive operation'ları nasıl engeller?

Destructive command'lar açık --yes flag'i olmadan çalışmayı reddeder ve yapılandırılmış needs_confirm code'unu döndürür. Böylece agent durup bir insandan approval isteyebilir.

Bir AI agent Dockup'tan secret environment value'larını okuyabilir mi?

Kayıtlı secret value'ları output'ta maskelenir. Agent key'i ve secret marker'ını görebilir ve value'yu değiştirebilir; ancak kayıtlı secret'ı alamaz.

Structured error code'ları autonomy için neden önemlidir?

Agent'ı authentication isteme, tam target'ı keşfetme, build log'larını okuma veya confirmation isteme gibi bilinen recovery branch'leriyle sınırlar.

Bir ekip production access vermeye nasıl başlamalıdır?

Salt okunur operation'larla başlayın, ardından düşük riskli tek bir target'a deployment'a izin verin ve agent doğrulanabilir kanıtları tutarlı şekilde raporladıktan sonra geri alınabilir configuration ve recovery kapsamını genişletin.