ai ajan denetim kaydı: kayıtlar neleri içermelidir

When an autonomous agent — not a human — is the actor, the usual audit fields (username, IP, timestamp) stop being enough. You still need accountability, reproducibility and non‑repudiation, but the record you store must capture a different set of attributes: model, prompt, tool calls, randomness seeds, code version, and the human who delegated authority. This article lists the fields an ai agent audit log must contain and why each one is necessary for security, compliance and incident response.

Neden olağan "kullanıcı" alanları ai ajanları için yetersiz

Geleneksel denetim kayıtları bir oturumun arkasında tek bir insan aktör olduğunu varsayar: kullanıcı adı, rol, IP, kullanıcı aracısı dizesi ve bir eylem tanımı. Bunlar yararlı olmakla birlikte, ai kaynaklı davranışa özgü şu nitelikleri gözden kaçırır:

• Deterministlik yokluğu: aynı prompt ve model yapılandırması, rastgelelik kaynağını (seed, rand algorithm, temperature) kaydetmedikçe farklı çıktılar üretebilir.
• Çok adımlı zincirler: ajanlar sıkça araçları, API'leri ve diğer ajanları çağırır; yalnızca tek bir eylem girdisi değil, nedensel bir zincire ihtiyacınız vardır.
• Gelişen kod ve modeller: ajanlar kod + model + runtime'dır. Bir kullanıcı adı size kullanılan model checkpoint'ini, container image digest'ini veya ajan politikasını söylemez.
• Delege etme ve onay: bir ajan bir insanın veya başka bir sistemin adına hareket edebilir; denetim izi ajanın kim tarafından yetkilendirildiğini ve hangi kısıtlamaların bulunduğunu göstermelidir.

Özetle: replace the mental model of "a person clicked a button" with "a reproducible computation transformed inputs into outputs and took side effects".

Bir ai ajan denetim kaydının içermesi gereken minimum alanlar

Her bir kayıt girişini bir hesaplamanın ve onun yan etkilerinin kaydı olarak ele alın. En azından bu alanları dahil edin; ortamınızın yasal veya operasyonel ihtiyaçları varsa ilgili öğeleri ekleyin (aşağıda örnekler ve gerekçe yer alıyor).

