Greenlight Console: Operasi Tulis Lewat Izin Manusia

Masalahnya

Agen yang bisa memanggil tool berarti agen yang bisa mengubah data. Begitu sebuah agen diberi akses ke operasi tulis — refund, perubahan pesanan, pembaruan pelanggan — pertanyaan sebenarnya bukan lagi “apakah modelnya cukup pintar”, melainkan “siapa yang menyetujui tulisannya, dan di mana buktinya?”. Kebanyakan konsol chat untuk agen menjawabnya dengan tidak menjawab: tool call disembunyikan di balik teks final.

Yang kami bangun

Konsol chat streaming untuk agen MCP, sisi klien dari server mcp-guarded-tools. Agen bekerja lewat empat meta-tool terjaga — search_tools, describe_tool, invoke_tool, confirm_action — dan setiap pemanggilan tool dirender sebagai kartu yang bisa diperiksa: argumen persisnya, hasil mentahnya, latensinya, dan guardrail mana yang berjalan.

Saat agen mencoba operasi tulis, rantai guardrail menolaknya dengan CONFIRMATION_REQUIRED dan kartu persetujuan menggantikan composer secara fisik — operator tidak bisa mengetik melewatinya; Approve dan Deny adalah satu-satunya jalan keluar. Satu klik Approve mencetak token sekali-pakai yang terikat pada argumen lewat confirm_action, dan loop yang terjeda dilanjutkan. Halaman /audit menampilkan log JSONL append-only dari server, dengan chip redaksi PII pada argumen yang mengandung data pribadi.

Keputusan rekayasa

Timeout persetujuan fail-closed. Persetujuan yang tidak dijawab diperlakukan sebagai penolakan; keheningan tidak pernah mengeksekusi tulisan.

Provenance dibaca dari warna permukaan. Pesan manusia putih, teks agen mint, plumbing tool abu-abu backstage, status terblokir amber — kepenulisan terbaca sekilas tanpa label, dan setiap status berwarna selalu ditemani glyph atau teks.

Loop agen agnostik terhadap provider. Provider default adalah mock skripted yang deterministik, sehingga seluruh konsol — termasuk skenario refund yang memicu gerbang — berjalan offline tanpa API key. Provider live (DeepSeek) opsional.

Hasil yang diukur

Dua bench offline berjalan melawan server sungguhan yang di-spawn. Bench token menunjukkan hasil yang campur dan dibiarkan campur: pada skenario baca, facade empat meta-tool menang telak (2.382 vs 6.360 token prompt kumulatif); pada skenario refund ia justru kalah (7.179 vs 6.380) karena discovery, penolakan, dan retry menambah empat ronde yang ikut terbayar ulang. Bench TTFT menunjukkan latensi plumbing dalam milidetik satu digit (p50 2,6–4,9 ms) — di mode live angka itu hilang di bawah latensi model; intinya lapisan governance bukan tempat waktu dihabiskan. Keduanya angka demonstrasi dari mock provider, bukan pengukuran produksi.

Menjalankannya

npm ci && npm run demo, buka http://localhost:3000 — enam puluh detik, tanpa key, tanpa database. Klik chip skenario refund, perhatikan agen menemukan tool lalu tertahan di gerbang, lalu setujui atau tolak. Bench-nya direproduksi dengan npm run bench:tokens dan npm run bench:ttft.