Micha Rave, CEO dan Co-Founder Hush Security – Seri Wawancara

Micha Rave, CEO dan co-founder Hush Security, adalah eksekutif keamanan siber dan teknologi berpengalaman yang kariernya mencakup rekayasa perangkat lunak, manajemen produk, jaringan perusahaan, keamanan cloud, dan identitas. Sebelum mendirikan Hush Security pada 2024, ia menghabiskan lebih dari lima tahun di Proofpoint sebagai Senior Director of Product Management untuk Cloud Security, di mana ia bertanggung jawab atas lini produk Zero Trust Network Access (ZTNA) dan Secure Web Gateway (SWG). Sebelumnya ia menjabat sebagai VP of Product Management di Meta Networks, berfokus pada jaringan perusahaan dan keamanan, serta memegang peran kepemimpinan produk dan rekayasa di HARMAN International, Redbend, SanDisk, Hola, Jungo, dan Elbit Systems. Latar belakangnya menggabungkan pengembangan perangkat lunak langsung dengan lebih dari dua dekade pengalaman dalam membangun dan memasarkan produk keamanan, jaringan, virtualisasi, dan teknologi tertanam.

Hush Security adalah perusahaan keamanan siber yang fokus mengamankan agen AI dan identitas non-manusia lainnya dengan menggantikan kredensial jangka panjang dan rahasia statis dengan akses berbasis identitas dan kebijakan. Platformnya menemukan agen AI, termasuk agen bayangan dan agen yang dikembangkan secara internal, memberikan mereka identitas yang dapat diverifikasi, dan mengatur interaksi mereka dengan sistem perusahaan menggunakan izin berskala, just-in-time, kebijakan terpusat, serta catatan aktivitas yang dapat diaudit. Perusahaan ini didirikan oleh veteran keamanan dari tim di balik Meta Networks, yang diakuisisi oleh Proofpoint pada 2019. Pada Juli 2026, Hush mengumpulkan $30 juta Seri A dengan Akamai Technologies bergabung sebagai investor strategis bersama Battery Ventures dan YL Ventures, meningkatkan total pendanaan menjadi $41 juta seiring perusahaan memperluas teknologinya untuk mengatur agen AI perusahaan dan infrastruktur non-manusia.

Sebelum mendirikan Hush Security, Anda menghabiskan bertahun-tahun membangun dan memimpin produk keamanan, termasuk keamanan cloud di Proofpoint. Apa yang Anda lihat di pasar yang meyakinkan bahwa ada kebutuhan untuk memulai Hush, dan bagaimana tesis awal tersebut berkembang seiring dengan kenaikan cepat AI agen?

Di Proofpoint kami menyaksikan perusahaan menyelesaikan identitas manusia sementara segala sesuatu non-manusia masih berjalan dengan rahasia statis. Akun layanan, beban kerja, pipeline, semuanya mengautentikasi dengan kunci yang tidak dimiliki siapa pun, tidak pernah kedaluwarsa. Industri menjawab dengan brankas yang lebih baik. Itu adalah brankas yang lebih baik, bukan solusi.

Tesis pendirian adalah memindahkan akses non-manusia dari rahasia ke identitas. Identitas beban kerja yang dapat diverifikasi, kredensial berumur pendek yang dikeluarkan just-in-time, kebijakan yang diterapkan secara inline. Tanpa penulisan ulang kode.

AI agen membuat hal itu mendesak. Sebuah agen adalah NHI yang berpikir dan memutuskan pada waktu berjalan alat mana yang akan dipanggil. Jika Anda memberikannya kunci statis, Anda telah memberikan perangkat lunak otonom akses tetap ke produksi, dan agen-agen dikirim di luar proses perubahan apa pun; seorang pengembang menghubungkan server MCP pada hari Selasa dan pada hari Jumat sudah menyentuh data pelanggan.

