Ana içeriğe geç

Agent'lar için Denetim İzleri Bir Dashboard Değil, Write-Ahead Log Problemidir

Agent hesap verebilirliği ancak her tool call, kimlik bilgisi kullanımı ve durum geçişi yürütülmeden önce kaydedildiğinde kanıtlanabilir; bu da logu bir çalışma zamanı bağımlılığı haline getirir.

Loş bir veri merkezi koridorunda üst üste dizilmiş depolama birimlerini, gösterge ışıklarını ve kabloları gösteren bir sunucu rafının yakın çekimi.

Agent gözlemlenebilirliğinde hesap verebilirlik boşluğu

Çoğu agent platformu denetimi sonradan ele alınacak bir mesele olarak görür. Trace'ler olay gerçekleştikten sonra yayınlanır, bir time-series deposuna gönderilir ve dashboard olarak görüntülenir. Bu, performans izleme için yeterlidir ve hesap verebilirlik için işe yaramaz. Bir dashboard örnekler, toplar ve downsample eder. Bu saatte kaç tool call başarısız oldu gibi soruları yanıtlar. Bu olaydan önce hangi kesin sıralı kararlar dizisi vardı ve her birini kim yetkilendirdi sorusunu yanıtlayamaz.

Yakın tarihli iki olay bu başarısızlık modunu gözler önüne seriyor. Avustralya Medicare olayı ve bildirilen Gemini bağlantılı ihlaller, her ikisi de kısmi telemetriden — dağınık uygulama logları, sağlayıcı tarafı kayıtlar ve elle birleştirilmesi gereken inference trace'leri — sonradan yeniden inşa edildi. Hiçbir durumda sistemin kendisi, agent'ın ne yapmayı amaçladığına ve ne yapmaya yetkili olduğuna dair eksiksiz, sıralı ve kurcalandığı kanıtlanabilir bir kayıt tutmuyordu. Yeniden inşa, adli arkeolojiydi ve vardığı sonuçlar ancak dolduramadığı boşluklar kadar güvenilirdi.

Daha derin sorun yapısaldır. Tanımladığı sürecin kendisi tarafından düzenlenebilen bir denetim kaydı kanıt değildir. Agent çalışma zamanı kendi logu üzerinde yazma yetkisini elinde tutuyorsa, o çalışma zamanındaki herhangi bir ihlal — prompt injection, dependency confusion, kötü niyetli bir tool — kendisini suçlayacak girdileri bastırabilir, yeniden sıralayabilir veya yeniden yazabilir. Bu şekilde kurulan gözlemlenebilirlik hatları, hesap verebilirlik açısından, öz bildirimdir. Hata ayıklama için faydalıdır ve bir anlaşmazlıkta değersizdir.

Agent çalıştırmaları için write-ahead semantiği

Write-ahead logging'in depolama motorlarında bu soruna yerleşik bir yanıtı vardır: niyet, etki uygulanmadan önce kalıcı olarak kaydedilir. Aynı disiplin agent'lar için de geçerlidir ve logu bir çıktıdan bir ön koşula dönüştürür.

Uyumlu bir agent çalıştırması, herhangi bir yan etki tetiklenmeden önce sırasıyla şunları ekler:

  1. Amaçlanan eylem — tool adı, kanonikleştirilmiş argümanlar, hedef kaynak.
  2. Yetkilendiren politika kararı — hangi kuralın eşleştiği, çalıştırmayı hangi principal'ın başlattığı, hangi kısıtların uygulandığı.
  3. Çözümlenen kimlik bilgisi — tool'un hangi kimlik olarak hareket edeceği ve o kimliğin kapsamı.

Close-up of a modern building facade with red steel beams in geometric patterns against a blue sky

Tool call ancak ekleme onaylandıktan sonra yürütülür. Dolayısıyla log bir çalışma zamanı bağımlılığıdır: log yazıcısı kullanılamıyorsa eylem ilerlemez. Dürüst ödünleşim budur. Write-ahead denetimi benimseyen ekipler, bir log kesintisinin bir yetenek kesintisi haline geldiğini kabul eder. Alternatif — asla bloklamayan best-effort logging — tam da yukarıdaki yeniden inşaları üreten rejimdir.

Log aynı zamanda kurtarma noktası haline gelir. Çökme, kill veya timeout durumunda, kaydedilen trajectory'nin replay'i bir eylemin yeniden denenip denenmeyeceğine, geri alınıp alınmayacağına veya karantinaya alınıp alınmayacağına karar verir. Niyet yürütmeden önce kaydedildiği için, kurtarma süreci hiç başlamadı ile başladı ve sonucu bilinmiyor arasında ayrım yapabilir; bu, idempotency ve telafi mantığı için önemli olan ayrımdır. Bu olmadan, yeniden denemeler yan etkileri çoğaltır ve geri almalar onları kaçırır.

Son olarak, yazıcı agent sürecinden ayrılmalıdır. Yaygın bir desen, farklı bir kimlik altında çalışan, kimliği doğrulanmış bir kanal üzerinden eklemeleri kabul eden ve tek yazma kimlik bilgisini elinde tutan bir log servisidir. Agent süreci, kendi run tanımlayıcısıyla sınırlı, yalnızca ekleme yapabilen bir yetenek tutar; silemez, değiştiremez veya çalıştırmalar arasında okuyamaz. İhlal edilmiş bir agent o zaman harekete geçmeyi reddedebilir, ancak zaten beyan ettiğini silemez.

Kaydın içermesi gerekenler

Tek bir ekleme girdisi için minimal şema:

