Refael Angel, Co-Founder dan CTO Akeyless – Seri Wawancara

Refael Angel, Co-Founder dan CTO Akeyless, adalah seorang pemimpin keamanan siber dan rekayasa perangkat lunak dengan pengalaman mendalam dalam keamanan cloud, enkripsi, autentikasi mesin, dan infrastruktur perusahaan. Sejak menjadi co-founder Akeyless pada 2018, ia telah membantu membangun perusahaan di sekitar manajemen rahasia modern dan keamanan identitas untuk lingkungan cloud-native. Sebelum Akeyless, ia bekerja sebagai Insinyur Perangkat Lunak Senior di Keamanan di Intuit (INTU ), di mana ia membangun sistem untuk pengelolaan kunci enkripsi cloud publik dan autentikasi mesin, memperoleh pengalaman tangan pertama di seluruh AWS, Go, Python, Java, PHP, Bash, Linux, Git, dan Jenkins. Pada awal karirnya, Angel memegang peran rekayasa perangkat lunak di 3D Systems (DDD ) dan Cimatron, mengembangkan aplikasi CAD/CAM dan berbasis Windows menggunakan C/C++, C#, WPF, MFC, dan pola desain berorientasi objek.

Akeyless adalah perusahaan keamanan identitas yang fokus pada mengamankan mesin, agen AI, dan manusia melalui platform cloud-native yang dibangun di sekitar kriptografi zero-knowledge. Platformnya menggabungkan manajemen rahasia, pengelolaan kunci enkripsi, manajemen siklus hidup sertifikat, akses istimewa, dan keamanan identitas mesin, memberikan organisasi cara yang terunifikasi untuk mengelola kredensial, kunci, sertifikat, dan akses di seluruh lingkungan hybrid, multi-cloud, DevOps, dan AI. Posisi perusahaan mencerminkan pergeseran yang lebih luas dalam keamanan siber: karena beban kerja, layanan, dan agen AI semakin banyak melakukan akses sistem tanpa keterlibatan manusia langsung, perusahaan memerlukan kontrol yang lebih kuat di sekitar identitas non-manusia, kredensial dengan masa hidup singkat, rotasi otomatis, dan tata kelola runtime.

Anda co-founder Akeyless pada 2018 setelah membangun sistem pengelolaan kunci enkripsi dan autentikasi mesin di Intuit. Apa celah dalam keamanan cloud dan manajemen identitas yang membuat Anda yakin bahwa sudah waktunya untuk memulai Akeyless, dan bagaimana visi asli itu telah berkembang seiring munculnya agen AI sebagai kelas identitas digital baru?

Di Intuit, saya adalah bagian dari tim yang membangun sistem pengelolaan kunci enkripsi dan autentikasi mesin pada saat Intuit adalah salah satu perusahaan besar pertama yang pindah ke cloud. Apa yang menjadi jelas bagi saya adalah bahwa setiap organisasi yang mengadopsi cloud akan menghadapi masalah yang sama yang kami pecahkan secara internal: bagaimana mengelola rahasia dan kunci di seluruh infrastruktur yang terdistribusi dan dinamis. Membangun ini secara in-house menghabiskan sumber daya rekayasa yang sangat besar, dan tidak masuk akal bagi setiap perusahaan untuk merekayasa ulang. Jawaban logisnya adalah model SaaS.

Sangkutannya adalah kepercayaan. Ini adalah materi paling sensitif yang dimiliki perusahaan, dan tidak ada organisasi serius yang akan menyerahkan pihak ketiga kemampuan untuk mengaksesnya. Jadi persyaratan itu hampir kontradiktif: menyampaikannya sebagai SaaS untuk skala dan kesederhanaan, namun membuatnya secara arsitektur mustahil bagi vendor untuk pernah melihat data pelanggan. Ketegangan itu tepatlah yang melahirkan Kriptografi Fragmen Terdistribusi (DFC). DFC memungkinkan kami menjalankan kontrol plane SaaS yang sepenuhnya dikelola sementara pelanggan memegang fragmen yang tidak pernah kami miliki, sehingga kami secara matematis tidak dapat mengakses kunci mereka. Itulah yang menjadi dasar model SaaS plus Zero-Knowledge yang Akeyless dibangun.

