Micha Rave, CEO và Đồng sáng lập Hush Security – Chuỗi phỏng vấn

Micha Rave, CEO và đồng sáng lập Hush Security, là một giám đốc điều hành có kinh nghiệm trong lĩnh vực an ninh mạng và công nghệ, với sự nghiệp trải dài từ kỹ thuật phần mềm, quản lý sản phẩm, mạng doanh nghiệp, an ninh đám mây đến quản lý danh tính. Trước khi đồng sáng lập Hush Security vào năm 2024, ông đã làm việc hơn năm năm tại Proofpoint với vị trí Giám đốc Cấp cao về Quản lý Sản phẩm cho An ninh Đám mây, chịu trách nhiệm về các dòng sản phẩm Zero Trust Network Access (ZTNA) và Secure Web Gateway (SWG). Trước đó, ông từng là Phó Chủ tịch Quản lý Sản phẩm tại Meta Networks, tập trung vào mạng doanh nghiệp và an ninh, và đã giữ các vị trí lãnh đạo sản phẩm và kỹ thuật tại HARMAN International, Redbend, SanDisk, Hola, Jungo và Elbit Systems. Nền tảng của ông kết hợp phát triển phần mềm thực tế với hơn hai thập kỷ kinh nghiệm trong việc xây dựng và thương mại hoá các sản phẩm an ninh, mạng, ảo hoá và công nghệ nhúng.

Hush Security là một công ty an ninh mạng tập trung vào việc bảo vệ các tác nhân AI và các danh tính không phải con người khác bằng cách thay thế các chứng chỉ lâu dài và bí mật tĩnh bằng truy cập dựa trên danh tính và kiểm soát bởi chính sách. Nền tảng của nó phát hiện các tác nhân AI, bao gồm các tác nhân bóng và các tác nhân được phát triển nội bộ, cấp cho chúng các danh tính có thể xác minh, và quản lý các tương tác của chúng với hệ thống doanh nghiệp thông qua quyền truy cập có phạm vi, cấp ngay khi cần, chính sách tập trung và hồ sơ hoạt động có thể kiểm toán. Công ty được thành lập bởi các cựu chuyên gia an ninh từ đội ngũ đứng sau Meta Networks, mà Proofpoint đã mua lại vào năm 2019. Vào tháng 7 năm 2026, Hush đã huy động 30 triệu đô la trong vòng Series A, với Akamai Technologies tham gia làm nhà đầu tư chiến lược cùng Battery Ventures và YL Ventures, đưa tổng số vốn lên 41 triệu đô la khi công ty mở rộng công nghệ để quản lý các tác nhân AI doanh nghiệp và hạ tầng không phải con người.

Trước khi thành lập Hush Security, bạn đã dành nhiều năm để xây dựng và lãnh đạo các sản phẩm an ninh, bao gồm an ninh đám mây tại Proofpoint. Điều gì bạn thấy trên thị trường khiến bạn tin rằng cần phải thành lập Hush, và luận điểm ban đầu đã phát triển như thế nào với sự bùng nổ nhanh chóng của AI có tính năng đại lý?

Tại Proofpoint, chúng tôi đã chứng kiến các doanh nghiệp giải quyết danh tính con người trong khi mọi thứ không phải con người vẫn chạy trên các bí mật tĩnh. Các tài khoản dịch vụ, khối lượng công việc, pipeline, tất cả đều xác thực bằng các khóa mà không ai sở hữu, không ai hết hạn. Ngành công nghiệp đã đáp lại bằng các kho lưu trữ tốt hơn. Đó là một chiếc két tốt hơn, chứ không phải là một giải pháp.

Luận điểm sáng lập là chuyển quyền truy cập không phải con người từ bí mật sang danh tính. Danh tính tải công việc có thể xác minh, chứng chỉ ngắn hạn được cấp ngay khi cần, chính sách được thực thi ngay trong luồng. Không cần viết lại mã.

AI có tính năng đại lý đã làm cho vấn đề này trở nên cấp bách. Một tác nhân là một NHI (định danh không phải con người) suy luận và quyết định trong thời gian chạy những công cụ nào sẽ được gọi. Nếu giao cho nó một khóa tĩnh, bạn đã cấp cho phần mềm tự động quyền truy cập vĩnh viễn vào môi trường sản xuất, và các tác nhân được triển khai ngoài bất kỳ quy trình thay đổi nào; một nhà phát triển cấu hình máy chủ MCP vào thứ Ba và nó đã tiếp cận dữ liệu khách hàng vào thứ Sáu.

