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 mendirikan DemonWare, sebuah platform layanan online skala besar untuk penerbit game video besar yang kemudian diakuisisi oleh Activision Blizzard, dan PageFair, sebuah startup yang didukung ventura yang fokus pada analitik pemblokiran iklan yang diakuisisi oleh Blockthrough. Ia juga 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 kecerdasan buatan berinteraksi dengan sistem perusahaan dan API secara aman. Platform ini memungkinkan organisasi untuk menghubungkan model kecerdasan buatan 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 kecerdasan buatan secara andal, Jentic bertujuan untuk membantu perusahaan mengirimkan otomatisasi yang didorong kecerdasan buatan 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 kecerdasan buatan yang muncul yang tidak dilihat 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 kecerdasan buatan. Modelnya luar biasa. Bottlenecknya adalah lapisan integrasi – selalu begitu. Agen kecerdasan buatan 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 kecerdasan buatan perusahaan tidak gagal karena model salah mengerti tugas; mereka gagal karena agen tidak bisa terhubung secara andal ke sistem yang dibutuhkan. Kecerdasan buatan 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 fokus memperjelas ketika Anda mengamati bagaimana organisasi benar-benar 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, diekstraksi – kekacauan panas. Jawabannya sama seperti yang akan saya lakukan dua puluh tahun yang lalu: sentralisasi autentikasi dan otorisasi. Tetapi menarik benang itu langsung menuju masalah berikutnya: jika Anda menyentralisasi menggunakan alat integrasi tradisional, Anda kembali ke tanah konektor statis, dan agen tidak statis. Apa yang menguatkan 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.

Paparan baru-baru ini tentang sejumlah besar contoh agen yang menghadap internet telah menyoroti bagaimana orkestrasi dan kredensial sering berbagi batas kepercayaan yang sama. Dari perspektif Anda, apa kelemahan arsitektur inti dalam model tersebut?

Kelemahan 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 server-side, menegakkan kebijakan, dan mencatat setiap panggilan. Dan ketika sesuatu salah, ada satu tombol bunuh – satu tindakan menghentikan akses agen tersebut ke semua sistem yang 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 contoh 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 server-side, dan membuat panggilan. LLM tidak pernah menyentuh kredensial. Dalam prakteknya: pergerakan lateral menjadi lebih sulit, radius ledakan dibatasi oleh apa yang diizinkan lapisan eksekusi untuk identitas agen tertentu, dan Anda mendapatkan tombol bunuh. Satu toggle dan akses agen berhenti di semua sistem yang terhubung. Agen masih bisa dimanipulasi – tetapi manipulasi tidak lagi secara otomatis berarti kompromi kredensial penuh.

Dalam penerapan perusahaan 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 signifikan.

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 memiliki hak akses terlalu banyak masih berjalan pada kredensial admin yang digunakannya saat prototipe; kredensial yang dilalui 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 bisa mengisolasi satu aktor jahat; 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 – meskipun setiap agen yang membaca email, memproses dokumen, atau menjelajahi web 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 itu menegakkan tata kelola tanpa memperlambat pengembang atau mengurangi fleksibilitas agen?

Bukannya menghubungkan agen ke lima puluh API yang berbeda – masing-masing dengan skema autentikasi, batas tarif, dan kekhasan – pengembang terhubung ke satu endpoint. Endpoint itu mengekspos alat untuk mencari katalog kemampuan API kami, memuat detail, dan mengeksekusi panggilan. Ini memaksimalkan fleksibilitas melalui antarmuka terpadu untuk API tak terbatas, sambil memungkinkan tata kelola – yang agen 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 bisa menyusun 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 sebaliknya – 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 kecerdasan buatan sebagai area permukaan baru yang berharga?

Tentu – dan logikanya jelas. File konfigurasi agen secara efektif adalah kunci super layanan: kredensial untuk sistem email, CRM, platform billing, API internal, dan akun GitHub. Satu pelarian infostealer yang sukses menghasilkan akses bulan-bulan ke seluruh sistem eksternal 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 yang bercredensial dan persisten – bukan pengguna yang masuk dan keluar. Agen yang dikompromikan dapat berfungsi sebagai 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 penjaga dan deteksi injeksi prompt.

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

Sebagian besar organisasi yang dikelola tidak bisa mengirimkan sistem non-deterministik ke proses bisnis yang paling berharga. Bank atau asuransi tidak bisa menunjuk agen otonom ke sistem billing mereka dan mengatakan “cari tahu”. Jadi bagaimana Anda berinovasi tanpa postur risiko Anda menjadi rem? Jawabannya adalah sandboxing. Buatlah kembar digital dari estate API Anda dengan struktur dan alur kerja yang sama, tetapi tanpa kredensial produksi atau konsekuensi. Kirimkan 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, diulang, dan ditinjau oleh tim kepatuhan apa pun. Ini berarti Anda bisa bergerak dengan kecepatan kecerdasan buatan di sandbox dan dengan kecepatan perusahaan di produksi, dan kedua mode tersebut koeksistensi. Prinsip-prinsip lain masih berlaku – hak akses terendah, jejak audit, tombol bunuh, pemisahan orkestrasi dari eksekusi. Tetapi sandbox adalah jawaban struktural untuk pertanyaan yang sebenarnya menghambat tim perusahaan: bagaimana kita bereksperimen dengan kecerdasan buatan non-deterministik tanpa bertaruh postur kepatuhan kita pada itu? Anda tidak mengirimkan non-determinisme. Anda mengekstrak nilai dari itu di bawah kondisi yang terkendali, dan mengirimkan hanya output deterministik.

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