Tesis tidak berubah. Lingkupnya yang berubah. Akses berbasis identitas adalah jawaban yang tepat untuk beban kerja. Untuk agen, itu satu-satunya yang dapat bekerja: ketahui setiap agen yang ada, berikan masing-masing agen hak paling sedikit secara default, dan audit setiap tindakan. Manusia mendapatkan IdP. Agen juga membutuhkannya dan itulah Hush.

Hush berpendapat bahwa agen AI perusahaan harus memiliki identitas dan izin delegasi mereka sendiri, bukan sekadar mewarisi hak akses manusia yang menggunakannya. Mengapa sistem Identity and Access Management (IAM) tradisional kesulitan dengan agen otonom, dan apa yang perlu diubah?

Kasus yang jelas adalah agen yang bertindak untuk seorang pengguna. Kasus yang lebih sulit adalah agen tanpa pengguna sama sekali: pekerjaan terjadwal, responden SOC otonom, pipeline yang berpikir dan bertindak sendiri. Tidak ada siapa pun untuk mendelegasikan, sehingga tim kembali ke satu-satunya alat yang mereka miliki, yaitu akun layanan statis dengan izin luas dan kunci yang tidak pernah kedaluwarsa. Itu adalah model rahasia bersama yang telah mengalami kegagalan selama satu dekade, kini terikat pada perangkat lunak yang berimprovisasi.

Sistem di ujung lain memperburuknya. Kebanyakan API internal, basis data, dan server MCP tidak melakukan otorisasi yang sesungguhnya. Mereka memeriksa apakah Anda memegang token yang valid, bukan apa yang Anda diizinkan lakukan dengan token tersebut. Kepemilikan sama dengan izin.

Apa yang perlu diubah: setiap agen mendapatkan identitasnya sendiri, diterbitkan secara kriptografis, terlepas apakah ada manusia di belakangnya atau tidak. Akses diberikan per tindakan, berumur pendek dan berskala, dengan kebijakan yang diterapkan secara inline alih-alih dipercayakan pada sistem target. Ketika ada pengguna, izin agen adalah irisan antara apa yang dapat dilakukan pengguna dan apa yang diizinkan bagi agen tersebut untuk tugas itu. Ketika tidak ada, identitas dan kebijakan agen sendiri menjadi seluruh cerita. Manusia mendapatkan hak paling sedikit. Agen membutuhkan agensi paling sedikit.

Anda menggunakan konsep “least agency” ketika membahas keamanan AI. Bagaimana agensi paling sedikit berbeda dari prinsip keamanan siber tradisional yaitu hak paling sedikit, dan bagaimana organisasi dapat menentukan secara tepat apa yang harus diizinkan bagi agen AI untuk melakukan pada tugas tertentu?

Agen tidak memiliki perilaku tetap. Memberikan satu agen akses baca ke CRM dan akses tulis ke email tidak berarti Anda memberikan dua izin, melainkan Anda memberikan setiap jalur di antara keduanya. Hak paling sedikit membatasi apa yang dapat disentuh agen. Itu tidak mengatakan apa yang harus dilakukan agen dengan akses tersebut.

Least agency menambahkan dimensi yang hilang: tindakan apa, untuk tugas apa, saat ini. Agen yang menanggapi tiket perlu membaca dan memberi komentar. Ia tidak perlu menutup, menghapus, atau menyentuh penagihan, bahkan jika token mengizinkannya. Ketika tugas selesai, akses berakhir.

Menentukan apa yang diizinkan dimulai dengan observasi, bukan tebak‑tebakan. Jalankan agen, perhatikan apa yang sebenarnya dipanggilnya, dan biarkan itu menjadi patokan. Kemudian persempit dengan tiga masukan: tugas yang ada untuk dilakukannya, pengguna yang diwakilinya (tidak pernah lebih dari yang dapat mereka lakukan), dan radius dampak setiap tindakan, karena memposting komentar dan melakukan pembayaran tidak seharusnya berbagi jalur persetujuan.

