Sean Blanchfield, Co-Founder dan CEO Jentic – Seri Wawancara

Sean Blanchfield, Co-Founder dan CEO Jentic, adalah seorang wirausahawan teknologi serial dengan pengalaman dekade membangun perusahaan perangkat lunak dan infrastruktur skala besar. Berbasis di Dublin, ia saat ini memimpin Jentic sambil juga menjabat di Dewan Penasihat AI Irlandia, memberikan saran kepada pemerintah tentang kebijakan kecerdasan buatan. Sebelumnya dalam karirnya, ia co-founder DemonWare, sebuah platform layanan online skala tinggi untuk penerbit permainan video besar yang kemudian diakuisisi oleh Activision Blizzard (ATVI ), dan PageFair, sebuah startup yang didukung ventura yang fokus pada analitik pemblokiran iklan yang diakuisisi oleh Blockthrough. Ia juga telah mendirikan atau memimpin beberapa startup dan terus mendukung ekosistem startup Irlandia melalui inisiatif seperti Techpreneurs.

Jentic sedang mengembangkan lapisan integrasi universal yang dirancang untuk membantu agen AI berinteraksi dengan sistem dan API perusahaan secara aman. Platform ini memungkinkan organisasi untuk menghubungkan model AI dengan alat internal, layanan eksternal, dan alur kerja operasional sambil mempertahankan tata kelola, autentikasi, dan pengawasan. Dengan mengubah API yang terfragmentasi menjadi antarmuka terstruktur yang dapat digunakan agen AI dengan andal, Jentic bertujuan untuk membantu perusahaan mengirimkan otomatisasi yang didorong AI pada skala besar di seluruh lingkungan perangkat lunak yang kompleks.

Anda telah mendirikan dan memimpin beberapa perusahaan teknologi, dari DemonWare (diakuisisi oleh Activision Blizzard) hingga PageFair dan sekarang Jentic, dan Anda juga menjabat di Dewan Penasihat AI Irlandia. Apa yang membuat Anda kembali membangun di lapisan infrastruktur lagi dengan Jentic, dan apa celah yang Anda lihat di ekosistem agen AI yang muncul yang tidak dilihat oleh orang lain?

Ketika Anda melihat pola untuk ketiga kalinya, Anda harus mengambilnya serius. Di DemonWare, semua orang berbicara tentang multiplayer online – tetapi masalah yang sulit adalah infrastruktur jaringan di bawahnya. Hal yang sama terjadi dengan agen AI. Modelnya luar biasa. Bottlenecknya adalah lapisan integrasi – selalu ada. Agen AI berjalan pada API, dan API tersebut dibangun untuk manusia: didokumentasikan untuk manusia, diamankan untuk manusia, dan diatur untuk manusia. Arahkan agen otonom ke infrastruktur itu, dan itu akan hancur dengan cepat. Pilot AI perusahaan tidak gagal karena model salah mengerti tugas; mereka gagal karena agen tidak dapat terhubung dengan andal ke sistem yang dibutuhkan. AI generatif menawarkan cara baru untuk memecahkan masalah ini – dengan mengobati integrasi sebagai masalah pengetahuan, bukan masalah pengkodean. Wawasan itu menarik saya.

Ketika Anda memulai Jentic pada 2024, apakah keamanan agen merupakan tesis utama dari hari pertama, atau apakah fokusnya menjadi lebih tajam ketika Anda mengamati bagaimana organisasi sebenarnya mengirimkan agen otonom di produksi?

Benang pertama yang saya tarik adalah kredensial. Saya membayangkan agen berkembang biak, masing-masing membutuhkan kredensial untuk puluhan sistem, semua rahasia itu mengalir ke jendela konteks LLM, dicuri – kekacauan panas. Jawabannya sama seperti yang akan saya lakukan dua puluh tahun yang lalu: sentralisasi autentikasi dan otorisasi. Tetapi menarik benang itu langsung ke masalah berikutnya: jika Anda sentralisasi menggunakan alat integrasi tradisional, Anda kembali ke tanah konektor statis, dan agen tidak statis. Apa yang membentuk visi adalah menyadari bahwa penemuan kemampuan harus dikaitkan erat dengan kontrol akses – bahwa agen hanya harus diberikan kemampuan jika benar-benar berwenang untuk menggunakannya, dan bahwa sistem yang menyediakan penemuan juga dapat menjadi titik tunggal penegakan dan pengawasan.

Penyebaran besar-besaran contoh agen internet yang menghadap ke luar telah menyoroti bagaimana orkestrasi dan kredensial sering berbagi batas kepercayaan yang sama. Dari perspektif Anda, apa inti kesalahan arsitektur dalam model tersebut?