Luận điểm không thay đổi. Phạm vi đã thay đổi. Truy cập dựa trên danh tính là câu trả lời đúng cho các tải công việc. Đối với các tác nhân, đây là giải pháp duy nhất khả thi: biết mọi tác nhân tồn tại, cấp cho mỗi tác nhân mức “agency” tối thiểu theo mặc định, và kiểm toán mọi hành động. Con người đã có một IdP. Các tác nhân cũng cần một IdP và đó là Hush.

Hush cho rằng các tác nhân AI doanh nghiệp nên có danh tính và quyền ủy quyền riêng thay vì chỉ kế thừa các quyền truy cập của con người sử dụng chúng. Tại sao các hệ thống Quản lý Danh tính và Truy cập (Identity and Access Management – IAM) truyền thống gặp khó khăn với các tác nhân tự động, và điều gì cần thay đổi?

Trường hợp rõ ràng là một tác nhân hoạt động thay cho người dùng. Trường hợp khó hơn là một tác nhân không có người dùng nào: một công việc được lên lịch, một bộ phản hồi SOC tự động, một pipeline tự suy luận và hành động độc lập. Không có ai để ủy quyền, vì vậy các đội ngũ quay lại công cụ duy nhất họ có, một tài khoản dịch vụ tĩnh với quyền rộng và một khóa không bao giờ hết hạn. Đó là cùng một mô hình bí mật chia sẻ đã gây ra vấn đề trong một thập kỷ, giờ được gắn vào phần mềm tự phát.

Các hệ thống ở phía bên kia khiến vấn đề tồi tệ hơn. Hầu hết các API nội bộ, cơ sở dữ liệu và máy chủ MCP không thực hiện ủy quyền thực sự. Chúng chỉ kiểm tra bạn có giữ một token hợp lệ hay không, chứ không xem bạn được phép làm gì với token đó. Sở hữu đồng nghĩa với quyền.

Điều cần thay đổi: mỗi tác nhân phải có danh tính riêng, được cấp bằng mật mã, bất kể có hay không có con người đứng sau. Quyền truy cập được cấp cho từng hành động, ngắn hạn và có phạm vi, với chính sách được thực thi ngay trong luồng thay vì dựa vào hệ thống đích. Khi có người dùng, quyền của tác nhân là giao thoa giữa những gì người dùng có thể làm và những gì tác nhân được phép thực hiện cho nhiệm vụ đó. Khi không có người dùng, danh tính và chính sách của chính tác nhân là toàn bộ câu chuyện. Con người đã có nguyên tắc “least privilege”. Các tác nhân cần “least agency”.

Bạn sử dụng khái niệm “least agency” khi thảo luận về an ninh AI. “Least agency” khác như thế nào so với nguyên tắc an ninh mạng truyền thống “least privilege”, và các tổ chức có thể xác định chính xác những gì một tác nhân AI nên được phép làm cho một nhiệm vụ cụ thể như thế nào?

Các tác nhân không có hành vi cố định. Nếu cấp cho một tác nhân quyền đọc vào CRM và quyền ghi vào email, bạn không chỉ cấp hai quyền, mà đã mở ra mọi đường dẫn giữa chúng. “Least privilege” chỉ giới hạn những gì một tác nhân có thể chạm tới. Nó không nói gì về việc tác nhân nên làm gì với những quyền đó.

Least agency bổ sung chiều kích còn thiếu: hành động nào, cho nhiệm vụ nào, ngay bây giờ. Một agent xử lý vé cần đọc và bình luận. Nó không cần đóng, xóa, hoặc chạm vào thanh toán, ngay cả khi token cho phép. Khi nhiệm vụ kết thúc, quyền truy cập cũng kết thúc.

Quyết định những gì được phép bắt đầu bằng việc quan sát, không phải đoán mò. Chạy agent, quan sát những gì nó thực sự gọi, và để đó làm nền tảng. Sau đó thu hẹp bằng ba yếu tố: nhiệm vụ mà nó tồn tại để thực hiện, người dùng mà nó hành động thay (không bao giờ vượt quá khả năng của họ), và phạm vi tác động của mỗi hành động, vì việc đăng bình luận và thực hiện thanh toán không nên chia sẻ cùng một đường phê duyệt.