Least privilege menentukan siapa yang mendapatkan kunci. Least agency menentukan apa yang dapat mereka lakukan setelah berada di dalam.

Seringkali kami “meminjamkan” identitas kami kepada agen kami, tetapi kami tidak menginginkan agen memiliki tingkat izin yang sama dengan kami – inilah definisi least agency.

Hush baru-baru ini mengumpulkan dana Seri A senilai 30 juta dolar, meningkatkan total pendanaan menjadi $41 juta, dengan Akamai bergabung sebagai investor strategis bersama Battery Ventures dan YL Ventures. Apa yang dibawa keterlibatan Akamai selain modal, dan bagaimana Anda memperkirakan kemitraan ini akan memengaruhi ekspansi Hush ke keamanan agen AI perusahaan?

Akamai berada di jalur lalu lintas sebagian besar perusahaan dunia, dan itulah tempat yang tepat bagi keamanan agen untuk beroperasi. Anda tidak mengatur agen dari dasbor setelah fakta. Anda mengaturnya secara inline, pada saat ia memanggil alat atau API. Akamai membangun bisnisnya dengan model itu.

Selain modal, mereka membawa tiga hal: Distribusi ke CISO yang sudah menanyakan cara mengendalikan agen dan lalu lintas MCP; validasi bahwa identitas agen adalah kategori nyata, bukan sekadar fitur; serta puluhan tahun pengalaman mengamankan lalu lintas mesin‑ke‑mesin dalam skala global, yang akan menjadi lalu lintas agen‑ke‑alat.

Model Context Protocol (MCP) dengan cepat menjadi lapisan penting untuk menghubungkan agen AI dengan alat dan data perusahaan. Dari perspektif keamanan, risiko baru apa yang diperkenalkan MCP, dan bagaimana organisasi harus memikirkan identitas serta otorisasi antara agen, server MCP, dan sumber daya yang mendasarinya?

MCP membuat menghubungkan agen ke alat menjadi sangat mudah. Itulah risikonya. Seorang pengembang menambahkan server ke file konfigurasi dan model kini dapat membaca Jira, mengkuiri basis data, atau mengirim email. Tanpa tinjauan, tanpa inventaris, tanpa kebijakan. Keamanan baru menyadari ketika sesuatu gagal.

Sekarang ada tiga masalah baru:

1. Shadow MCP – tidak ada yang tahu berapa banyak server yang berjalan atau apa yang mereka sentuh.
2. Credential sprawl – sebagian besar server mengautentikasi dengan token statis yang memberikan akses ke seluruh permukaan, sehingga agen mendapatkan semua yang dapat dilakukan token tersebut.
3. The collapsed chain – sumber daya hanya melihat kredensial server MCP, sehingga tidak dapat mengetahui agen mana, yang bertindak atas nama pengguna mana, yang melakukan panggilan. Identitas harus berada di dasar setiap interaksi, akses harus bersifat sementara, tersegmentasi, dan berdasarkan izin agen serta pengguna.

Hush pada awalnya dibangun dengan gagasan bahwa rahasia statis dan kredensial jangka panjang merupakan fondasi yang rusak untuk akses mesin. Karena sebagian besar infrastruktur perusahaan masih sangat bergantung pada kunci API, token, dan rahasia lainnya, bagaimana perusahaan dapat secara realistis beralih ke akses berbasis identitas yang bersifat singkat tanpa membangun ulang seluruh tumpukan teknologi mereka?

Anda tidak membangun ulang. Tidak ada yang mengatakan sebaliknya yang pernah berhadapan dengan perusahaan. Sebagian besar apa yang kami lindungi sudah ada sebelum istilah identitas non-manusia muncul, dan tidak akan ditulis ulang.

Jadi kami tidak memintanya. Hush diterapkan tanpa perubahan kode dan berada di jalur akses. Langkah pertama adalah penemuan: setiap rahasia, siapa yang menggunakannya, apa yang dijangkau, apa yang sebenarnya dilakukannya saat runtime. Sebagian besar perusahaan belum pernah melihat gambaran itu.