Kesalahan itu sederhana: agen – sistem yang menjalankan prompt dari LLM – juga sistem yang memegang kredensial dan membuat panggilan API. Kompromi agen dan Anda mendapatkan semua yang bisa dilakukan. Ini adalah kesalahan yang sama yang kita buat di era web awal – server aplikasi dengan akses database superuser karena itu nyaman. Jentic duduk sebagai lapisan di antara agen dan API yang dipanggil. Agen tidak pernah memegang kredensial. Ini mengeluarkan permintaan melalui lapisan eksekusi yang dikelola, yang menyuntikkan kredensial sisi server, menegakkan kebijakan, dan mencatat setiap panggilan. Dan ketika sesuatu salah, ada satu tombol bunuh – satu tindakan berhenti akses agen tersebut ke semua sistem terhubung secara bersamaan.

Anda telah berbicara tentang memisahkan orkestrasi dari eksekusi untuk mengandung radius ledakan. Bisakah Anda menjelaskan dalam istilah praktis bagaimana pemisahan itu mengubah profil risiko ketika instance dikompromikan?

Dalam model datar, LLM beralasan tentang apa yang harus dilakukan dan langsung memanggil API menggunakan kredensial yang dimilikinya. Kompromi lapisan penalaran, dan Anda mengontrol lapisan eksekusi. Dengan pemisahan, LLM mengeluarkan niat – “panggil API billing Stripe dengan parameter ini” – lapisan eksekusi yang dikelola memvalidasi permintaan tersebut terhadap kebijakan, menyuntikkan kredensial sisi server, dan membuat panggilan. LLM tidak pernah menyentuh kredensial. Dalam praktiknya: pergerakan lateral menjadi lebih sulit, radius ledakan dibatasi oleh apa yang lapisan eksekusi izinkan untuk identitas agen tertentu, dan Anda mendapatkan tombol bunuh. Satu toggle dan akses agen berhenti di semua sistem terhubung. Agen masih dapat dimanipulasi – tetapi manipulasi tidak secara otomatis berarti kompromi kredensial penuh.

Dalam penerapan perusahaan dunia nyata, apa yang terlihat seperti manajemen kredensial terpusat dan pencabutan instan, dan bagaimana hal itu berbeda dari cara tim saat ini menangani kunci API dan token untuk agen?

Hari ini, sebagian besar tim memiliki pengembang yang menyediakan kunci API, menyimpannya dalam file .env, dan memuatnya saat startup agen – sering langsung ke jendela konteks LLM. Tidak ada yang memiliki gambaran lengkap tentang agen mana yang memegang kredensial mana. Ketika seseorang meninggalkan, kunci yang disediakan tidak diputar. Ketika agen berperilaku aneh, tidak ada jejak audit untuk merekonstruksi apa yang terjadi. Dengan Jentic, pengembang tidak pernah menangani kredensial mentah. Mereka menyatakan akses apa yang dibutuhkan agen, platform menyediakan akses terbatas, dan agen memanggil melalui lapisan eksekusi tanpa pernah melihat kunci dasar. Itu berarti Anda mendapatkan pencabutan per agen instan, kemampuan untuk menghentikan akses sementara Anda menyelidiki, dan jejak audit waktu yang mencatat setiap panggilan API. Perbedaan antara itu dan “kunci API di file .env” sangat substansial.

Banyak tim bereksperimen dengan kerangka agen di penjualan, teknik, dan ilmu data. Apa kesalahan keamanan paling umum yang Anda lihat ketika organisasi berpindah dari eksperimen ke produksi?

Polanya berulang: agen yang berwenang berlebihan masih berjalan pada kredensial admin yang mereka prototipkan; kredensial yang dilewatkan dalam prompt atau jendela konteks di mana mereka berakhir di log, telemetri, dan potensi data pelatihan; kredensial yang dibagikan di seluruh contoh agen sehingga Anda tidak dapat mengisolasi aktor jahat tunggal; tidak ada tombol bunuh untuk menghentikan agen tanpa menurunkan sistem yang lebih luas; tidak ada jejak audit yang layak; dan injeksi prompt tidak dianggap serius – bahkan jika agen membaca email, memproses dokumen, atau menjelajahi web, mereka akan menemukan konten yang dibuat lawan. Benang umum adalah bahwa tim-tim ini membangun untuk jalur bahagia dan sekarang menemukan bahwa produksi sebagian besar adalah jalur tidak bahagia.