Least privilege quyết định ai được nhận chìa khóa. Least agency quyết định họ có thể làm gì khi đã vào trong.

Chúng tôi thường “cho vay” danh tính của mình cho agent, nhưng không muốn agent có cùng mức quyền như chúng tôi – đây là định nghĩa của least agency.

Hush gần đây đã huy động vòng Series A trị giá 30 triệu USD, đưa tổng vốn lên $41 million, với Akamai tham gia như nhà đầu tư chiến lược cùng Battery Ventures và YL Ventures. Akamai mang lại gì ngoài vốn, và bạn kỳ vọng mối quan hệ này sẽ ảnh hưởng như thế nào đến việc mở rộng bảo mật AI-agent doanh nghiệp của Hush?

Akamai nằm trong đường truyền lưu lượng của hầu hết các doanh nghiệp trên thế giới, và đó chính là nơi bảo mật agent phải tồn tại. Bạn không quản lý một agent từ bảng điều khiển sau khi đã xảy ra. Bạn quản lý nó ngay trong luồng, tại thời điểm nó gọi công cụ hoặc API. Akamai đã xây dựng mô hình kinh doanh dựa trên cách này.

Ngoài vốn, họ mang lại ba yếu tố: phân phối tới các CISO đã hỏi cách kiểm soát agent và lưu lượng MCP; xác nhận rằng danh tính agent là một danh mục thực sự, không chỉ là tính năng; và hàng thập kỷ kinh nghiệm bảo mật lưu lượng máy‑tới‑máy ở quy mô toàn cầu, chính là những gì lưu lượng agent‑tới‑công cụ sắp trở thành.

Model Context Protocol (MCP) đang nhanh chóng trở thành lớp quan trọng để kết nối các AI agent với công cụ và dữ liệu doanh nghiệp. Từ góc độ bảo mật, MCP mang lại những rủi ro mới nào, và các tổ chức nên suy nghĩ thế nào về danh tính và ủy quyền giữa agent, máy chủ MCP và tài nguyên nền tảng?

MCP làm cho việc kết nối một agent với công cụ trở nên đơn giản. Đó chính là rủi ro. Một nhà phát triển chỉ cần thêm một máy chủ vào tệp cấu hình và mô hình giờ có thể đọc Jira, truy vấn cơ sở dữ liệu, hoặc gửi email. Không có đánh giá, không có kiểm kê, không có chính sách. Bảo mật chỉ phát hiện khi có sự cố.

Hiện có ba vấn đề mới:

1. Shadow MCP – không ai biết có bao nhiêu máy chủ đang chạy hoặc chúng chạm tới gì.
2. Credential sprawl – hầu hết máy chủ xác thực bằng token tĩnh cho toàn bộ bề mặt, vì vậy agent nhận được mọi quyền mà token có thể thực hiện.
3. Chuỗi bị sụp – tài nguyên chỉ thấy thông tin xác thực của máy chủ MCP, nên không thể biết agent nào, đại diện cho người dùng nào, đã thực hiện cuộc gọi. Danh tính cần nằm ở nền tảng của mọi tương tác, quyền truy cập phải ngắn hạn, có phạm vi và dựa trên quyền của agent và người dùng.

Hush ban đầu được xây dựng dựa trên ý tưởng rằng các bí mật tĩnh và chứng chỉ lâu dài là nền tảng lỗi thời cho việc truy cập máy. Vì hầu hết hạ tầng doanh nghiệp vẫn phụ thuộc mạnh vào API key, token và các bí mật khác, các công ty có thể thực tế chuyển sang truy cập dựa trên danh tính, ngắn hạn mà không phải xây dựng lại toàn bộ ngăn xếp công nghệ như thế nào?

Bạn không cần xây dựng lại. Không ai nói ngược lại đã gặp được một doanh nghiệp. Phần lớn những gì chúng tôi bảo vệ đã tồn tại trước khi có thuật ngữ danh tính phi người, và nó không được viết lại.

Vì vậy chúng tôi không yêu cầu nó. Hush triển khai mà không cần thay đổi mã và nằm trong đường truy cập. Bước đầu là khám phá: mọi bí mật, ai đang dùng, nó tiếp cận gì, thực tế nó làm gì khi chạy. Hầu hết các công ty chưa từng thấy bức tranh này.