Kemudian ini adalah perjalanan, bukan migrasi. Penemuan menunjukkan rahasia mana yang sudah tidak terpakai, terlalu luas, atau berisiko tinggi. Perbaiki yang itu terlebih dahulu. Kemudian ganti kunci statis dengan kredensial yang dikeluarkan identitas dan bersifat singkat, satu sistem pada satu waktu. Aplikasi masih mengira bahwa ia menggunakan kunci. Kunci tersebut hanya berhenti menjadi jangka panjang, dan kebijakan berpindah ke kami.

Model yang sama mencakup layanan Java berusia lima belas tahun dan server MCP yang baru dipasang minggu lalu. Mulailah dari tempat risiko berada, buktikan, teruskan.

Agen AI akan semakin banyak bekerja atas nama manusia dan, dalam banyak kasus, mendelegasikan tugas ke agen lain. Seiring alur kerja multi‑agen ini menjadi lebih kompleks, bagaimana Anda menjaga rantai identitas, otorisasi, kepemilikan, dan akuntabilitas yang jelas untuk setiap tindakan yang terjadi?

Mode kegagalan: seorang pengguna meminta orchestrator, yang kemudian mendelegasikan ke agen kedua, yang memanggil alat melalui server MCP, yang mengakses basis data dengan akun layanan. Empat lompatan kemudian log hanya menunjukkan satu hal, token yang valid. Siapa yang meminta, siapa yang memutuskan, dan siapa yang bertanggung jawab sudah tidak terlihat.

Solusinya adalah menolak identitas untuk runtuh pada setiap lompatan. Setiap agen memiliki identitas kriptografi masing‑masing. Saat mendelegasikan, ia tidak menyerahkan tokennya. Ia mengeluarkan delegasi tersegmentasi: sub‑agen ini, tugas ini, tindakan ini, atas nama pengguna ini. Setiap lompatan membawa seluruh rantai, serta izin masing‑masing.

Akuntabilitas berasal dari penegakan dan pencatatan secara inline, pada titik aksi. Catatan gateway tentang apa yang diizinkannya lakukan, apa yang dipanggilnya, dan rantai di belakangnya.

Sistem multi‑agen akan menjadi semakin sulit untuk dipahami. Rantai kepemilikan untuk setiap aksi tidak harus.

Prompt injection dan serangan lain berpotensi memanipulasi agen AI yang sah menjadi melakukan tindakan yang tidak pernah dimaksudkan oleh operatornya. Sejauh mana kontrol akses berbasis identitas dapat membatasi kerusakan dari agen yang terkompromi atau dimanipulasi, bahkan ketika model AI yang mendasarinya berperilaku tidak benar?

Anda tidak akan menghentikan prompt injection pada model. Model secara desain membaca konten yang tidak tepercaya. Asumsikan agen pada akhirnya akan dibujuk melakukan sesuatu yang salah. Pertanyaannya adalah apa yang dapat dilakukannya ketika hal itu terjadi.

Akses berbasis identitas membatasi radius dampak. Agen yang dimanipulasi dengan wewenang minimal hanya dapat menyalahgunakan tindakan yang diberikan untuk tugas tersebut. Jika ia dapat membaca tiket dan memposting komentar, tidak ada injeksi yang membuatnya mengekstrak basis data pelanggan. Token tidak memiliki jangkauan tersebut.

Atribusi pengguna menjaga rantai tetap utuh: pengguna mana, agen mana, tugas mana, pada setiap panggilan. Agen tidak pernah melampaui apa yang dapat dilakukan pengguna, dan setiap aksi dapat ditelusuri kembali.

Deteksi anomali menangkap apa yang diizinkan kebijakan tetapi tidak sesuai dengan niat. Agen yang biasanya membaca lima catatan dan tiba‑tiba menarik lima ribu berada di luar karakteristiknya bahkan jika setiap panggilan diotorisasi. Karena gateway berada secara inline dan mengetahui baseline, ia dapat menandai atau memblokirnya secara real time.