Visi asli adalah tentang mengamankan akses manusia dan mesin di cloud. Agen AI adalah ekstensi alami dan paling ekstrem dari masalah yang sama. Mereka adalah identitas non-manusia yang beroperasi pada skala dan kecepatan yang tidak dirancang oleh direktori mana pun, dan fondasi Zero-Knowledge yang sama, yang berfokus pada identitas, sekarang diperluas langsung ke mereka.

Anda dikenal sebagai arsitek di balik teknologi enkripsi Zero-Trust yang dipatenkan Akeyless. Apa tantangan teknis terbesar dalam membangun model keamanan yang dapat menghilangkan asumsi kepercayaan sambil tetap praktis untuk perusahaan besar?

Bagian tersulit adalah membuat “jangan percaya siapa pun” menjadi praktis daripada akademis. Sebagian besar skema kunci terbagi atau berbagi rahasia masih merakit kunci penuh pada saat tertentu, biasanya di dalam proses tunggal, HSM, atau enclave pada saat operasi kriptografi. Jendela singkat itu tepatlah yang ditargetkan oleh penyerang, insider berbahaya, dan skenario hukum.

Dengan DFC, kunci tidak pernah dirakit, tidak pada saat pembuatan, tidak pada saat istirahat, dan tidak selama penggunaan. Fragmen dihasilkan secara independen di domain kepercayaan terpisah, dan operasi kriptografi berjalan sebagai komputasi terdistribusi di mana setiap pemegang fragmen menghitung bagian lokalnya dan hanya hasil parsial yang ditukar. Tantangan rekayasa adalah mencapai ini dengan latensi, throughput, dan keandalan yang diminta oleh perusahaan besar di produksi.

Tantangan kedua, dan salah satu yang paling signifikan, adalah memungkinkan penyegaran fragmen terus-menerus. Kami harus dapat menggantikan setiap fragmen dengan nilai matematika baru, di setiap lokasi, sementara kunci master yang diwakili oleh fragmen tetap tidak berubah dan proses kriptografi tidak pernah terganggu. Ini menambahkan lapisan keamanan yang sangat besar pada solusi. Karena penyegaran, penyerang tidak dapat lagi mengumpulkan fragmen dengan sabar seiring waktu. Sebuah fragmen yang ditangkap minggu lalu adalah tidak terkait secara matematis dengan fragmen yang ada hari ini, sehingga itu adalah noise daripada awal. Untuk mempelajari sesuatu tentang kunci, penyerang harus mengompromikan setiap lokasi fragmen secara bersamaan, dalam jendela penyegaran tunggal, dan persyaratan itu tumbuh secara eksponensial lebih sulit seiring dengan peningkatan lokasi, domain kepercayaan, dan frekuensi penyegaran. Dikombinasikan dengan ambang batas all-or-nothing, di mana 100 persen fragmen diperlukan untuk mengungkapkan apa pun dan subset ketat apa pun tidak bocorkan informasi, penyegaran mengubah model keamanan dari jaminan statis menjadi jaminan terikat waktu.

Banyak organisasi berlomba untuk mengirimkan agen AI, namun keamanan identitas sering kali tetap menjadi pemikiran kedua. Apa kesalahan paling umum yang dilakukan perusahaan ketika memberikan agen AI akses ke sistem dan data perusahaan yang sensitif?

Kesalahan terbesar adalah mengobati agen seperti akun layanan dan menyerahkan kunci API statis yang berumur panjang. Kredensial itu menjadi aset yang dapat dipanen secara permanen yang duduk di dalam aktor non-deterministik dan injeksi prompt.