Sau đó đó là một hành trình, không phải một cuộc di chuyển. Khám phá cho thấy bí mật nào đã chết, quá rộng, hoặc có rủi ro cao nhất. Đầu tiên sửa những thứ đó. Sau đó thay thế các khóa tĩnh bằng chứng chỉ ngắn hạn, do danh tính phát hành, từng hệ thống một. Ứng dụng vẫn nghĩ mình đang dùng một khóa. Khóa chỉ không còn lâu dài, và chính sách chuyển sang chúng tôi.

Mô hình tương tự áp dụng cho một dịch vụ Java đã 15 năm tuổi và một máy chủ MCP được dựng lên tuần trước. Bắt đầu từ nơi có rủi ro, chứng minh, rồi tiếp tục.

Các AI agent sẽ ngày càng làm việc thay mặt con người và, trong nhiều trường hợp, ủy nhiệm nhiệm vụ cho các agent khác. Khi các quy trình đa‑agent trở nên phức tạp hơn, làm sao bạn duy trì chuỗi rõ ràng về danh tính, ủy quyền, sở hữu và trách nhiệm cho mỗi hành động xảy ra?

Kịch bản thất bại: một người dùng yêu cầu một orchestrator, orchestrator ủy nhiệm cho agent thứ hai, agent này gọi công cụ qua máy chủ MCP, máy chủ này truy cập cơ sở dữ liệu bằng tài khoản dịch vụ. Bốn bước sau, log chỉ hiển thị một token hợp lệ. Ai đã yêu cầu, ai đã quyết định, và ai chịu trách nhiệm đã biến mất.

Giải pháp là không để danh tính sụp đổ ở bất kỳ bước nào. Mỗi agent có danh tính mật mã riêng. Khi ủy nhiệm, nó không chuyển token của mình. Nó phát hành ủy nhiệm có phạm vi: agent phụ này, nhiệm vụ này, các hành động này, thay mặt người dùng này. Mỗi bước mang toàn bộ chuỗi và quyền riêng của nó.

Trách nhiệm xuất phát từ việc thực thi và ghi nhật ký ngay tại chỗ, tại thời điểm hành động. Bản ghi của gateway về những gì nó được phép thực hiện, những gì nó đã gọi, và chuỗi phía sau đó.

Các hệ thống đa tác nhân sẽ ngày càng khó suy luận. Chuỗi quản lý quyền sở hữu cho mỗi hành động không nhất thiết phải như vậy.

Việc tiêm lệnh (prompt injection) và các cuộc tấn công khác có thể thao túng một tác nhân AI hợp pháp thành thực hiện các hành động mà người vận hành không bao giờ dự định. Đến mức độ nào các kiểm soát truy cập dựa trên danh tính có thể hạn chế thiệt hại từ một tác nhân bị xâm phạm hoặc bị thao túng, ngay cả khi mô hình AI nền tảng hoạt động không chính xác?

Bạn không thể ngăn chặn tiêm lệnh ở mức mô hình. Các mô hình được thiết kế để đọc nội dung không tin cậy. Hãy giả định rằng tác nhân cuối cùng sẽ bị thuyết phục thực hiện điều sai. Câu hỏi là nó có thể làm gì khi điều đó xảy ra.

Kiểm soát truy cập dựa trên danh tính giới hạn phạm vi ảnh hưởng. Một tác nhân bị thao túng với quyền hạn tối thiểu chỉ có thể lạm dụng các hành động mà nó được cấp cho nhiệm vụ đó. Nếu nó có thể đọc vé và đăng bình luận, không có cuộc tiêm lệnh nào khiến nó trích xuất cơ sở dữ liệu khách hàng. Token không có quyền truy cập rộng.

Ghi nhận người dùng giữ cho chuỗi không bị phá vỡ: người dùng nào, tác nhân nào, nhiệm vụ nào, trên mỗi cuộc gọi. Tác nhân không bao giờ vượt quá khả năng của người dùng, và mọi hành động đều có thể truy ngược lại.

Phát hiện bất thường bắt được những gì chính sách cho phép nhưng ý định không. Một tác nhân thường chỉ đọc năm bản ghi mà đột nhiên kéo về năm nghìn là hành vi bất thường ngay cả khi mỗi cuộc gọi đều được ủy quyền. Vì gateway hoạt động ngay tại chỗ và nắm rõ mức chuẩn, nó có thể đánh dấu hoặc chặn ngay trong thời gian thực.