Model akan salah kadang‑kadang. Identitas berskala, atribusi, dan baseline perilaku membuat kesalahan dapat ditangani.

Hush terutama fokus pada mengamankan AI, tetapi bagaimana Anda menggunakan AI di dalam Hush sendiri? Apakah ada area seperti menemukan identitas non‑manusia, menganalisis pola akses, memprioritaskan risiko, atau menegakkan kebijakan di mana AI dapat secara signifikan meningkatkan platform keamanan?

Kami menggunakannya di mana pun ia pantas berada.

Dalam produk, bagian sulit bukan menemukan rahasia, melainkan memahaminya. Sebuah kunci muncul dalam lalu lintas. Identitas beban kerja, integrasi vendor, token pengujian pengembang, kredensial mati? Sebuah LLM membaca konteks runtime dan sinyal pemilik serta mengusulkan jawaban dengan skor kepercayaan. Ia merangkum apa yang sebenarnya dilakukan sebuah identitas dalam bahasa manusia yang sederhana, sehingga kebijakan tersebut dapat disetujui manusia. Ia memberi peringkat risiko berdasarkan jangkauan nyata dan radius dampak, bukan keparahan statis. Penegakan tetap deterministik. AI membantu menulis kebijakan – ia tidak mendapatkan suara pada runtime.

Di dalam Hush, pemrograman agenik mengubah ritme kerja kami. Fitur yang biasanya memakan satu sprint kini memakan hari, dan kami meluncurkan integrasi dengan kecepatan yang tidak dapat dicapai tim Series A. LLM menyeleksi tiket dukungan, mengelompokkan penyebab utama, dan menampilkan permintaan pelanggan untuk diskusi roadmap. Gateway MCP kami sendiri berada di depan semua itu, membantu pelanggan kami memahami dan mengonsumsi NHI serta risiko agenik.

Hush mengatakan beberapa perusahaan Fortune 500 kini menggunakan teknologinya, sementara Kyndryl telah menerapkan Hush secara internal dan mulai menjualnya kembali ke klien perusahaan. Apa yang Anda pelajari dari penerapan skala besar ini tentang masalah tata kelola dunia nyata yang dihadapi perusahaan ketika agen AI beralih dari eksperimen ke produksi? 

Tidak ada yang tahu apa yang mereka miliki. Setiap penerapan besar dimulai dengan cara yang sama: keamanan mengira ada selusin agen dalam produksi, penemuan menemukan ratusan, yang sudah menyentuh data pelanggan. Masalah tata kelola bukan kebijakan, melainkan inventarisasi terlebih dahulu.

Kredensial lebih buruk daripada agen. Hampir setiap agen produksi berjalan pada akun layanan statis yang ada sebelum agen tersebut, dengan izin yang terkumpul selama bertahun‑tahun untuk keperluan lain. Ia tidak mendapatkan akses yang terdefinisi.

Kepemilikan tidak ada. Tanyakan siapa yang bertanggung jawab atas sebuah agen, atau NHI, dan Anda hanya mendapatkan nama tim paling baik, kontraktor yang sudah keluar, atau tidak ada jawaban.

Dan pembelinya berubah. Ini adalah masalah tim platform. Sekarang CISO yang memilikinya karena dewan meminta. Itu mengalihkan kami dari pilot ke peluncuran perusahaan, dan itulah mengapa Kyndryl menerapkan secara internal sebelum menjual kembali.

Agen tidak menciptakan masalah tata kelola baru. Mereka mengambil masalah yang diabaikan perusahaan selama satu dekade dengan akun layanan dan membuatnya jauh lebih buruk.

Terima kasih atas wawancara yang luar biasa, pembaca yang ingin belajar lebih lanjut sebaiknya mengunjungi Hush Security.