Jentic memposisikan diri sebagai lapisan eksekusi yang dikelola yang duduk di antara kerangka agen dan sistem eksternal. Bagaimana lapisan perantara tersebut menegakkan tata kelola tanpa memperlambat pengembang atau mengurangi fleksibilitas agen?

Bukannya menghubungkan agen ke lima puluh API yang berbeda – masing-masing dengan skema autentikasi, batasan tarif, dan kekhasan sendiri – pengembang terhubung ke satu endpoint. Endpoint itu mengekspos alat untuk mencari katalog kemampuan API kami, memuat detail, dan mengeksekusi panggilan apa pun. Ini memaksimalkan fleksibilitas melalui antarmuka unifikasi tunggal ke API tak terbatas, sambil memungkinkan tata kelola – agen mana yang mengakses API mana, di bawah kondisi apa, dengan batasan apa – semua dikelola di platform, bukan di kode klien. Lapisan eksekusi adalah pass-through; agen masih dapat menggabungkan alur kerja multi-langkah, menghubungkan panggilan, dan menangani kesalahan secara dinamis. Tata kelola tanpa gesekan sulit. Jalan pintas adalah mendorong beban ke pengembang. Infrastruktur harus melakukan kebalikannya — menyerap kompleksitas sehingga pengembang tidak perlu.

Dengan malware infostealer sekarang secara aktif menargetkan file konfigurasi agen dan kredensial yang disimpan, apakah Anda melihat penyerang beralih fokus ke infrastruktur AI sebagai area permukaan nilai tinggi baru?

Tentu saja – dan logikanya jelas. File konfigurasi agen secara efektif adalah kunci super layanan multi: kredensial untuk sistem email, CRM, platform billing, API internal, dan akun GitHub. Satu pelarian infostealer yang sukses menghasilkan akses bulan-bulan ke sistem eksternal seluruh perusahaan. Itu adalah pengembalian yang jauh lebih tinggi daripada menargetkan layanan tunggal secara terisolasi. Dimensi lain adalah bahwa agen yang berjalan terus-menerus di produksi adalah kehadiran berizin dan persisten – bukan pengguna yang masuk dan keluar. Agen yang dikompromikan dapat bertindak sebagai titik pijakan jangka panjang, beroperasi di bawah ambang deteksi. Kenyataan yang tidak nyaman adalah bahwa permukaan serangan berkembang lebih cepat daripada alat pertahanan. Jentic dapat secara signifikan mengurangi permukaan serangan kredensial, tetapi kita tidak bisa mencegah agen menyalahgunakan ruang lingkup yang telah diberikan. Masalah yang lebih sulit itu perlu diselesaikan di tingkat model, dengan penghalang dan deteksi injeksi prompt.

Di luar kerangka kerja tunggal, apa prinsip keamanan yang lebih luas yang harus diadopsi organisasi jika mereka ingin mengirimkan AI agen dengan aman pada skala besar?

Sebagian besar organisasi yang dikelola tidak dapat mengirimkan sistem non-deterministik ke proses bisnis yang paling berharga. Bank atau asuransi tidak bisa menunjuk agen otonom ke sistem billing mereka dan mengatakan “pergi cari tahu.” Jadi bagaimana Anda berinovasi tanpa postur risiko Anda menjadi rem? Jawabannya adalah sandboxing. Buat tiruan digital dari estate API Anda dengan struktur dan alur kerja yang sama, tetapi tanpa kredensial produksi atau konsekuensi. Kirim agen di sana, biarkan mereka menjelajahi, lihat apa yang terjadi. Jalur yang sukses ditangkap sebagai otomatisasi alur kerja yang deterministik dan terstruktur menggunakan Arazzo, spesifikasi alur kerja terbuka yang dikembangkan dalam Inisiatif OpenAPI – dapat diaudit, dapat diulang, dan dapat ditinjau oleh tim kepatuhan apa pun. Ini berarti Anda dapat bergerak dengan kecepatan AI di sandbox dan dengan kecepatan perusahaan di produksi, dan kedua mode tersebut coexist. Prinsip-prinsip lain masih berlaku – izin minimal, jejak audit, tombol bunuh, pemisahan orkestrasi dari eksekusi. Tetapi sandbox adalah jawaban struktural untuk pertanyaan yang sebenarnya tim perusahaan terjebak: bagaimana kita bereksperimen dengan AI non-deterministik tanpa bertaruh postur kepatuhan kita pada itu? Anda tidak mengirim non-determinisme. Anda mengekstrak nilai dari itu di bawah kondisi terkendali, dan mengirim hanya output deterministik.

Terima kasih atas wawancara yang luar biasa, pembaca yang ingin mempelajari lebih lanjut harus mengunjungi Jentic.