Kesalahan umum lain yang saya lihat: memberikan hak istimewa yang berdiri daripada akses just-in-time, mengandalkan izin berbasis peran yang kasar yang menjelaskan apa yang dapat dijangkau agen tetapi tidak pernah apa yang dimaksudkan untuk dilakukan, memberikan agen jalur jaringan langsung ke database dan API sehingga kompromi menjadi pergerakan lateral, dan tidak memiliki rantai audit yang menghubungkan tindakan agen kembali ke prompt manusia dan yang memicunya. Setiap kesalahan ini adalah upaya untuk memasang kembali kontrol era manusia ke sesuatu yang tidak berperilaku seperti manusia.

Akeyless telah berargumen bahwa agen AI memerlukan model identitas yang secara mendasar berbeda dari manusia atau beban kerja mesin tradisional. Apa yang membuat agen AI secara unik sulit untuk diamankan dibandingkan dengan kerangka kerja IAM dan PAM yang ada?

Kesalahan inti adalah mengobati agen AI sebagai jenis pengguna baru, atau bahkan jenis akun layanan baru, dan menganggap mereka dapat diaktifkan dan diperintah seperti identitas manusia. Itu adalah kesalahan kategori, karena beberapa alasan terkait.

Identitas agen tidak dapat dihitung. Instansi spesifik yang ingin Anda kelola biasanya belum ada, dan pada saat itu ada, itu sudah hilang. Sebuah agen dapat memulai di Lambda, berjalan selama 800 milidetik, dan menghilang sebelum pemindai memperhatikannya, atau memunculkan rantai agen sub di seluruh VM, kontainer, dan serverless yang selesai dalam hitungan detik. Mendaftarkan ini dalam direktori adalah mengobati hantu sebagai penghuni: pada saat entri tersebut selesai, entitas yang digambarkannya sudah hilang.

Sesuatu yang benar adalah identitas beban kerja yang sudah diterbitkan oleh runtime, peran eksekusi AWS, token akun layanan Kubernetes, OIDC federasi, dan standar seperti SPIFFE/SPIRE yang sudah terbukti dan cross-substrat. Identitas itu sudah ada, dijamin oleh platform yang agen jalankan, dan menghilang ketika agen menghilang. Karena identitasnya adalah efemeral, entitas stabil yang dapat ditulis kebijakan di antaranya adalah metode autentikasi dan sistem target, bukan identitas bernama dan cakupan.

Dan inilah di mana IAM dan PAM yang ada paling putus: RBAC dan ABAC statis tidak dapat mengandung aktor non-deterministik. Sebuah agen dengan token yang perfectly scoped dan TTL yang ditegakkan dengan sempurna masih dapat diinjeksi prompt, mengalami halusinasi query destruktif, atau berpindah dari tugas baca ke tugas tulis dalam sesi yang sama, tanpa pelanggaran kebijakan yang terlihat pada lapisan otorisasi. RBAC dan ABAC mengevaluasi pada saat autentikasi, bukan setelahnya, karena apa yang terjadi setelahnya ditentukan oleh LLM yang melihat jendela konteks yang tidak dapat dilihat oleh penulis kebijakan.

Sehingga agen secara unik sulit karena mereka adalah efemeral, non-deterministik, multi-substrat, dan dapat diinjeksi prompt secara bersamaan. Lapisan yang hilang bukanlah direktori yang lebih baik. Itu adalah penerapan intent-aware pada setiap tindakan, dimediasi oleh gerbang yang memeriksa apa yang sebenarnya dilakukan agen melawan apa yang dikatakannya akan dilakukan, sebelum kredensial apa pun diterbitkan.

Ada diskusi yang tumbuh sekitar arsitektur “tanpa rahasia” untuk sistem AI. Bagaimana Anda mendefinisikan autentikasi tanpa rahasia, dan mengapa Anda percaya bahwa kredensial statis dan kunci API menjadi tidak berkelanjutan di era agen otonom?