{
  "seq": 41822,
  "run_id": "run_7f3a...",
  "parent_step": 41819,
  "ts_monotonic": 918273645,
  "kind": "tool.intent",
  "tool": "http.fetch",
  "args_hash": "sha256:9c1f...",
  "policy_rule": "net.egress.allowlist.v4",
  "credential": "svc-fetch-readonly@proj-9",
  "context_refs": ["doc_31a", "doc_88b"]
}

Birkaç alan orantısız ağırlık taşır.

Argümanlar değil, argüman hash'i. Hash'leme, sırları logun dışında tutarken girdiyi yine de tam girdiye bağlar. Argümanların replay için kurtarılabilir olması gerektiğinde, bunları aynı hash ilClose-up of stacked rusty industrial pipes showing corrosion and texturesaklayın.

Circuit board macro

Parent step. Agent çalıştırmaları çizgiler değil, ağaçlardır. Her eylemi talep eden parent step'i kaydetmek, bir subagent'ın davranışını onu doğuran delegasyona atfetmeyi mümkün kılan şeydir. Parentage olmadan, bir swarm'ın eylemleri ayrıştırılamayan bir akışa dönüşür.

Alınan bağlam için provenance. Bağlam penceresine giren her belge, snippet veya tool sonucu tanımlayıcı ve içerik hash'i ile referans verilmelidir. Bu, zehirlenmiş bir belgenin onu tüketen her çalıştırmaya ileriye doğru ve onu kabul eden ingestion yoluna geriye doğru izlenmesini sağlayan şeydir. Provenance olmadan retrieval, bir injection olayını sınırsız bir soruşturmaya dönüştürür.

Deterministik saatleme ve monotonik sıra numaraları. Worker başına duvar saati zaman damgaları, dağıtık bir orchestrator genelinde sıralanamaz; saat kayması ve eşzamanlı worker'lar nedensel olarak sıralı olan olayları yeniden sıralayacaktır. Orchestrator tarafından atanan tek bir monotonik sıra, insan okuması için ikincil alan olarak duvar saati zamanıyla birlikte, replay'den sağ çıkan bir toplam sıra verir.

Operasyonel sonuçlar

Write amplification ve retention bütçe kalemleri haline gelir. Her tool call artık en az bir kalıcı ekleme, çoğu zaman birkaç tane (niyet, politika kararı, kimlik bilgisi çözümlemesi, sonuç) maliyetindedir. Yüksek frekanslı agent'larda bu, depolama ve I/O bütçesinin anlamlı bir kısmıdır ve bir gözlemlenebilirlik ödeneğinin içinde değil, inference maliyetinin yanında durur. Retention politikası bir tasarım kararı haline gelir: tam trajectory'nin ne kadar süre saklanacağı, neyin hash'lere indirgeneceği, neyin soğuk depolamaya aktarılacağı. İndirgeme zinciri asla kırmamalıdır — bir hash ancak preimage'i onu güvenilir tutan bir politika altında kurtarılabilirse faydalıdır.

İlk günden şema sürümleme. Olay incelemesi, kod değiştikten aylar sonra gerçekleşir. Log şeması sürümlenmemişse, soruşturma altındaki döneme ait girdiler mevcut araçlar tarafından okunamayabilir ve soruşturma format geçişinde tıkanır. Girdi şemasını açıkça sürümleyin, şimdiye kadar yayınlanan her sürüm için okuyucuları koruyun ve şema değişikliklerini bir API ile aynı titizlikle breaking change olarak ele alın.

Olay müdahalesi arkeolojiden replay'e kayar. Trajectory eksiksiz ve sıralı olduğunda, ne oldu sorusu kaydedilen çalıştırmayı kaydedilen kararlara karşı replay ederek yanıtlanır. İlginç iş politika neden buna izin verdi ve neyin değişmesi gerektiği noktasına kayar. Bu gerçek bir iyileşmedir ve aynı zamanda çıtayı yükseltir: agent'larını kesin olarak replay edebilen bir organizasyon artık olayları eksik görünürlüğe atfedemez.

Görüş

Agent'lar için denetim izleri bir write-ahead log problemidir. Log, yürütmeden önce eklenmeli, agent'ın etkileyemeyeceği bir süreç tarafından yazılmalı, orchestrator tarafından sıralanmalı ve henüz var olmayan okuyucular için sürümlenmelidir. Dashboard'lar operasyonlar için faydalı olmaya devam eder; kanıt değildirler. Bu ayrımı içselleştiren ekipler, agent'larının ne yaptığını kanıtlayabilecek. İçselleştirmeyenler ise hayatta kalan telemetriden yeniden inşa etmeye devam edecek.

İlgili okumalar

Bunun yanıtladığı sorular

Why can't existing observability dashboards serve as an audit trail?

Dashboards sample, aggregate and downsample telemetry, so they cannot reconstruct the exact ordered sequence of decisions that preceded an incident. They are also typically written by the same process they describe, which means a compromised agent can suppress or rewrite its own entries. Audit requires an append-only record written before execution by a separate process.

What does write-ahead logging change about agent runtime behaviour?

The log becomes a runtime dependency. The intended action, the authorising policy decision and the resolved credential are appended durably before any side effect fires. If the log writer is unavailable, the action does not proceed. On crash or kill, replay of the recorded trajectory decides whether the action is retried, rolled back or quarantined.

What is the minimum content of an agent audit entry?

Tool name, argument hash, the policy rule that matched, the credential identity the tool will act as, and the parent step that requested the action. Retrieved context should be referenced by identifier and content hash so a poisoned document can be traced to every run that consumed it. Ordering should come from orchestrator-assigned monotonic sequence numbers rather than per-worker wall-clock timestamps.

What are the main costs of adopting write-ahead auditing for agents?

Write amplification and retention become first-class budget lines alongside inference, and a log outage becomes a capability outage because actions are blocked until the append is acknowledged. Log schemas also need explicit versioning from the start, since incident review often happens months after the code changed.