Phỏng vấn
Sean Blanchfield, Đồng sáng lập và CEO của Jentic – Loạt bài Phỏng vấn

Sean Blanchfield, Đồng sáng lập và CEO của Jentic, là một doanh nhân công nghệ kỳ cựu với nhiều thập kỷ kinh nghiệm xây dựng các công ty phần mềm và hạ tầng quy mô lớn. Đặt trụ sở tại Dublin, hiện ông lãnh đạo Jentic đồng thời tham gia Hội đồng Tư vấn AI của Ireland, tư vấn cho chính phủ về chính sách trí tuệ nhân tạo. Trước đó trong sự nghiệp, ông đồng sáng lập DemonWare, một nền tảng dịch vụ trực tuyến quy mô lớn cho các nhà phát hành trò chơi điện tử lớn, sau này được Activision Blizzard mua lại, và PageFair, một công ty khởi nghiệp được đầu tư mạo hiểm tập trung vào phân tích chặn quảng cáo được Blockthrough mua lại. Ông cũng đã sáng lập hoặc dẫn dắt nhiều công ty khởi nghiệp và tiếp tục hỗ trợ hệ sinh thái khởi nghiệp Ireland thông qua các sáng kiến như Techpreneurs. Jentic đang phát triển một lớp tích hợp phổ quát được thiết kế để giúp các tác nhân AI tương tác an toàn với hệ thống doanh nghiệp và API. Nền tảng này cho phép các tổ chức kết nối mô hình AI với công cụ nội bộ, dịch vụ bên ngoài và quy trình làm việc vận hành trong khi vẫn duy trì quản trị, xác thực và giám sát. Bằng cách biến các API phân mảnh thành các giao diện có cấu trúc mà các tác nhân AI có thể sử dụng một cách đáng tin cậy, Jentic hướng tới mục tiêu giúp các doanh nghiệp triển khai tự động hóa dẫn dắt bởi AI ở quy mô lớn trên các môi trường phần mềm phức tạp. Ông đã sáng lập và dẫn dắt nhiều công ty công nghệ, từ DemonWare (được Activision Blizzard mua lại) đến PageFair và giờ là Jentic, đồng thời ông cũng tham gia Hội đồng Tư vấn AI của Ireland. Điều gì đã thu hút ông trở lại xây dựng ở lớp hạ tầng với Jentic, và ông nhìn thấy khoảng trống nào trong hệ sinh thái tác nhân AI đang nổi lên mà những người khác đang bỏ lỡ? Đến lần thứ ba bạn nhận thấy một khuôn mẫu, bạn phải nghiêm túc xem xét nó. Tại DemonWare, mọi người đều nói về chơi trực tuyến nhiều người – nhưng vấn đề khó khăn là hạ tầng mạng bên dưới nó. Điều tương tự đang xảy ra với các tác nhân AI. Các mô hình rất đáng chú ý. Nút thắt cổ chai là lớp tích hợp – luôn luôn như vậy. Các tác nhân AI chạy trên API, và những API đó được xây dựng cho con người: được ghi chép cho con người, bảo mật cho con người và có cấu trúc cho con người. Chỉ một tác nhân tự trị vào hạ tầng đó, và nó sẽ nhanh chóng sụp đổ. Các dự án thí điểm AI doanh nghiệp không thất bại vì mô hình hiểu sai nhiệm vụ; chúng thất bại vì tác nhân không thể kết nối đáng tin cậy với các hệ thống nó cần. AI tạo sinh cung cấp một cách mới để giải quyết điều này – bằng cách coi tích hợp là một vấn đề tri thức, không phải vấn đề mã hóa. Nhận thức đó đã thu hút tôi. Khi ông bắt đầu Jentic vào năm 2024, bảo mật tác nhân có phải là luận điểm chính ngay từ ngày đầu tiên, hay trọng tâm đã được mài sắc khi ông quan sát cách các tổ chức thực sự triển khai các tác nhân tự trị trong môi trường sản xuất? Sợi chỉ đầu tiên tôi kéo ra là thông tin xác thực. Tôi hình dung các tác nhân sinh sôi nảy nở, mỗi tác nhân cần thông tin xác thực cho hàng chục hệ thống, tất cả những bí mật đó chảy vào cửa sổ ngữ cảnh LLM, bị rò rỉ – một mớ hỗn độn. Câu trả lời giống như cách đây hai mươi năm: tập trung hóa xác thực và ủy quyền. Nhưng kéo sợi chỉ đó dẫn thẳng đến vấn đề tiếp theo: nếu bạn tập trung hóa bằng công cụ tích hợp truyền thống, bạn quay lại vùng đất của các bộ kết nối tĩnh, và các tác nhân thì không tĩnh. Điều củng cố tầm nhìn là nhận ra rằng việc khám phá khả năng nên được kết hợp chặt chẽ với kiểm soát truy cập – rằng một tác nhân chỉ nên được cung cấp một khả năng nếu nó thực sự được ủy quyền sử dụng, và rằng hệ thống cung cấp khám phá cũng có thể là điểm thực thi và quan sát duy nhất. Việc phơi bày gần đây của một số lượng lớn các phiên bản tác nhân hướng ra internet đã làm nổi bật cách điều phối và thông tin xác thực thường chia sẻ cùng một ranh giới tin cậy. Từ góc nhìn của ông, lỗ hổng kiến trúc cốt lõi trong mô hình đó là gì? Lỗ hổng rất đơn giản: tác nhân – một hệ thống chạy các lệnh từ một LLM – cũng là hệ thống nắm giữ thông tin xác thực và thực hiện các lệnh gọi API. Xâm phạm tác nhân và bạn có được mọi thứ nó có thể từng làm. Đó là sai lầm tương tự chúng ta đã mắc phải trong thời kỳ đầu của web – các máy chủ ứng dụng có quyền truy cập cơ sở dữ liệu siêu người dùng vì nó thuận tiện. Jentic đóng vai trò như một lớp giữa tác nhân và các API mà nó gọi. Tác nhân không bao giờ nắm giữ thông tin xác thực. Nó đưa ra yêu cầu thông qua lớp thực thi được quản lý của chúng tôi, lớp này tiêm thông tin xác thực phía máy chủ, thực thi chính sách và ghi nhật ký mọi lệnh gọi. Và khi có sự cố xảy ra, có một công tắc ngắt duy nhất – một hành động dừng quyền truy cập của tác nhân đó trên mọi hệ thống được kết nối đồng thời. Ông đã nói về việc tách biệt điều phối khỏi thực thi để kiềm chế bán kính ảnh hưởng. Ông có thể giải thích bằng thuật ngữ thực tế cách tách biệt đó thay đổi hồ sơ rủi ro như thế nào khi một phiên bản bị xâm phạm? Trong mô hình phẳng, LLM lý luận về việc cần làm và trực tiếp gọi API bằng thông tin xác thực mà nó nắm giữ. Xâm phạm lớp lý luận, và bạn kiểm soát lớp thực thi. Với sự tách biệt, LLM phát ra một ý định – “gọi API thanh toán Stripe với các tham số này” – một lớp thực thi được quản lý xác thực yêu cầu đó dựa trên chính sách, tiêm thông tin xác thực phía máy chủ và thực hiện lệnh gọi. LLM không bao giờ chạm vào thông tin xác thực. Trong thực tế: việc di chuyển ngang trở nên khó khăn hơn nhiều, bán kính ảnh hưởng bị giới hạn bởi những gì lớp thực thi cho phép đối với danh tính tác nhân cụ thể đó, và bạn có một công tắc ngắt. Một nút chuyển và quyền truy cập của tác nhân dừng lại trên mọi hệ thống được kết nối. Tác nhân vẫn có thể bị thao túng – nhưng thao túng không còn tự động đồng nghĩa với việc thông tin xác thực bị xâm phạm hoàn toàn. Trong các triển khai doanh nghiệp thực tế, quản lý thông tin xác thực tập trung và thu hồi tức thì thực sự trông như thế nào, và nó khác với cách hầu hết các nhóm hiện đang xử lý khóa API và mã thông báo cho tác nhân ra sao? Ngày nay, hầu hết các nhóm có một nhà phát triển cung cấp khóa API, lưu trữ chúng trong tệp .env và tải chúng khi khởi động tác nhân – thường trực tiếp vào cửa sổ ngữ cảnh của LLM. Không ai có bức tranh hoàn chỉnh về việc tác nhân nào nắm giữ thông tin xác thực nào. Khi ai đó rời đi, các khóa họ cung cấp không được xoay vòng. Khi một tác nhân hoạt động kỳ lạ, không có dấu vết kiểm tra nào để tái tạo lại những gì đã xảy ra. Với Jentic, nhà phát triển không bao giờ xử lý thông tin xác thực thô. Họ khai báo quyền truy cập mà một tác nhân cần, nền tảng cung cấp quyền truy cập có phạm vi và tác nhân gọi thông qua lớp thực thi của chúng tôi mà không bao giờ nhìn thấy khóa cơ bản. Điều đó có nghĩa là bạn có được khả năng thu hồi tức thì cho mỗi tác nhân, khả năng tạm dừng quyền truy cập trong khi bạn điều tra và một dấu vết kiểm tra có dấu thời gian cho mọi lệnh gọi API. Sự khác biệt giữa điều đó và “khóa API trong tệp .env” là rất lớn. Nhiều nhóm đang thử nghiệm các khuôn khổ tác nhân trên các lĩnh vực bán hàng, kỹ thuật và khoa học dữ liệu. Những sai lầm bảo mật phổ biến nhất mà ông đang thấy khi các tổ chức chuyển từ thử nghiệm sang sản xuất là gì? Các khuôn mẫu tương tự lặp lại: các tác nhân được cấp quyền quá mức vẫn chạy trên thông tin xác thực quản trị viên mà chúng được tạo nguyên mẫu; thông tin xác thực được truyền trong lệnh hoặc cửa sổ ngữ cảnh nơi chúng kết thúc trong nhật ký, dữ liệu viễn thám và có khả năng là dữ liệu đào tạo; thông tin xác thực được chia sẻ trên nhiều phiên bản tác nhân để bạn không thể cô lập một tác nhân xấu duy nhất; không có công tắc ngắt để dừng một tác nhân mà không làm sập hệ thống rộng hơn; không có dấu vết kiểm tra đáng giá; và việc tiêm lệnh không được xem trọng – mặc dù bất kỳ tác nhân nào đọc email, xử lý tài liệu hoặc duyệt web đều sẽ gặp phải nội dung được tạo ra một cách thù địch. Sợi chỉ chung là các nhóm này xây dựng cho con đường suôn sẻ và giờ đang khám phá ra rằng sản xuất chủ yếu là những con đường không suôn sẻ. Jentic định vị mình là một lớp thực thi được quản lý nằm giữa các khuôn khổ tác nhân và hệ thống bên ngoài. Lớp trung gian đó thực thi quản trị như thế nào mà không làm chậm các nhà phát triển hoặc giảm tính linh hoạt của tác nhân? Thay vì kết nối một tác nhân với năm mươi API khác nhau – mỗi API có sơ đồ xác thực, giới hạn tốc độ và đặc điểm riêng – nhà phát triển kết nối với một điểm cuối duy nhất. Điểm cuối đó hiển thị các công cụ để tìm kiếm toàn bộ danh mục khả năng API của chúng tôi, tải chi tiết và thực thi bất kỳ lệnh gọi nào. Điều này tối đa hóa tính linh hoạt thông qua một giao diện thống nhất duy nhất cho vô số API, đồng thời cho phép quản trị – tác nhân nào truy cập API nào, trong điều kiện nào, với giới hạn nào – tất cả được quản lý trong nền tảng, không phải trong mã khách hàng. Lớp thực thi là một đường chuyển tiếp; các tác nhân vẫn có thể soạn các quy trình làm việc nhiều bước, chuỗi lệnh gọi và xử lý lỗi một cách linh hoạt. Quản trị mà không có ma sát là khó. Đường tắt là đẩy gánh nặng lên các nhà phát triển. Hạ tầng nên làm điều ngược lại — hấp thụ sự phức tạp đó để các nhà phát triển không phải làm. Với phần mềm độc hại đánh cắp thông tin hiện đang nhắm mục tiêu tích cực vào các tệp cấu hình tác nhân và thông tin xác thực được lưu trữ, ông có thấy những kẻ tấn công chuyển hướng trọng tâm sang hạ tầng AI như một bề mặt tấn công có giá trị cao mới không? Chắc chắn – và logic là rõ ràng. Một tệp cấu hình tác nhân thực chất là một siêu khóa đa dịch vụ: thông tin xác thực cho hệ thống email, CRM, nền tảng thanh toán, API nội bộ và tài khoản GitHub. Một lần chạy phần mềm độc hại đán