• record_id — denetim girişi için kalıcı bir UUID (v4 veya v7) ve oturum için sıra numarası.
• timestamp — RFC3339 UTC; yeniden sıralamayı tespit etmek için monotonik sıra numaralarını da dahil edin.
• agent_id — ajan örneği için mantıksal tanımlayıcı (sadece insan sahibi değil).
• agent_version — commit hash, container image digest (ör. sha256:...), veya ajan kodunun paket sürümü.
• model_name & model_digest — model tanımlayıcısı ve kullanılan ağırlıklar/checkpoint için bir digest veya checksum (veya barındırılan modelin sürüm dizesi).
• runtime_config — model parametreleri: temperature, top_k/top_p, max_tokens, eşzamanlılık sınırları ve RNG algorithm.
• prompt_template_id & prompt_hash — prompt şablonunun tanımlayıcısı ve çözülmüş prompt'un hash'i; hassassa düz metni saklamamak için.
• input_artifacts — ekler, dosyalar veya kullanılan harici verilere referanslar (URI'ler) ve checksum'ları.
• actions — ajanın gerçekleştirdiği eylemlerin zaman damgaları, araç tanımlayıcıları ve sonuçlarıyla birlikte sıralı listesi (araç adı, sürüm, çıkış kodu, dönen veri hash'i).
• external_calls — hedef, URL host'u, istek hash'i, yanıt hash'i ve gecikme süreleri ile her bir giden API çağrısı.
• human_principal — ajanı veya isteği oluşturan/onaylayan kişi (kullanıcı id'si, rol ve delege iddiası).
• authorization_context — politika id'si, izin verilen kapsamlar, sona erme ve eylemi onay akışına bağlayan onay jetonu veya denetim id'si.
• outcome — nihai durum veya yan etkiler: yazılan dosyalar, çalıştırılan komutlar, ağ değişiklikleri; nesne id'leri ve checksum'ları dahil edin.
• evidence_hash — tahrif tespitinde kullanılan tam kayıt yükünün digest'i (ayrı saklayın veya imzalayın; imzalama bölümüne bakın).
• p2p_or_relay — oturumun peer-to-peer mi yoksa bir relay üzerinden mi yönlendirildiği ve relay ise bölge ve relay id'si.
• log_integrity — logları imzalarsanız imza meta verisi (anahtar id'si, imza algoritması, imza).

Bu alanlar çekirdeği oluşturur. Risk ve düzenlemeye bağlı olarak birkaç öğe daha ekleyin: container runtime id, kernel/hypervisor sürümleri, donanım TPM attestation id'si, TLS için kullanılan sertifika seri numaraları ve herhangi bir veri seti kaynak gösterimi (provenance) işaretleri.

Örnek denetim girişi

{
  "record_id": "b3f8a1d2-2e8f-4a5b-9a0f-7c6d2f3a1b2c",
  "timestamp": "2026-09-11T14:23:05Z",
  "session_seq": 42,
  "agent_id": "invoice_processor_v2",
  "agent_version": "git+sha:8b7f3c2",
  "model_name": "gpt-like-3b",
  "model_digest": "sha256:0f3a...",
  "runtime_config": {"temperature":0.2,"top_p":0.9,"seed":123456789},
  "prompt_template_id": "tmpl-invoice-2026-v3",
  "prompt_hash": "sha256:abcd...",
  "human_principal": {"user_id":"alice@corp.example","approval_id":"apr-2026-019"},
  "actions": [
    {"t":"2026-09-11T14:23:06Z","tool":"ocr:1.4.0","result_hash":"sha256:1111..."},
    {"t":"2026-09-11T14:23:10Z","tool":"bank_api:2.0","endpoint":"payments/verify","response_hash":"sha256:2222..."}
  ],
  "outcome": {"invoices_processed":3,"files_created":["s3://legal/inv-345.pdf"]},
  "p2p_or_relay": "relay",
  "relay_id": "relay-eu-2",
  "evidence_hash": "sha256:ffff...",
  "log_integrity": {"sig_kid":"logs-prod-2026","sig":"MEUCIQD..."}
}

Yukarıdaki örnek, yeniden üretilebilirlik (model_digest, prompt_hash, runtime_config) ile gizliliği (prompt'un hash olarak saklanması) dengeler. Yasal nedenlerle tam prompt'ları saklamanız gerekirse, erişimi kısıtlayın ve ham prompt'un her okunmasını ayrı olarak kaydedin.

Değiştirilemezlik, imzalama ve saklama politikaları

Denetçiler ve olay müdahale ekipleri logların tahrif edilmediğine güvenmelidir. İki pratik önlem:

• Sadece ekleme yapılabilen depolama ve değiştirilemez anlık görüntüler (sürümlemeli/WORM nesne depolama veya tek yazımlık dosya sistemleri). Soğuk yedeği farklı bir bölgede saklayın.
• Log imzalama: her kayıt için bir evidence_hash hesaplayın ve bunu özel bir log-imzalama anahtarıyla imzalayın. Anahtarları zamanında döndürün ve doğrulama için eski açık anahtarları saklayın. Kayıt içinde imza meta verilerini (anahtar id'si, algoritma ve son kullanma) ekleyin.

Saklama: operasyon ekipleri genellikle hata ayıklama için yüksek doğruluklu denetim loglarını 90 gün çevrimiçi tutar, uyumluluk için indekslenmiş meta veriyi 1 yıl saklar ve imzalanmış değiştirilemez arşivleri düzenlemeye bağlı olarak 1–7 yıl tutar. Saklama süresini hukuk müşavirinizle belirleyin — doğru süre sektöre göre değişir: finans ve sağlık genellikle birden fazla yıla uzanır.

Gizlilik, redaksiyon ve erişim kontrolleri

Agent'ların denetim logları sırlar içerebilir: API anahtarları, PII, taranmış belgeler, veya sözleşmeye dayalı veriler. Yeniden üretilebilirlik için gerekli olanı ve fazlasını kaydetmeyin. Pratik kontroller:

• Redaksiyon politikası: hassas girdilerin hash'lerini (prompt_hash, file_hash) saklayın ve düz metni bir olay sırasında ve yalnızca denetlenebilir bir onay akışı ile erişilebilir olan korumalı bir kasaya taşıyın.
• En az ayrıcalık ilkesi: log yazma, ham log okuma ve imza doğrulama için ayrı roller. Ham logların her okunması ayrıca denetlenmelidir.
• Onay ve eşleme: bir ajan bir kullanıcı adına hareket ediyorsa, eylemleri insan ilkeye atfedebilmeniz için net bir bağ (delege jetonu, zaman damgalı onay) tutun; bu, yasal ve GDPR amaçları için gereklidir.

GDPR ve diğer gizlilik kanunları, kişisel veri içeren logları kişisel veri olarak ele alır; minimizasyon, amaç sınırlaması ve saklama için hukuki dayanaklar konusunda hukuk müşavirine danışın. Şüphe durumunda, düz metni hash'leyin veya redakte edin ve redakte edilmemiş materyale yapılan erişimleri kaydedin.

Neden model ve runtime ayrıntılarını yakalamalısınız (isteğe bağlı meta veri değil)

Aynı prompt ile yapılan iki ajan çalıştırması model sürümü, temperature, seed veya araç zinciri farklıysa ayrışabilir. Olay yeniden kurgulama için şunlara ihtiyacınız var:

• Model tanımlayıcısı ve digest — sadece barındırılan modelin sürüm dizesi kırılgan olabilir; bir checksum veya değiştirilemez sağlayıcı sürümü daha iyidir.
• Ajan kodu commit'i veya image digest — ajan kodunda oluşan bir hata, davranışı prompt'tan daha fazla değiştirebilir.
• Runtime parametreleri ve seed — belirli bir çıktıyı yeniden üretmek veya yeniden üretimin deterministik modda mümkün olup olmadığını bilmek için.
• Araç sürümleri ve yanıtlar — bir aracın farklı veriler döndürmesi sonuçları değiştirir; yanıt hash'lerini ve endpoint'leri saklayın.

Bu alanlar olmadan bir ajanın ne yaptığını veya neden yaptığını güvenilir şekilde söyleyemezsiniz.

Operasyonel kontroller: uyarılar, örnekleme ve adli mod

Her şeyi tam fideliteyle loglamak pahalı ve riskli olabilir. Katmanlı bir strateji benimseyin:

• Varsayılan örnekleme: her çalıştırma için tam meta verileri (hash'ler, model adları, eylem listesi) saklayın, ancak tam prompt'ları ve araç yanıtlarını yalnızca çalıştırma bir tetikleyici (yüksek riskli eylem, kullanıcı şikayeti, politika ihlali puanı) karşılıyorsa saklayın.
• Adli mod: uyarılarda (başarısız politika kontrolü, dış şikayet) tüm ham materyalleri mühürlenmiş, erişim kontrollü bir adli depoya alın ve araştırmacılar için değiştirilemez imzalı bir anlık görüntü oluşturun.
• Gerçek zamanlı uyarılar: yüksek riskli eylemler (banka transferleri, ayrıcalıklı komutlar) için kurallar oluşturun ve yan etki gerçekleşmeden önce otomatik onaylar veya insan-kontrolü blokları üretin.

Altyapı seçenekleri: yönetilen relay vs kendi kendine barındırma

Denetim kayıtlarının nerede saklandığı ve iletildiği önemlidir. Uzaktan erişim ve ajan araçları için Tenvo'nun yönetilen relay'i çoğu ekip için varsayılan öneridir: Windows/macOS/Linux için yerel istemciler, herkese açık beta'da bir tarayıcı istemcisi ve yerleşik kayıt ve saklama katmanlarına sahip çok bölgeli yönetilen relay sağlar (Free $0 / Lite $2.99/mo / Pro $7.99/mo). Yönetilen relay'i kullanmak sertifika yenileme, relay ölçekleme, nöbetçi yamalama ve bölge çapı yedeklemelerini sizin yerinize üstlenir.

Önemli relay uyarısı: bir oturum relay'e düşerse TLS relay'de sonlanır, yani relay'i işleten kişi/kuruluş oturumu görme konumunda olur. Bu nedenle relay'de barındırılan logları relay işletmecisi tarafından görülebilir olarak değerlendirmelisiniz. Gereksiniminiz üçüncü taraf altyapının oturum yüklerine erişmesini kesinlikle yasaklıyorsa (ör. belirli uyumluluk veya veri-residency kısıtları), kendi kendine barındırma doğru seçimdir.

Kendi kendine barındırma yalnızca yazılı bir gereksiniminiz olduğunda mantıklıdır: üçüncü taraf relay'leri yasaklayan düzenleyici zorunluluklar, dışa çıkışı olmayan izole ağlar veya katı veri-residency kuralları. Kendi barındırma maliyet getirir: nöbetçi, yamalama, anahtar saklama, sertifika yenileme ve otomatik çok bölgeli failover yoksa bunu siz kurmalısınız — işletme maliyetlerini hesaba katarsanız yönetilen relay daha ucuzdur.

Denetim kaydı erişim modeli ve olay müdahalesi

Kimlerin loglarla ne yapabileceğini ihtiyaç ortaya çıkmadan önce tasarlayın. Asgari kontroller:

• Ajanlar için yazma-yönelimli: ajan servisleri loglara ekleme yapar ancak ham logları okuyamaz.
• Ayırılmış okuma rolleri: analistler meta verileri okuyabilir; araştırmacıların ham materyalleri açmak için daha yüksek ayrıcalığa ihtiyacı vardır ve her açma işlemi ayrıca kaydedilir ve imzalanır.
• Otomatik teyitler: bir araştırmacı mühürlü verilere eriştiğinde, araştırmacının kimliğini, zamanı ve amacı ilişkilendiren imzalı bir teyit kaydı oluşturun.

Olay sırasında, nedensel zinciri hızlıca yeniden oluşturmanız gerekecektir. Loglarınız model_digest, agent_version, prompt_hash, eylem listesi ve dış çağrı hash'lerini içeriyorsa genellikle kök nedeni günler yerine saatler içinde belirleyebilirsiniz.

Başlarken kontrol listesi (pratik adımlar)

• Agent denetim kaydınız için bir JSON şeması tanımlayın ve yazma zamanında bunu zorunlu kılın. Önceki listede yer alan alanları dahil edin.
• evidence_hash uygulayın ve her kaydı bir log-imzalama anahtarı ile imzalayın; denetçiler için genel anahtarları keşfedilebilir bir anahtar kümesinde saklayın.
• Saklama süresini belirleyin: tam kayıtlar için 90 gün çevrimiçi; 1–7 yıl arası arşiv, düzenlemeye bağlı olarak.
• Redaksiyon kuralları oluşturun: hangi verilerin hash'leneceği vs düz metin olarak saklanacağı ve kimin düz metne erişebileceği.
• Yüksek riskli eylemler için gerçek zamanlı politika kontrolleri ve otomatik onaylar ekleyin.
• Haftalık yeniden üretilebilirlik testleri çalıştırın: bir örnek giriş seçin ve kaydedilmiş model, seed ve konfigürasyonla ajan çıktısını yeniden üretebildiğinizi doğrulayın.

Zaten Tenvo ile uzaktan masaüstü veya ajan araçları kullanıyorsanız, etkileşimli oturumlardaki kayıt desenleri için Uyumlu Uzaktan Masaüstü Denetim Kaydı İzleme Tasarımı'nı inceleyin ve ajanlara özgü onay akışları için ai agent remote desktop: politikalar, onaylar, denetim'e danışın. Ajanların uzak araçlara nasıl entegre olduğuna daha geniş bir bakış için AI ve uzaktan masaüstü: ajanların uzak araçları nasıl kullandığı'na bakın.

Küçük başlayın: şemayı uygulayın, imzalamayı zorunlu kılın ve redaksiyon üzerinde yineleyin. Sonuç: daha hızlı olay müdahalesi, denetlenebilir yetki devri ve savunulabilir bir uyumluluk duruşu.

Tenvo'yu indirerek loglama ve yönetilen relay davranışını yerel ortamda test edin ve relay'imizin, fiyatlandırma katmanlarımızın (Free $0 / Lite $2.99/mo / Pro $7.99/mo) ve çok bölgeli relay'lerin operasyonları nasıl basitleştirdiğini görün: İndir.