Autentikasi tanpa rahasia berarti agen tidak pernah memegang kredensial sama sekali. Sebagai gantinya, agen mengautentikasi melalui identitas beban kerja aslinya, dan kredensial just-in-time yang berumur singkat diinjeksi ke dalam sesi yang diperantarai pada saat eksekusi, kemudian dihancurkan ketika sesi berakhir. Agen tidak pernah melihatnya.

Kredensial statis dan kunci API menjadi tidak berkelanjutan karena satu alasan sederhana: rahasia yang dimiliki agen adalah rahasia yang dapat dicuri penyerang. Dalam dunia di mana aktor yang memegang kredensial dapat diinjeksi prompt atau mengalami halusinasi, kunci yang berumur panjang menjadi aset yang dapat dipanen yang duduk di dalam aktor non-deterministik. Menghilangkan kredensial dari agen dan agen yang dikompromikan tidak memiliki apa-apa untuk bocorkan. Itulah titik dari apa yang kami sebut SecretlessAI.

Seiring agen AI memperoleh kemampuan untuk merencanakan, mengeksekusi tindakan, dan berinteraksi dengan sistem multiple secara mandiri, apa vektor serangan baru yang paling mengkhawatirkan Anda selama tiga hingga lima tahun ke depan?

Vektor yang paling mengkhawatirkan saya semua berasal dari agen yang dapat merencanakan dan bertindak di seluruh sistem secara independen. Injeksi prompt yang mengambil alih niat agen di tengah tugas adalah yang paling jelas, karena identitas tetap valid bahkan ketika perilaku berubah menjadi malisis. Di luar itu, saya khawatir tentang penyerahan agen-ke-agen di mana otoritas diteruskan sepanjang rantai tanpa akuntabilitas yang jelas, pergerakan lateral melalui agen yang memiliki jangkauan jaringan langsung, dan eksfiltrasi data di mana agen yang berlebihan memiliki izin menarik jauh lebih banyak daripada yang diperlukan tugasnya.

Benang merah yang sama adalah bahwa kredensial dan peran dapat sepenuhnya sah sementara tindakan tidak. Pertahanan yang hanya memeriksa izin, bukan tujuan, tidak akan menangkap salah satu dari ini. Itulah mengapa penerapan intent-aware di gerbang, pada setiap tindakan, adalah kontrol yang saya percaya akan paling berarti.

Kita menyaksikan pergeseran dari mengamankan identitas manusia ke mengamankan identitas mesin dan agen. Bagaimana Anda melihat perubahan keseimbangan prioritas keamanan seiring organisasi mulai mengelola jutaan identitas non-manusia di seluruh infrastruktur mereka?

Kita memasuki dunia di mana sebagian besar akses sistem dilakukan oleh identitas non-manusia, mesin, beban kerja, dan sekarang agen, namun sebagian besar alat masih menganggap ada manusia di belakang keyboard. Hasilnya adalah rahasia di mana-mana, hak istimewa yang berdiri, dan identitas yang tidak dapat dilacak oleh siapa pun.

Perubahan prioritas adalah dari kontrol berkala, berbasis manusia ke kontrol runtime terus-menerus pada skala mesin. Ketika Anda mengelola jutaan identitas non-manusia, Anda tidak dapat mengandalkan pendaftaran, kampanye sertifikasi, dan tinjauan akses triwulanan. Anda memerlukan identitas yang efemeral, tanpa hak istimewa yang berdiri, dan kebijakan yang dievaluasi secara otomatis pada setiap tindakan. Keamanan identitas manusia tidak menghilang, tetapi menjadi fraksi yang lebih kecil dari permukaan, dan arsitektur harus dibangun untuk mayoritas non-manusia terlebih dahulu.

Penelitian terbaru menunjukkan bahwa agen AI mungkin sudah mengakses informasi di luar izin yang dimaksudkan. Apa tata kelola dan kontrol runtime yang harus dimiliki organisasi sebelum mengizinkan agen untuk beroperasi secara otonom di lingkungan produksi?