Mô hình sẽ sai đôi khi. Danh tính có phạm vi, ghi nhận và các mức chuẩn hành vi giúp lỗi có thể chịu đựng được.

Hush chủ yếu tập trung vào việc bảo mật AI, nhưng các bạn đang sử dụng AI bên trong Hush như thế nào? Có những lĩnh vực như phát hiện danh tính không phải con người, phân tích mẫu truy cập, ưu tiên rủi ro, hoặc thực thi chính sách mà AI có thể cải thiện đáng kể nền tảng bảo mật không?

Chúng tôi sử dụng nó ở bất cứ nơi nào nó xứng đáng.

Trong sản phẩm, phần khó không phải là tìm ra bí mật, mà là hiểu chúng. Một khóa xuất hiện trong lưu lượng. Danh tính tải công việc, tích hợp nhà cung cấp, token kiểm thử phát triển, chứng chỉ chết? Một LLM đọc ngữ cảnh thời gian chạy và tín hiệu của chủ sở hữu và đề xuất câu trả lời kèm điểm tin cậy. Nó tóm tắt những gì một danh tính thực sự làm bằng ngôn ngữ con người đơn giản, vì vậy chính sách là một thứ mà con người sẽ phê duyệt. Nó xếp hạng rủi ro dựa trên phạm vi thực tế và bán kính ảnh hưởng, không phải mức độ nghiêm trọng tĩnh. Việc thực thi vẫn quyết định được. AI giúp viết chính sách – nó không có quyền bỏ phiếu trong thời gian chạy.

Trong Hush, lập trình dựa trên tác nhân đã thay đổi nhịp độ của chúng tôi. Các tính năng mà trước đây mất một sprint giờ chỉ mất vài ngày, và chúng tôi triển khai các tích hợp với tốc độ mà một đội Series A không thể chi trả. Các LLM phân loại vé hỗ trợ, nhóm nguyên nhân gốc rễ, và đưa ra các yêu cầu của khách hàng cho các cuộc thảo luận lộ trình. Gateway MCP của chúng tôi nằm ở phía trước tất cả, giúp khách hàng của chúng tôi suy luận và tiêu thụ NHI và rủi ro tác nhân.

Hush cho biết nhiều công ty trong danh sách Fortune 500 hiện đang sử dụng công nghệ của mình, trong khi Kyndryl đã triển khai Hush nội bộ và bắt đầu bán lại cho khách hàng doanh nghiệp. Các bạn đang học được gì từ các triển khai quy mô lớn này về các vấn đề quản trị thực tế mà các công ty gặp phải khi các tác nhân AI chuyển từ giai đoạn thử nghiệm sang sản xuất?

Không ai biết mình có gì. Mỗi triển khai lớn đều bắt đầu như vậy: bộ phận bảo mật nghĩ chỉ có khoảng mười hai tác nhân đang hoạt động, nhưng quá trình khám phá lại phát hiện hàng trăm, đã tiếp cận dữ liệu khách hàng. Vấn đề quản trị không phải là chính sách, mà là việc kiểm kê trước tiên.

Thông tin xác thực còn tệ hơn các tác nhân. Hầu hết các tác nhân trong môi trường sản xuất chạy trên tài khoản dịch vụ tĩnh đã tồn tại trước chúng, với quyền được tích lũy trong nhiều năm cho mục đích khác. Nó không được cấp quyền có phạm vi.

Quyền sở hữu còn thiếu. Khi hỏi ai chịu trách nhiệm về một tác nhân, hoặc một NHI, bạn chỉ nhận được tên một đội ở mức tối đa, một nhà thầu đã rời đi, hoặc im lặng.

Và người mua đã thay đổi. Đây là vấn đề của đội nền tảng. Bây giờ CISO sở hữu nó vì ban giám đốc yêu cầu. Điều đó đã đưa chúng tôi từ các dự án thí điểm sang triển khai doanh nghiệp, và đó là lý do Kyndryl triển khai nội bộ trước khi bán lại.

Các tác nhân không tạo ra vấn đề quản trị mới. Chúng đã lấy những vấn đề mà doanh nghiệp đã bỏ qua trong một thập kỷ với các tài khoản dịch vụ và làm chúng tồi tệ hơn nhiều.

Cảm ơn các bạn đọc đã tham gia phỏng vấn tuyệt vời, những người muốn tìm hiểu thêm nên truy cập Hush Security.