Sebelum agen apa pun beroperasi secara otonom di produksi, saya ingin beberapa hal ada di tempat. Pertama, tidak ada kredensial yang berdiri di agen, dengan akses just-in-time yang berumur singkat diinjeksi per sesi. Kedua, tidak ada jalur jaringan langsung, sehingga setiap tindakan agen diperantarai melalui titik tengah wajib daripada mencapai database dan API secara langsung. Ketiga, kebijakan intent-aware yang mengevaluasi tujuan permintaan melawan prompt asli sebelum kredensial apa pun diterbitkan, sehingga agen yang diminta untuk menganalisis pendapatan tidak dapat mengeluarkan perintah destruktif. Keempat, inspeksi sesi dan masking respons sehingga data sensitif seperti PII dan PHI dihapus sebelum memasuki konteks agen. Dan kelima, catatan audit tunggal yang tidak dapat diubah yang menghubungkan prompt manusia, niat yang diklasifikasikan, keputusan kebijakan, sesi, dan tindakan akhir.

Penemuan dan visibilitas juga penting, tetapi sebagai input kebijakan, bukan sebagai prasyarat untuk perlindungan. Anda harus dapat mengatur agen pertama kali ia mengautentikasi, bahkan jika Anda belum pernah melihat instance spesifik sebelumnya.

Industri sering kali fokus pada keamanan model, tetapi perhatian yang lebih sedikit diberikan pada identitas, otorisasi, dan kontrol akses. Mengapa Anda percaya bahwa area ini akan menjadi beberapa tantangan keamanan paling penting di era AI?

Keamanan model mendapatkan sorotan, tetapi model yang sepenuhnya sejalan masih harus bertindak di dunia nyata, dan saat itu bertindak, model memerlukan akses ke sistem dan data. Akses itulah di mana kerusakan sebenarnya terjadi. Model yang tidak pernah menyentuh database tidak dapat mengekstraknya.

Otorisasi juga bagian tersulit dari keamanan agen, karena aktor adalah non-deterministik dan efemeral. Anda tidak dapat menyelesaikannya sepenuhnya pada lapisan model, dan Anda tidak dapat menyelesaikannya dengan peran statis. Ini memerlukan penerapan intent-aware yang terus-menerus pada setiap tindakan. Itu adalah pekerjaan infrastruktur yang tidak glamor, yang tepat mengapa itu kurang dibahas dan tepat mengapa itu akan menjadi salah satu masalah keamanan paling penting di era ini.

Menghadap ke depan, apakah Anda percaya bahwa perusahaan akan pada akhirnya memerlukan lapisan identitas khusus untuk agen AI, serupa dengan bagaimana penyedia identitas menjadi penting untuk pengguna manusia, dan apa arsitektur masa depan itu akan terlihat seperti?

Ya, tetapi itu tidak akan terlihat seperti model penyedia identitas manusia yang hanya diberi merek ulang untuk agen. Mencoba membangun direktori agen adalah membangun direktori untuk hantu, identitas yang hilang sebelum Anda selesai mendaftarkannya.

Lapisan identitas agen yang saya harapkan akan mengaitkan identitas ke beban kerja yang diterbitkan oleh runtime, IAM cloud, token akun layanan Kubernetes, federasi OIDC, dan standar seperti SPIFFE/SPIRE yang sudah terbukti dan cross-substrat. Otorisasi akan diekspresikan sebagai hubungan antara metode autentikasi dan sistem target, bukan antara identitas bernama dan cakupan. Dan pusat gravitasi akan menjadi bidang penerapan runtime, gerbang yang memperantarai setiap tindakan, mengklasifikasikan niat, menginjeksi kredensial efemeral, memasker respons sensitif, dan menghasilkan rantai forensik penuh. Identitas masih penting, tetapi jatuh ke tempat di belakang penerapan daripada di depan. Lapisan otoritas runtime itu, yang duduk di platform yang sama yang sudah mengatur akses manusia dan mesin, adalah apa yang saya percaya setiap perusahaan yang menjalankan agen di produksi akan membutuhkan.

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