Dựng MCP server đưa security context vào AI agent

1. Đoạn mở đầu: agent xoá database, ai cũng build được

Đây là một tập của AI Security Podcast, trong đó host Ashish Rajan trò chuyện với Prahathess Rengasamy. Theo mô tả video đăng ngày 07/10/2026, Prahathess là Senior Security Engineer tại xAI; thẻ tên trên màn hình ghi "Security, xAI", còn Ashish được ghi là "Co-host, AI Security Podcast".

Video mở bằng một đoạn ghép những câu sẽ xuất hiện lại trong cuộc trò chuyện (video đăng ngày 07/10/2026). Có câu nói rằng AI agent đã từng xoá sạch cả database production. Có câu nói rằng đội security thường nắm toàn bộ quyền admin, ở một số nơi là vậy, nên đó có lẽ là những credential có tác động lớn nhất mà kẻ xấu có thể đánh cắp, hoặc một agent có thể mạo danh, để gây ra thiệt hại thật cho doanh nghiệp. Có câu nói rằng gần như ai cũng build được, không cần phải rành kỹ thuật, chỉ cần có một ý tưởng.

Những câu khác trong đoạn ghép (video đăng ngày 07/10/2026): các phương pháp truyền thống gần như đã bị gạt ra ngoài; pull request là quá muộn để còn nghĩ tới, trong một thế giới mà code đổ về từ mọi phía. Rồi câu trích: "A machine cannot be held accountable, therefore it should not be making a management decision" (một cỗ máy không thể bị buộc chịu trách nhiệm, vì vậy nó không nên đưa ra quyết định quản lý). Một câu kể rằng các agent cứ qua lại với nhau, còn người nói thì ngồi ăn bỏng ngô và xem. Một câu nói rằng chúng thông minh hơn tất cả chúng ta cộng lại, và đây là lúc chúng tệ nhất (this is the worst they'll ever be).

Sau đó Ashish giới thiệu: hãy nói về chuyện build AI platform, "vâng, bạn nghe không nhầm đâu". Làm sao để mở rộng security cho AI trên toàn một tổ chức lớn? Theo Ashish (video đăng ngày 07/10/2026), câu trả lời là dựng một platform mà đội security đã cùng đội engineering rộng hơn tạo ra. Nếu ý đó nghe có vẻ đi trước thời đại, thì cuộc trò chuyện với Prahathess, người anh giới thiệu là senior security engineer ở SpaceX xAI, sẽ rất đáng nghe để hiểu cách tiếp cận security cho agent và chuẩn hoá nó trên toàn tổ chức.

Trong video đăng ngày 07/10/2026, Ashish nêu thêm những câu hỏi của tập: chuyện gì xảy ra khi các team khác nhau, kể cả các team bên trong security như AppSec và CloudSec, bắt đầu tạo agent theo những cách khác nhau? Khi những người không làm kỹ thuật bắt đầu đẩy code vào SDLC (software development lifecycle, vòng đời phát triển phần mềm), thì SDLC trông ra sao? Tất cả những chuyện đó, và nhiều hơn nữa, có trong tập này.

Vào tập chính, Ashish chào mừng khán giả tới với một tập nữa của AI Security Podcast, giới thiệu Prahathess và cảm ơn anh đã quay lại chương trình. Prahathess chào Ashish và nói anh rất vui được quay lại. Ashish mời anh giới thiệu một chút về bản thân, anh đang ở đâu và nền tảng nghề nghiệp của anh là gì.

2. Prahathess là ai, và vòng đời phát triển phần mềm kiểu cũ

Prahathess kể (video đăng ngày 07/10/2026) anh đang làm security engineer ở SpaceX AI. Trước đó anh làm ở Block, Apple và vài nơi khác, chủ yếu tập trung vào product security và infrastructure security. Giờ anh ở cấp độ frontier, nên chuyện xử lý agent và security xoay quanh việc build cho AI là thứ anh đặt lên hàng đầu.

Trong video đăng ngày 07/10/2026, Ashish nói rằng Prahathess đã làm ở những công ty rất đi trước, rất nặng về engineering trong suốt sự nghiệp của mình. Giờ hai người nói tiếp về chuyện hệ sinh thái đã thay đổi thế nào với AI. Để mở đầu, anh nhờ Prahathess nói nhanh trong khoảng 30 giây về vòng đời phát triển phần mềm và tác động mà agent và AI đã tạo ra lên nó, ít nhất là theo cách anh nhìn thấy.

Prahathess nói anh có vài quan điểm khá "cay" (spicy takes). Anh muốn nói rõ trước: mọi ý kiến là của riêng anh, không phản ánh quan điểm của chỗ anh làm, và anh không đại diện cho SpaceX AI. Anh chỉ chia sẻ trải nghiệm của một người đang đứng ở mũi giáo (tip of the spear).

Anh kể (video đăng ngày 07/10/2026) anh đã thấy nhiều vòng đời phát triển phần mềm khác nhau trong sự nghiệp, và gần như ai cũng vậy. Nó bắt đầu với mô hình waterfall, rồi tới agile, và bạn có cả một workflow build và deploy đầy đủ: bạn viết code, đẩy PR, xin approve, một loạt test chạy, rồi bạn deploy lên một môi trường thấp hơn như staging, và nếu mọi thứ ổn thì bạn promote nó lên prod. Ở tầng staging có một quy trình QA, tuỳ mức độ trưởng thành của tổ chức, để chắc chắn mọi thứ đều ổn.

Theo Prahathess, đó là cách mọi người đã rất quen làm, và nó rất phổ biến cho tới khoảng một năm rưỡi trước (tính từ lúc video đăng ngày 07/10/2026). Anh nói có thể hơi mạnh tay, nhưng đại khái là một năm rưỡi tới hai năm trước.

3. SDLC bị nén lại: từ ý tưởng tới production trong một, hai tuần

Rồi bỗng nhiên, theo lời Prahathess (video đăng ngày 07/10/2026), chúng ta bước vào buổi bình minh của một kỷ nguyên mới, nơi LLM trở thành chuyện có thật. Mọi người copy paste code vào các giao diện chat để lấy thêm code, hoặc lấy code đã sửa, rồi thả nó vào dự án. Và nó chạy được, nên người ta nhận ra LLM khá giỏi viết code. Các lab nắm lấy điều đó, và giờ có những model chuyên cho coding, theo anh là "khá giỏi, giỏi tới mức điên rồ" về coding ở thời điểm video đăng ngày 07/10/2026, lại rất nhanh, và bạn có thể chạy năm cái cùng lúc trong khi bạn đang làm một việc khác.

Theo ý kiến của anh (video đăng ngày 07/10/2026), SDLC đã thay đổi ở chỗ nó bị nén lại nhiều hơn trước rất nhiều. Trước đây bạn có product requirement document, design document và đủ thứ tài liệu về việc bạn muốn build một thứ thế nào, rồi một kỹ sư hoặc một team kỹ sư làm việc trên đó để dựng nó lên. Giờ thì bạn có một ý tưởng, bùm, bạn có POC, bạn deploy nó lên môi trường thấp hơn, xem mọi thứ có ổn không, mà đôi khi bước này còn là tuỳ chọn, và nó lên prod trong vòng một tuần, tối đa hai tuần.

Anh tả cảnh đó: "cái feature nhỏ mình vừa build giờ đã được roll out cho hàng triệu người". Có thể họ thích, có thể không. Nếu họ không thích, nó bị bỏ. Nhưng nó đã ở đó rồi. Theo Prahathess (video đăng ngày 07/10/2026), khoảng thời gian từ ý tưởng tới thứ được ship đã bị nén lại rất nhiều, và trên nhiều bề mặt khác nhau.

Trong video đăng ngày 07/10/2026, Ashish hỏi: thay đổi theo nghĩa nào? Có phải vì giờ có những mối đe doạ mới, hay vì chúng ta đang nhìn vào một thế giới hoàn toàn khác? Anh tò mò vì sao Prahathess thấy nó đã thay đổi.

Prahathess giải thích (video đăng ngày 07/10/2026): trước đây chúng ta build mọi thứ bằng con người, và phải giao tiếp qua lại giữa cả đống bộ phận khác nhau. Những người có thể build thứ kỹ thuật như backend và frontend chỉ giới hạn ở các frontend engineer, full stack engineer, hoặc một nhóm người kỹ thuật cụ thể trong công ty.

4. Người không làm kỹ thuật cũng build, và tỉ lệ 1 trên 100

Giờ thì, theo Prahathess (video đăng ngày 07/10/2026), gần như ai cũng build được. Bạn không cần phải rành kỹ thuật mới build được, bạn chỉ cần một ý tưởng. Và đoán xem? Ai trong công ty cũng có ý tưởng cho những thứ mới phục vụ chính công việc của mình, và giờ ai cũng đang build những thứ đó. Nên bạn thấy rất nhiều người build ở quy mô đó. Thêm nữa, đi từ con số không tới một prototype ở máy local không còn mất bao lâu.

Anh kể nhiều công ty anh từng thấy, như các công ty nơi bạn bè anh làm, đã tái tổ chức để hỗ trợ chuyện này. Câu hỏi mà ai cũng đang nghĩ tới, theo anh ở thời điểm video đăng ngày 07/10/2026, là: làm sao đưa một ý tưởng từ con số không lên production thật nhanh trong thế giới của agent.

Trong video đăng ngày 07/10/2026, Ashish hỏi lại: vậy có phải vì giờ những người không làm kỹ thuật cũng đang làm SDLC? Vì đó có vẻ cũng là một chủ đề đang nổi lên.

Prahathess nói đó chính là ý của anh: họ không làm SDLC. Họ build thứ đó và tự tìm cách host nó cho mục đích riêng của mình. Theo anh (video đăng ngày 07/10/2026), bạn thấy rất nhiều internal tool mới ở những chỗ trước đây chẳng có gì, hoặc ở những chỗ trước đây bạn phải đi nhờ một team engineering build cho một tool phục vụ việc của bạn, ví dụ như tuyển dụng. Prahathess nói giờ anh có những trường hợp mà người không làm kỹ thuật đã deploy thứ của riêng họ trong nội bộ, và anh khá chắc anh không phải người duy nhất gặp chuyện này.

Trong video đăng ngày 07/10/2026, Ashish nói anh đồng ý và không ngạc nhiên. Nhưng điều anh thấy đáng chú ý là, khỏi phải nói, bản chất tự chủ (autonomous) của AI agent chắc chắn khiến chuyện này đáng sợ hơn một chút. Anh tò mò: trong những gì Prahathess đang thấy, người ta tiếp cận chuyện này thế nào?

Prahathess nói có nhiều cách. Theo anh (video đăng ngày 07/10/2026), rõ ràng cấm dùng agent sẽ không giúp được ai cả. Với một đội security, quy trình vận hành cốt lõi không đổi: bạn muốn tìm cách gặp những "developer mới" ở đúng chỗ họ đang đứng. Anh gọi là developer mới vì đó không chỉ còn là kỹ sư và developer, mà gần như là mọi chức năng công việc ở thời điểm đó. Nên bạn muốn chắc chắn mình gặp họ ở chỗ họ đang đứng, và truyền đạt policy của mình theo cách hợp lý mà không làm họ chậm lại.

Anh nói thêm (video đăng ngày 07/10/2026): doanh nghiệp đang chuyển động, và trong ngành security đây là chuyện khá bình thường, tỉ lệ giữa số security engineer với số engineer xưa nay luôn tệ. Nó kiểu một trên một trăm, hoặc khoảng đó, cho mỗi service. Giờ thì vẫn là một người đó cho một trăm engineer đang dùng agent, cộng thêm một nghìn người nữa, gần như toàn bộ nhân sự công ty, cũng đang dùng agent để build. Nên theo anh, mở rộng quy mô ở đây bằng những cách tiếp cận thông thường sẽ rất, rất khó.

5. Đưa security policy vào context của agent: hook và MCP server

Cách tiếp cận Prahathess thường nghĩ tới, và cũng là nội dung bài talk của anh ở fwd:cloudsec, là thế này (video đăng ngày 07/10/2026). Trong thời kỳ trước agent, security đã bỏ rất nhiều thời gian để dựng paved road (những "con đường lát sẵn" cho dev đi theo), tạo các secure pattern cho mọi người dùng, hướng dẫn cách xin exception, cách làm X, Y và Z. Ý của anh là đóng gói context đó theo một cách hợp lý để đưa thẳng cho chính agent. Như vậy, trong lúc agent làm task mà developer giao, mà developer ở đây gần như là bất kỳ người dùng nào trong công ty, các security policy của bạn luôn nằm ở vị trí trung tâm trong context của nó.

Theo Prahathess (video đăng ngày 07/10/2026), có nhiều cách để làm việc này. Bạn có thể dùng hook trong các agent đời mới hơn, vì chúng hỗ trợ hook. Bạn cũng có thể làm một server Model Context Protocol (MCP) do chính đội security build và bảo trì, mà agent có thể gọi tới để hỏi kiểu: "Tôi đang build hạ tầng serverless này, có những điều gì về security tôi cần lưu ý?"

Context đó, theo anh (video đăng ngày 07/10/2026), được inject thẳng vào context window của model, và mọi request sau đó đều diễn ra với những điều này nằm sẵn trong đầu nó. Cái hay của cách này là nó là một server phục vụ security policy mà bao nhiêu agent cũng có thể query, bao nhiêu người dùng cũng có thể query, và nó giúp bạn đưa tất cả các policy tới đích rất nhanh.

6. Anti-pattern: bỏ quên preventative controls vì mải chạy theo agent

Trong video đăng ngày 07/10/2026, Ashish hỏi: đó chẳng phải là một thay đổi về mặt tổ chức sao? Anh đoán có lẽ nó giống chuyện xảy ra khi cloud mới hình thành, khi nhiều người nói "chúng ta cần transformation, đừng lift and shift". Vậy anti-pattern với AI agent là gì, mọi người không nên làm gì? Vì theo những gì hai người đã nói, người không làm kỹ thuật đang đẩy code ra, người làm kỹ thuật đang đẩy code ra, và security cũng đang đẩy code ra. Anh kể chính anh cũng đang chạy code ở background trong lúc làm buổi phỏng vấn này.

Trong video đăng ngày 07/10/2026, Ashish nói Prahathess hẳn đã thấy nhiều kiểu, và giống anh, cũng đã ở trong mảng cloud, nên đã thấy cả những cách "thật ra như vậy là không đúng". Anh hỏi: trong hệ sinh thái những người Prahathess nói chuyện cùng, kể cả ở fwd:cloudsec, anh có thấy người ta mắc anti-pattern nào trong cách dùng agent, hoặc trong việc phát triển phần mềm, mà họ không nên làm không?

Prahathess nói một điều anh hay gặp, cả khi nói chuyện với mọi người, là rất nhiều sự chú ý đã dồn sang làm AI security nói riêng (video đăng ngày 07/10/2026). Nhưng định nghĩa thế nào là AI security thì anh hỏi 10 người, nhận về 10 câu trả lời khác nhau.

Theo anh (video đăng ngày 07/10/2026), ở một số nơi, các nền tảng cơ bản theo nghĩa preventative controls (các biện pháp kiểm soát ngăn chặn từ trước) không được chú trọng. Nói bằng ngôn ngữ cloud, đó có thể là service control policies (SCP) hoặc resource control policies, còn trên GCP là organization policies, và bất kỳ preventative control nào khác. Có thể các công ty biết mình vốn không có preventative controls ngay từ đầu, nhưng rồi agent xuất hiện và họ tập trung vào agent. Nên anh thấy ở nhiều nơi người ta đang đánh đổi các foundational controls quanh data security và preventative controls nói chung.

Prahathess coi đó là một anti-pattern lớn hơn (video đăng ngày 07/10/2026). Vì rốt cuộc, bạn có thể đưa security context vào trong agent, bạn có thể sandbox agent theo nhiều cách về mạng, cách ly ở mức hệ điều hành, đủ kiểu. Nhưng khi chúng truy cập các hệ thống thật đang chạy, thì preventative controls mới là thứ cứu bạn. Nên anh sẽ không thoả hiệp bất kỳ preventative control nào. Bất cứ thứ gì chúng ta đã làm trước khi agent tràn tới, về preventative controls, chúng ta vẫn nên tiếp tục làm.

Ở phía detection, anh cũng thấy nhiều bối rối hơn về chuyện identity vận hành thế nào (video đăng ngày 07/10/2026). Chúng ta bắt ai chịu trách nhiệm? Ví dụ một agent thực thi một việc và xoá một resource, hoặc truy cập thứ nó không được phép. Ai chịu trách nhiệm cũng là chuyện mà anh cảm thấy mọi người chưa thật sự nắm được.

Ashish nói thêm: nhất là khi bạn nghe những câu chuyện AI agent đã xoá sạch cả database production (theo các câu chuyện được nhắc trong video đăng ngày 07/10/2026). Mà công bằng mà nói, anh không biết ai, hoặc tại sao, lại tự đặt mình vào tình huống AI agent của mình có thể đẩy code lên production mà không qua review. Anh hỏi: đó có phải cũng là một anti-pattern theo cách so sánh Prahathess vừa nói không?

Prahathess nói đúng là vậy (video đăng ngày 07/10/2026). Như anh đã nói, di chuyển với tốc độ chóng mặt cũng được. Nhưng bất kỳ môi trường quan trọng nào, bất kỳ việc truy cập data quan trọng nào, và bất kỳ thứ gì làm thay đổi trạng thái, những request cập nhật hay xoá một thứ gì đó, tất cả đều cần có người chịu trách nhiệm. Bạn cần một người dùng nói rõ ràng: "tôi cho phép thứ này đi xoá X, Y, Z". Theo anh, câu chuyện đó bắt nguồn từ việc có một identity posture tốt ngay từ đầu. Agent tới nhanh quá, nên rất nhiều người đang chật vật chạy theo cho kịp.

7. Agent dùng identity của bạn, và agent không ai giám sát

Trong video đăng ngày 07/10/2026, Ashish hỏi: vậy có lối thoát nào không? Vì Prahathess từng nhắc với anh về một MCP reference architecture. Anh muốn tiếp cận chuyện này theo hai phần. Phần một là chuyện "Ashish và agent của Ashish" làm đủ thứ việc. Phần hai là agent nằm trong SDLC. Anh hỏi Prahathess thấy gì ở cả hai kiểu.

Trong video đăng ngày 07/10/2026, Ashish giải thích: agent của anh có thể làm nhiều việc, như kiểm tra email của anh, và lúc đó nó không còn là SDLC nữa. Nhưng là người làm security, chúng ta quan tâm cả hai phía. Anh tò mò phía nào khó sửa hơn. Rõ ràng là có MCP ở cả hai phía: anh có thể có một MCP vào AWS, nhưng cũng có thể có một MCP vào Slack của anh hay chỗ nào đó. Anh nhờ Prahathess nói về reference architecture cho MCP từ cả hai góc nhìn, và nó áp dụng được thế nào, hay không áp dụng được.

Prahathess giải thích (video đăng ngày 07/10/2026): MCP reference architecture nói cụ thể về cách bạn đóng gói các security policy của chính tổ chức mình và đưa chúng cho các agent đang làm những chức năng khác nhau. Bạn có thể có những agent dùng MCP với bạn ở trong vòng lặp, như một "trợ thủ" của Ashish kiểm tra email cho anh, trả lời Slack cho anh, đủ thứ. Trong trường hợp đó, identity mà nó dùng sẽ là của bạn. Nó thực sự mạo danh bạn để làm hết những việc đó. Nên chúng ta biết là, trường hợp xấu nhất, rốt cuộc chính bạn là người đã thực hiện thay đổi đó.

Còn nếu bạn nghĩ tới những agent chạy trên cloud, không có người giám sát, thì theo anh (video đăng ngày 07/10/2026) chúng ta bước vào vùng câu hỏi ai chịu trách nhiệm. Anh nhắc câu nói nổi tiếng mà anh gán cho IBM: "A machine cannot be held accountable, therefore it should not be making a management decision". Ashish hỏi lại: "Thật sao?" Prahathess đáp: "Thật đấy."

Prahathess nói nguyên tắc đó không vô ích, nó có tác dụng (video đăng ngày 07/10/2026). Cụ thể, với chức năng bạn muốn agent làm, hãy định nghĩa nó cần làm gì, liệt kê những thứ nó được phép truy cập ở tầng identity và tầng network, rồi ràng buộc nó trong phạm vi đó. Theo anh, đó là cách làm đúng.

8. Pull request quá chậm cho năm agent chạy song song

Trong video đăng ngày 07/10/2026, Ashish nói "Okay", rồi bảo có lẽ đáng nói rõ điều này. Có quá nhiều cuộc bàn tán về AI security và các loại lỗ hổng khác nhau, nên đôi khi khó chỉ ra đúng vấn đề. Anh có thể nói: "tôi đã có SCA, SAST và mọi thứ khác trong SDLC rồi, sao nó lại không hiệu quả trong trường hợp này?" Kiểu như anh Bob bên kế toán thử đẩy cái gì đó vào code, thì anh đã có guardrail trên GitHub, GitLab, đã có SCA, SAST và mọi thứ khác. Kể cả nếu AI của anh viết code, nó vẫn phải đi qua những thứ đó. Hay là chuyện đó cũng đang thay đổi, kiểu "khoan đã, ranh giới ở đó cũng đang mờ đi"?

Prahathess xác nhận ranh giới ở đó cũng đang mờ đi (video đăng ngày 07/10/2026). Nếu bạn nghĩ kỹ: khi bạn tạo một PR và tất cả các tool này chạy, nó thêm khoảng năm, mười phút vào thời gian chờ PR của bạn. Rồi bạn được review, và bạn phải sửa những gì cần sửa. Nhưng anh đang làm việc với năm agent cùng lúc, mỗi agent làm task riêng của nó, và phải chờ mười phút.

Ashish hỏi: "Thật à?" Prahathess nói đúng vậy, trên mọi repo: nếu anh có một danh sách việc cần làm, những việc được định nghĩa rất rõ, thì ở thời điểm video đăng ngày 07/10/2026 anh có thể làm chúng song song.

Theo Prahathess (video đăng ngày 07/10/2026), khi các agent đi tạo PR, giờ bạn thật sự có thể cho agent "trông" (babysit) PR. Anh nói đó là một feature của Cursor, và cả Grok Build cũng có. Chúng trả lời comment, sửa, rồi đẩy lên. Nên ranh giới đang mờ đi, vì những thứ đang phản hồi các finding của bạn cũng không còn là con người nữa. Chính agent đang phản hồi các finding đó.

Anh kể một chuyện khá buồn cười (video đăng ngày 07/10/2026): anh có một repo cá nhân, nơi anh đang thử Bugbot. Bugbot là thứ sẽ comment phàn nàn trên PR của bạn rằng "bạn có tất cả những bug này". Và anh có một thứ khác cũng trông PR. Thế là Bugbot phàn nàn về một thay đổi mà Grok Build hoặc OpenCode đã làm, rồi thứ kia lại đi sửa nó. Các agent cứ qua lại với nhau như vậy, còn anh thì kiểu ngồi lấy bỏng ngô ra xem.

Một người trong hai nói tiếp (video đăng ngày 07/10/2026) rằng chúng gần như đang có cả một "AI governance council" (hội đồng quản trị AI), duyệt qua nhau, cứ đi vòng vòng giữa chúng, kiểu như "PewDiePie AI council". Prahathess nói xem cũng hơi buồn cười.

9. Đưa phản hồi security vào lúc agent đang chạy ở máy local

Nhưng theo Prahathess (video đăng ngày 07/10/2026), các tool dùng cho security cũng cần nhanh lên. Anh thà không làm việc này ở giai đoạn PR. PR là thứ bạn tạo ra giữa chừng quy trình: bạn đã xong các thay đổi ở local, rồi bạn tạo PR, rồi bạn mới phát hiện có gì đó không ổn. Anh muốn bắt được nó sớm hơn nhiều, ngay khi agent đang làm việc.

Anh lấy ví dụ (video đăng ngày 07/10/2026): giả sử bạn đang build một web app mới mà bạn muốn expose theo một cách nhất định. Nếu agent biết cách làm việc này, biết những library nào được phép dùng, những tool nào cần chạy ở local, thì nó có thể tự chạy ở local và tự sửa. Trong lúc bạn chờ task hoàn thành, agent có thể chạy những thứ này song song và có vòng phản hồi ngay trong lúc đang build, thay vì đi trông một PR.

Prahathess nói vẫn có một số vấn đề về business và logic mà bạn có thể gặp, nơi những thứ kiểu Bugbot trong GitHub repository và pull request vẫn có tác dụng (video đăng ngày 07/10/2026). Nhưng nếu bạn muốn hỗ trợ tốc độ, và cũng muốn có security ở tốc độ đó, thì việc đẩy chuyện này lên tận agent, nói cho nó biết cần để ý gì về mặt security tuỳ theo loại task bạn đang làm, theo anh là hoàn toàn đáng làm.

Trong video đăng ngày 07/10/2026, Ashish nói điều đó khiến anh nảy ra rất nhiều câu hỏi. Anh luôn nghĩ rằng cách duy nhất chúng ta làm được trước đây, và cách mà AppSec nói chung dạy chúng ta, là shift left, là DevSecOps. Người ta bảo chúng ta rằng IDE sẽ nhắc bạn. Hệ sinh thái lý tưởng nhất có lẽ là chính IDE chặn anh không cho đưa vào thứ gì có vấn đề về security. Anh hỏi: điều đó còn khả thi không? Vì nó đã không thực sự xảy ra trong AppSec, và anh chắc là dân AppSec...

Prahathess cắt vào, nói để anh giải thích. Anh nói anh cũng đã thấy chuyện đó (video đăng ngày 07/10/2026). Mỗi khi bạn nói "đây là tất cả những gì IDE cần làm cho bạn", thì người phải phản hồi lại nó trước đây là một con người, với context có hạn, năng lượng có hạn, thời gian có hạn để xử lý. Theo Prahathess, chính giới hạn đó là thứ agent gỡ bỏ.

Anh lấy ví dụ (video đăng ngày 07/10/2026): có những thứ tốt cho Terraform, như một extension cho IDE sẽ gắn cờ mọi thay đổi Terraform không ổn mà bạn làm, chẳng hạn khi bạn không có trust relationship đúng, và bạn có thể nối IDE của mình với nó. Còn các lỗi linter thì agent tự động sửa luôn. Nên giới hạn về khả năng tập trung của con người, cộng với cả danh sách việc bạn cần làm xong để chuyển sang việc khác, chính là thứ agent hoàn toàn giải phóng bạn khỏi.

10. CloudSec và AppSec còn tách nhau không, và build hay buy

Theo Prahathess (video đăng ngày 07/10/2026), có nhiều cách, nhưng nếu nghĩ kỹ thì rốt cuộc mọi thứ quy về một câu hỏi: trong cách làm việc mới này, làm sao bạn giải thích cho agent trạng thái tốt lý tưởng là gì, và làm sao đảm bảo mọi thay đổi nó tạo ra đều tuân thủ. Nếu không tuân thủ, thì ít nhất phải có một exception cho nó.

Trong video đăng ngày 07/10/2026, Ashish hỏi: vậy có phải ranh giới giữa CloudSec và AppSec cũng đang mờ đi? Anh lùi lại một bước: hai người đã nói về SDLC, về MCP, về chuyện người không làm engineering cũng tạo ra code. Nên các phương pháp truyền thống gần như đã bị gạt ra ngoài; pull request là quá muộn để còn nghĩ tới, trong một thế giới mà code đổ về từ mọi phía. Trong cách các tổ chức thường vận hành, anh từng ở một team có CloudSec riêng, AppSec riêng, mỗi bên tập trung vào những thứ khác nhau.

Trong video đăng ngày 07/10/2026, Ashish hỏi tiếp: AI có đang khiến chúng ta thách thức lối mòn, nơi một người với một bộ kỹ năng cụ thể chỉ đủ cho cloud? Hay anh có thể làm cloud, làm cả AppSec, vì chính anh cũng là người tạo ra code? Như Prahathess nói anh chạy năm agent ở background, thì Ashish cũng đang làm tất cả những việc đó, với tư cách một người không phải coder, tự mình làm. Anh hỏi Prahathess có thấy cách làm security trong tổ chức đang thay đổi không, và thay đổi đó là gì, để những người đang nghe hoặc xem, có thể chưa thấy nó, chưa làm việc với frontier model, có lẽ vẫn ở giai đoạn đầu, nơi họ có ChatGPT, hiểu được.

Ashish tả giai đoạn đó (video đăng ngày 07/10/2026): ở đầu cuộc trò chuyện, Prahathess nói mọi người dùng chat để trò chuyện với AI. Anh có thể bảo AI của mình "tôi muốn build một, chẳng hạn, đề xuất bán hàng", và nó build ra một ứng dụng đẹp, cho anh cảm giác đã build được một single page app, rồi anh muốn đưa nó cho mọi người khác dùng. Vậy định nghĩa cách chúng ta làm security có cần tiến hoá ở cấp tổ chức không? Anh nói Prahathess đang ở một frontier lab, nơi có lẽ không phải chuẩn chung, mà là một thái cực. Nếu quay lại các công ty trước của anh, hoặc những công ty kiểu đó, thì mô hình làm security cũ có còn hiệu quả không, nếu AI mở rộng như cách nó đang mở rộng ở khắp nơi?

Prahathess nói, như anh đã đề cập, các foundational preventative controls bạn có trên toàn tổ chức vẫn là thứ cứu bạn (video đăng ngày 07/10/2026). Theo Prahathess, có một security policy tốt và định nghĩa "known good" (trạng thái tốt đã biết) trông thế nào, với threat model riêng của tổ chức mình, là việc không có đường vòng. Bạn cần có nó làm nền móng thì mới cho phép việc áp dụng AI an toàn được.

Một điều thú vị, thật sự nảy sinh từ chuyện này, theo Prahathess (video đăng ngày 07/10/2026), là các quyết định build hay buy thay đổi hoàn toàn. Trước đây, khi bạn cân nhắc mua một tool cho việc này, hoặc build một tool trong nội bộ rồi gánh việc bảo trì nó về sau, và thay đổi cách mình vận hành dựa trên tool đó. Giờ thì các đội security cũng được trao khả năng ngang như vậy để build nhiều paved road hơn, nhanh hơn rất nhiều.

Anh lấy ví dụ (video đăng ngày 07/10/2026): nếu bạn đã có threat model và đã định nghĩa known good, giả sử công ty bạn không chạy infrastructure as code mà toàn là click ops, hoặc bạn cần một cách tốt để làm container security, như base image và những thứ tương tự. Trước đây việc đó mất rất nhiều thời gian và công sức của từng người. Giờ gần như toàn bộ khía cạnh kỹ thuật của vấn đề đã được giải quyết, hoặc tự động hoá được.

Vấn đề thật sự bạn cần tập trung, theo anh (video đăng ngày 07/10/2026), là: làm sao truyền đạt nó ra ngoài, làm sao đảm bảo mọi người dùng nó. Nếu có một paved road mà bạn tuyệt đối phải đi theo, như dùng một internal artifact registry hay thứ tương tự, thì làm sao buộc mọi người dùng nó? Truyền đạt, đưa deadline, thực thi, và đảm bảo mọi người cảm thấy được hỗ trợ. Phần build nó ra thì đã được lo rồi, nên bạn có thể làm nhiều việc kiểu này hơn.

Prahathess nói thêm (video đăng ngày 07/10/2026): build một thứ như một internal security platform, kiểu một security hub, trước đây là việc khó, vì bạn phải có những security engineer biết build và host, gần như là kỹ sư phần mềm luôn. Giờ thì nếu bạn có ý tưởng đó, bạn cứ làm và deploy, vì bạn biết thế nào là tốt cho một internal app. Nên anh nghĩ mọi người cần bắt kịp; nếu chưa làm, anh sẽ nghiêm túc khuyên họ nghĩ lại và tự hỏi: những tool nào tôi ước mình có trong nội bộ mà tôi có thể build ngay bây giờ? (lời khuyên trong video đăng ngày 07/10/2026)

11. Giết bảng Excel: một bot giải thích lỗi 403

Trong video đăng ngày 07/10/2026, Ashish nói Prahathess vừa chạm tới một điều rất thú vị. Ngay cả với cybersecurity nói chung, trước thời AI, từng có cả một cuộc bàn luận: bạn có thể mua tool trong ngành, từ bất kỳ vendor bên thứ ba nào, nhưng lần nào chúng ta cũng vẫn phải thêm một lớp ở trên. Lớp đó kiểu: "high, low, medium gì đó, cái này với tôi không thật sự là high". Rồi với vai trò một người lãnh đạo, bạn phải tổng hợp nó thêm nữa để nói "cloud security posture của tôi là thế này", và đây là thông tin chính xác mà bạn phải tự tay đi qua hết.

Trong video đăng ngày 07/10/2026, Ashish cảm thấy, theo những gì Prahathess nói, việc đó giờ có thể làm bằng AI agent và AI. AppSec cũng vậy: với cả hệ sinh thái ứng dụng anh từng phải theo dõi, giờ anh có thể hỏi "lớp lỗ hổng nào mà nếu tôi giải quyết, 80% số vấn đề của tôi biến mất?" Những câu hỏi kiểu đó trước đây là: "tôi không dùng tool cho việc này được, tôi phải build một thứ, nên tôi bị giới hạn, tôi phải mở một bảng Excel". Anh hỏi Prahathess có nghĩ đó về cơ bản là vấn đề giải quyết được ở thời điểm đó không.

Prahathess nói việc này thậm chí có thể giết luôn các bảng Excel trong cybersecurity (video đăng ngày 07/10/2026). Cả hai cùng cười. Anh nói anh khá chắc là được, và đưa ra một ví dụ rất hay.

Ví dụ của anh (video đăng ngày 07/10/2026): giả sử bạn bị một preventative control chặn, có thể là admission control của Kubernetes, hoặc SCP, hoặc organization policy, và nó trả về cho bạn một lỗi 403 kiểu "policy này đang chặn, bạn không được phép làm việc này". Trước đây, bạn sẽ chụp màn hình hoặc copy lỗi ra, thả vào Slack hay đâu đó, rồi hỏi một security engineer hoặc một kênh: "này, sao tôi bị chặn việc này?"

Theo Prahathess (video đăng ngày 07/10/2026), không có vendor nào ở thời điểm đó làm việc này, vì xây cả một công ty xoay quanh việc giải thích cho mọi người vì sao họ bị chặn thì không sinh lời. Nên đây là những tool sẽ không ai khác build để bạn mua về. Nhưng về trải nghiệm người dùng, nó là một tool rất hay, rất vui để một security engineer có. Nó thậm chí có thể chỉ là một Slack bot nói kiểu: "bạn đang bị policy này chặn, vì có lẽ bạn đã deploy với cấu hình sai này; bạn có lẽ cần đổi giá trị này, hoặc đi nộp đơn xin exception; đây, để tôi kéo một người vào".

Theo anh (video đăng ngày 07/10/2026), đây đều là những thứ bạn có thể build ngay. Không ai build nó cho bạn cả, nhưng về trải nghiệm người dùng và trải nghiệm developer, nó tạo ra rất nhiều giá trị. Họ biết vì sao họ bị chặn, họ biết cách sửa là gì, nếu không thì họ biết cần nói chuyện với ai. Ở hầu hết các công ty anh từng làm, theo Prahathess (video đăng ngày 07/10/2026), việc đó sẽ loại bỏ ít nhất 25 tới 30 phần trăm số request lặp đi lặp lại bạn nhận qua Slack, những thứ khiến bạn phải chuyển ngữ cảnh.

Anh nói đó chỉ là một ví dụ, và anh chủ yếu nói từ trải nghiệm của mình (video đăng ngày 07/10/2026). Nhưng nếu bạn lấy nó và áp vào các ngành khác, và vào compliance, ví dụ bạn phải đi qua HIPAA, hoặc có các yêu cầu compliance PCI, rồi bạn đưa các yêu cầu compliance đó cùng context của môi trường cho agent, thì nó sẽ không làm gì không tuân thủ các yêu cầu bạn có. Nếu bạn lấy cách tiếp cận này và áp vào nhiều lĩnh vực khác nhau, theo anh nó gần như vẫn chạy được.

12. Không cần rành kỹ thuật: dùng AI như một copilot trước

Trong video đăng ngày 07/10/2026, Ashish nêu câu hỏi tiếp theo: làm sao để bắt đầu dùng AI cho security? Vì nhiều người nghe những gì Prahathess vừa nói sẽ nghĩ: "trời, tôi không rành kỹ thuật", hoặc "anh ấy nghe có vẻ là người rất giỏi", hoặc "tôi chỉ là người xưa nay luôn dùng một tool, một sản phẩm cho việc này", trong bất kỳ hệ sinh thái sản phẩm nào bạn muốn chọn.

Trong video đăng ngày 07/10/2026, Ashish nói lý do anh nêu chuyện này là vì lập luận ở phía bên kia, của hệ sinh thái vendor, là: "không đời nào bạn build được cái này, vì bạn phải bảo trì nó, phải tưới cây, phải làm đủ thứ với nó". Với anh, điều đó đúng ở một mức độ, rõ ràng nếu bạn làm bất kỳ tool nào trong nội bộ thì bạn phải build và bảo trì nó. Anh hỏi Prahathess nghĩ gì về chuyện mọi người nên tiếp cận build hay buy thế nào, cụ thể với những thứ mà bạn biết vendor sẽ không bao giờ làm vì không có tiền trong đó.

Trong video đăng ngày 07/10/2026, Ashish nói tiếp: nhưng bạn có sức mạnh của AI trong tay. Vậy có cần rành kỹ thuật mới làm được không? Có workflow thật nào nữa, như ví dụ "vì sao tôi bị chặn" rất hay vừa rồi? Anh muốn có thêm ví dụ về build hay buy để mọi người tự tin rằng họ không cần giỏi như Prahathess mới build được một AI agent.

Prahathess đáp, có một điều anh muốn nói: gần như mọi frontier model ở thời điểm video đăng ngày 07/10/2026 đều thông minh hơn Prahathess. Chúng thông minh hơn tất cả chúng ta cộng lại. Cả hai cùng cười. Anh nói đó là mục tiêu mà chúng ta đang hướng tới, và đây là lúc chúng tệ nhất (this is the worst they'll ever be).

Nên, theo Prahathess (video đăng ngày 07/10/2026), một là bạn hoàn toàn không cần rành kỹ thuật. Bạn chỉ cần hiểu thế nào là tốt và có một ý tưởng. Một điều anh khuyên, và anh đã làm vậy với cả bố mẹ mình, những người rất không rành kỹ thuật: bước đầu tiên là dùng nó như một copilot.

Cách làm Prahathess khuyên (video đăng ngày 07/10/2026): cứ dùng nó cho công việc hằng ngày của bạn, và hỏi xem nó sẽ giải quyết thế nào một vấn đề mà bạn đang giải quyết mỗi ngày. Nếu bạn làm vậy trong khoảng một, hai tuần, bạn sẽ có một cái nhìn khái quát: nó giỏi ở đâu, ở đâu bạn có lẽ cần nhảy vào để chỉnh hướng, và việc gì có lẽ bạn cần tự làm hoàn toàn.

Anh chia thành ba mức (video đăng ngày 07/10/2026): những việc bạn có thể giao hẳn cho nó; những việc bạn có thể giao cho nó nhưng phải để mắt tới; và những việc bạn phải tự làm, với một chút trợ giúp từ copilot. Nên hãy dùng nó như một copilot và tìm các pattern xuất hiện, những việc giống nhau mà bạn giải quyết đi giải quyết lại. Những thứ đó có thể tự động hoá được, có thể thành một workflow, hoặc chỉ là một tool nằm đâu đó. Tuỳ mức độ trưởng thành của platform nơi bạn làm, bạn có thể tìm cách deploy nó trong nội bộ để người khác cũng dùng được.

Prahathess lấy ví dụ (video đăng ngày 07/10/2026): nếu bạn làm AppSec và đang bị dội bom bởi các alert bug bounty, thì nói thật, tầng triage đầu tiên có thể là một AI agent có context của chính codebase đó. Anh nghĩ ngay cả các bug bounty platform cũng cần thiết kế lại kiến trúc xoay quanh việc AI tìm bug và triage bug.

Nói chung, theo anh (video đăng ngày 07/10/2026): dùng nó như một copilot, tìm ra các workflow bạn làm gần như thường xuyên, xác định nó giỏi gì và không giỏi gì trong context của bạn, rồi tự động hoá mọi thứ nó hoàn toàn giỏi và bạn có thể giao, và biến cái đó thành một pattern người khác cũng dùng được. Theo anh như vậy là gần như ổn. Đó là điều anh đang cho bố mẹ mình làm.

13. Paved road giờ trông như một API: identity, data và catalog

Trong video đăng ngày 07/10/2026, Ashish nói thú vị, anh sẽ quay lại chuyện này vì nó làm anh nghĩ tới một thứ khác. Chuyện pattern rất đáng chú ý, vì trong suốt hệ sinh thái build hạ tầng cloud, chúng ta đã dựng cả khái niệm paved road. Ý tưởng là chúng ta bắt đầu với EC2, máy ảo, rồi sang container, Kubernetes. Giờ anh cảm thấy Kubernetes vẫn là chuẩn chung, kể cả với các workload AI.

Trong video đăng ngày 07/10/2026, Ashish hỏi tiếp: có rất nhiều hệ sinh thái AI đang được tạo ra bên ngoài paved road. Anh sẽ không nêu tên công ty, nhưng có rất nhiều công ty cho phép bạn host ứng dụng AI bạn đang dùng. Nó cho bạn ảo giác là bạn đang chạy một AI agent, nhưng về mặt kỹ thuật đó không phải hạ tầng của bạn, không phải production, nói nôm na là vậy. Vậy mọi người nên tiếp cận những hạ tầng hoàn toàn mới, hoặc phức tạp, ra sao, nơi bạn có Kubernetes nói chuyện với một LLM, nói chuyện với không biết còn những thứ gì người ta thêm vào? Nên bảo mật nó, hoặc nhìn vào security của nó thế nào?

Prahathess nói paved road phần lớn vẫn có tác dụng (video đăng ngày 07/10/2026). Paved road trước đây giống như các tài liệu: làm cái này, làm cái kia, đây là module cho bạn. Ashish thêm: theo một nghĩa nào đó là một policy document. Prahathess nói tiếp: hoặc "đây là một pattern cho bạn". Có tiếng nói tiếp: hoặc "đây là template của tôi, cứ deploy template đó là bạn ổn".

Theo Prahathess (video đăng ngày 07/10/2026), giờ thì chúng trông giống một API, vậy thôi. Nghĩa là bạn có thể function call để lấy thông tin đó đưa cho agent, và agent làm theo. Nên với paved road, những paved road đang có vẫn dùng được: chỉ cần bọc chúng trong một API và expose cho agent để chúng cũng hiểu và dùng được paved road của bạn.

Còn để chúng hoạt động trong những môi trường phức tạp, Kubernetes, multi-cloud, thì theo anh (video đăng ngày 07/10/2026) nền móng luôn là thứ cứu bạn. Nắm rõ data và identity sẽ giúp được rất nhiều. Ý anh là: nếu bạn có cả đống người dùng được cấp quyền quá mức đang chạy agent để thực hiện thay đổi, thì chắc chắn mọi chuyện sắp tệ đi. Vì chính những người dùng đó đã được cấp quá quyền, câu chuyện identity chưa được giải quyết, và nếu họ chạy agent, agent mạo danh họ nên nhận luôn identity đó.

Về phía data, theo Prahathess (video đăng ngày 07/10/2026), identity và data gần như đi đôi với nhau. Bạn muốn có một bản kiểm kê xem dữ liệu nhạy cảm nằm ở đâu, "crown jewels" của bạn ở đâu. Ví dụ bạn có một bucket chứa PII và bạn có yêu cầu lưu trữ (retention) cho compliance. Hãy ghi chép chúng lại, có các data security baseline tốt: gắn nhãn, annotate chúng, biết chúng được đặt ở đâu, có một catalog. Anh nói có công ty có, có công ty không, tuỳ vào mức độ trưởng thành.

Anh kể (video đăng ngày 07/10/2026) thứ catalog này trước đây anh từng thấy là spreadsheet, rồi các hệ thống được build xoay quanh nó, như những website nơi bạn đưa vào một dataset và nó cho bạn biết trong đó có loại dữ liệu gì. Cách làm hiệu quả ở đây là kéo thứ đó vào context của agent. Kiểu: "catalog này có API. Bất cứ khi nào bạn làm gì đó, tương tác với dữ liệu, hãy đảm bảo bạn không đụng tới các data resource có những annotation cụ thể này", ví dụ có tên, email (PII) và những thứ tương tự, "bạn không được tương tác với nó". Bùm. Xong.

Nhưng theo anh (video đăng ngày 07/10/2026), gốc của chuyện này là bạn phải có một identity posture và một data posture tốt ngay từ đầu. Việc bạn làm ở chặng cuối, với agent trong môi trường của bạn, chỉ là expose nó cho agent. Trong Kubernetes, đó có thể chỉ là namespace label hoặc resource label ghi "off limits to agents" (agent không được đụng vào). Và những thứ này mặc định đều query được, vì bạn có một API tuyệt vời. Đó là cách anh sẽ tiếp cận: đảm bảo annotate mọi thứ. Theo anh, các nền tảng cơ bản rất khó né, có agent hay không cũng vậy.

Thứ duy nhất có lẽ cần nghĩ kỹ hơn nhiều, theo Prahathess (video đăng ngày 07/10/2026), là làm sao cách ly ở mức hệ điều hành, và làm sao đảm bảo các egress control được giữ nguyên, vì agent thực hiện rất nhiều lời gọi ra và vào. Anh nói đó là góp ý nhỏ của anh về chuyện này.

14. Mở rộng ra cả tổ chức: dựng một platform

Ashish hỏi: chuyện này chạy ở quy mô lớn thế nào? Vì security có chuyện agent của từng người và chuyện nhiều agent. Anh và Prahathess có thể ở cùng một team, anh có bộ agent của anh, Prahathess có bộ agent của mình. Anh nói (video đăng ngày 07/10/2026) anh đồng ý 100% rằng paved road từng hiệu quả với hạ tầng cloud vì chúng ta có template để phát ra. Giờ nó là một API. Có lẽ điều này quay lại chuyện anh nói về security trong hệ sinh thái này: chúng ta có cần nghĩ lại về cách tạo paved road từ nay về sau không, và như Prahathess nói, chúng nên là API.

Ashish hỏi tiếp: làm sao mở rộng thứ đó ra toàn một tổ chức lớn, để thấy "vâng, cái này đang thật sự hiệu quả, mọi người thật sự quan tâm làm theo", rồi dùng phần chênh lệch để tìm ra chỗ nào chưa hiệu quả và tập trung sự chú ý vào đó? Anh kể (video đăng ngày 07/10/2026) hầu hết các tổ chức anh đang nói chuyện cùng chỉ có một hoặc hai team thật sự dùng AI, chưa mở rộng ra cả tổ chức. Anh hình dung các công ty đi trước có lẽ đang thử, và một số đã làm được. Prahathess nghĩ gì về việc mở rộng những thứ này ở cấp tổ chức?

Prahathess nói, với các công ty đang dẫn đầu chuyện này, có một điều anh nghĩ hoàn toàn đáng nêu ra (video đăng ngày 07/10/2026): ví dụ Perplexity đã làm rất nhiều việc về agent tập trung vào security cho sản phẩm computer của họ, và anh rất thích nó. Theo anh, các công ty đi đầu đang build hạ tầng riêng cho việc này, nơi bạn có thể chạy cloud agent một cách an toàn, nghĩa là có egress control, có proxy để điền credential vào, đủ thứ. Và bạn không chạy chúng trên máy của mình; bạn chạy chúng trên một cloud khác.

Về chuyện mở rộng quy mô, theo Prahathess (video đăng ngày 07/10/2026), nó giống cách chúng ta đã mở rộng Kubernetes, cách chúng ta mở rộng cho thế giới cloud native: chúng ta dựng một platform xoay quanh nó. Một khi bạn dựng platform xoay quanh nó, nó cho bạn một con đường tập trung, một paved path, ở đây là một "meta paved path", để dùng những thứ này. Và chúng ta có thể nhúng các nguyên tắc security vào platform để đảm bảo nó an toàn.

Theo anh (video đăng ngày 07/10/2026), khi ngay cả một công ty 10.000 người dùng nó và đi theo cách tiếp cận dựa trên platform này, chúng ta biết nó an toàn. Anh sẽ có khả năng nhìn thấy những thứ không đi theo, hoặc được miễn trừ (exempted), và ít nhất có thể phản ứng với chúng, xử lý sự cố hoặc bất kỳ vấn đề security nào có thể xảy ra.

Nên, theo Prahathess (video đăng ngày 07/10/2026), mở rộng quy mô chỉ có nghĩa là bạn cần nghĩ kỹ hơn một chút, thay vì chỉ nói "bạn muốn dùng gì thì dùng, dùng thế nào cũng được". Bạn nói: "đây là một team đã nghĩ kỹ về chuyện này, đang làm cùng security để build một platform cho bạn dùng". Nó được nối vào toàn bộ context nội bộ của chúng ta, vào mọi hệ thống, mọi tool nội bộ chúng ta đã có. Và giờ đây nó là một platform. Nên chúng ta sẽ mở rộng nó theo đúng cách mà có lẽ chúng ta đã mở rộng cho cloud: dựng một platform xoay quanh nó.

15. Agent không phải Terminator: loại coding và loại hỏi đáp

Trong video đăng ngày 07/10/2026, Ashish nói thú vị, rồi hỏi: điều đó có còn đúng với agent không? Anh xin lỗi vì cứ nhắc đi nhắc lại chuyện này, vì anh thấy chắc chắn mọi người hiểu sai về AI agent. Mỗi lần anh nói "AI agent", anh khá chắc một số khán giả của anh nghĩ tới Terminator, nghĩ thứ này tự chủ, trôi nổi khắp nơi. Họ thậm chí không nhận ra có những cách để sandbox agent, có những cách đặt giới hạn cho việc agent tự nó có thể làm, những con đường nó có thể đi.

Trong video đăng ngày 07/10/2026, Ashish nói anh đã nói về chuyện này đủ nhiều rồi, nhưng muốn nghe Prahathess: nếu bạn build một platform AI security, à không phải AI security, cứ nói là một AI platform trong tổ chức để deploy AI agent ở quy mô lớn trên toàn doanh nghiệp, thì có quản lý được nó và có các security control được không? Nó sẽ không phải kiểu "autonomous agency", ném thêm vài buzzword AI vào, kiểu một trang trại AI agent tự làm việc của chúng trong tổ chức.

Prahathess nói nếu đó là một platform, nó sẽ đi kèm những giới hạn hợp lý cho doanh nghiệp (video đăng ngày 07/10/2026). Và theo anh, đáng nói rõ AI agent nghĩa là gì. Nói rất đơn giản hoá, nhìn chung có hai loại. Loại thứ nhất là agent kiểu coding: chức năng chính của nó là làm việc với repository, viết code, build cho bạn, deploy cho bạn, làm việc với các hệ thống kiểu engineering để hoàn thành một task.

Loại còn lại là agent kiểu hỏi đáp (Q&A). Anh vẫn gọi chúng là agent, vì theo anh (video đăng ngày 07/10/2026) phần lớn UX của chatbot giờ cũng đã trở nên agentic ở phía sau. Chúng có thể query nhiều nguồn dữ liệu để đưa cho bạn một câu trả lời, và chúng đang query bằng identity của bạn. Các nguồn dữ liệu đó có thể chứa những thứ nhạy cảm mà bạn không biết.

Theo Prahathess (video đăng ngày 07/10/2026), chuyện platform anh vừa nói thuộc về nhóm coding agent: những agent viết code, tương tác với hạ tầng, ứng dụng và các hệ thống nội bộ. Còn những agent kiểu chatbot thì về cơ bản không tự chủ; chúng tồn tại để trả lời câu hỏi của bạn, hoặc làm copilot cho bạn. Bảo vệ chúng nghĩa là identity của bạn đã được giải quyết: bạn biết chính bạn là người đang gửi request.

Sau đó, theo anh (video đăng ngày 07/10/2026), bạn có thể có hook và các tính năng native khác của platform; security MCP vẫn dùng được. Với các tính năng native được expose của những tool này, tất cả đều có metric OpenTelemetry cho bạn biết ai đã truy cập cái gì, khi nào, và bạn build xoay quanh đó như một tool để có preventative control và detective control.

Còn với kiểu "co-work", những kịch bản mà agent thực hiện hành động thay mặt người dùng trên trình duyệt và mọi thứ tương tự, theo Prahathess (video đăng ngày 07/10/2026) chuyện đó vẫn còn bỏ ngỏ, tương đối khó bảo vệ hơn. Nếu bạn có thể giới hạn agent trong một trình duyệt bị giới hạn, như Island hoặc Chrome Enterprise, nơi mọi thứ đều có MDM và bị giới hạn những gì được làm và không được làm, thì theo anh đó là một cách tiếp cận tốt.

Nhưng nhìn chung, theo anh (video đăng ngày 07/10/2026), có hai loại, hỏi đáp và coding, và nhìn chung loại coding có tác động rộng nhất. Nên build một platform sẽ thực sự mở đường cho công ty. Kiểu co-work vẫn còn mới, và cần nghĩ rất nhiều về cách chúng ta sẽ build những ứng dụng mà agent kiểu co-work có thể dùng.

16. Đọc hay thay đổi, và chặn MCP bằng cách chặn API

Trong video đăng ngày 07/10/2026, Ashish kể một ví dụ anh đã làm, trong lúc đủ loại agent khác đang được tạo ra: anh có một agent chỉ để query AWS xem những S3 bucket nào đang mở ra internet. Anh nói đó là ví dụ đã đơn giản hoá rất nhiều so với thứ anh deploy. Anh hỏi: Prahathess sẽ xếp nó vào nhóm coding agent hay nhóm chat? Về mặt kỹ thuật, anh vẫn đang nói chuyện với nó.

Có tiếng đáp (video đăng ngày 07/10/2026): nó có thể thuộc nhóm nào cũng được, cả hai loại đều trả lời được, nó có thể là cả hai. Có tiếng nói tiếp: phần "coding" chỉ là chức năng của nó, có thể nó chạy ở background.

Prahathess nói anh sẽ đo bằng các hành động không phải đọc (video đăng ngày 07/10/2026): những việc agent đang tạo ra thay đổi, so với việc chỉ đọc thứ gì đó cho bạn. Nếu chỉ đọc cho bạn, thì hai loại như nhau, chúng chỉ đọc thôi.

Ashish tóm lại (video đăng ngày 07/10/2026): vậy là cập nhật, xoá, tạo mới, những kiểu đó. Chỉ đọc thì là chat của bạn, làm gì cũng được, miễn là bạn không đọc thứ gì nhạy cảm. Còn bất cứ thứ gì là hành động sửa đổi, tạo mới, thì đó là chỗ bạn thật sự phải chú ý.

Prahathess đồng ý: "Exactly." Và theo anh (video đăng ngày 07/10/2026), cách nhìn này có một giả định ngầm: bạn không dễ dàng cấp quyền cho mọi người vào những thứ họ không được phép đọc.

Trong video đăng ngày 07/10/2026, Ashish nói đó là một ý hay và đáng nói rõ, vì nó quay lại chuyện MCP Prahathess nói lúc trước. Anh có quyền truy cập vào rất nhiều MCP, và nếu muốn anh có thể tự tạo MCP của riêng mình. Có giới hạn được chuyện đó không? Có giới hạn được những MCP nào anh được truy cập không? Đó có phải là chuyện của MDM không?

Prahathess giải thích (video đăng ngày 07/10/2026): MCP chỉ là lớp bọc quanh API. Bạn có thể đặt các lệnh chặn lên những API nào được truy cập. Ashish nói lại theo ý đó: nếu, chẳng hạn, Meta là một API bị chặn, thì MCP cho Meta sẽ không chạy, vì nó vẫn sẽ cố đi tìm nó trên internet. Prahathess nói nó sẽ bị chặn ở tầng network. Ashish nói "Okay, cool", đó là một điểm đáng làm rõ.

17. Agent của chính đội security: áp policy vào mình trước

Trong video đăng ngày 07/10/2026, Ashish nói một điều sẽ rất vui để nghĩ tới là các chức năng khác nhau trong security sẽ dùng các agent khác nhau thế nào. Một người làm AppSec sẽ build gì? Một người làm InfraSec sẽ build gì? Một người làm detection and response sẽ build gì? Anh tò mò thật sự: khi một đội security build các agent riêng cho cloud security, agent cho AppSec, agent cho detection and response, agent cho bug bounty, danh sách còn dài, CISO cũng có agent riêng, thì Prahathess sẽ tiếp cận và quản lý chúng thế nào?

Prahathess nói (video đăng ngày 07/10/2026): không phải thỉnh thoảng, mà là thường xuyên, đội security nắm toàn bộ quyền admin, ở một số nơi là vậy. Nên đó có lẽ là credential có tác động lớn nhất mà bạn có thể đánh cắp, hoặc một agent có thể mạo danh, để gây ra thiệt hại thật cho doanh nghiệp. Vì vậy, theo anh, bất kỳ policy nào bạn áp dụng cũng phải bắt đầu từ bên trong: bạn cần áp các policy đó lên chính mình, và lên cách bạn build những agent này cho mình.

Theo kinh nghiệm của Prahathess (video đăng ngày 07/10/2026), một khi bạn đã build xong agent này, bạn có thể chia sẻ nó với người khác: "đây là cách tôi build cái bot này, và nó tuân thủ mọi thứ; bạn có thể dùng nó làm ví dụ, làm POC cho bất cứ thứ gì khác bạn build".

Nên mỗi khi chúng ta build những agent này và đặt security control vào, theo anh (video đăng ngày 07/10/2026), một ý luôn đáng nghĩ kỹ là: làm sao tổng quát hoá nó và để engineering, hoặc những người khác trong công ty, cũng dùng được. Việc đó giúp bạn tiết kiệm rất nhiều thời gian. Anh lấy ví dụ: nếu chúng ta đang tìm cách đưa credential cho một agent mà agent không thật sự gửi credential đó lên LLM, thì đó không phải vấn đề mới, mà là vấn đề của bất kỳ ai đang dùng LLM.

Có tiếng đáp "That's right". Ashish nói build những thứ đó nghĩa là chúng có thể trở thành một phần của AI platform của bạn. Có tiếng đáp: "Exactly." Prahathess nói (video đăng ngày 07/10/2026) yêu cầu bạn có cũng là yêu cầu mà mọi người khác có, đó là thế giới chúng ta đang sống. Nên nếu bạn đang giải quyết một vấn đề cho mình, làm nó tổng quát hơn một chút và tìm cách mở ra cho người khác dùng sẽ rất hữu ích.

Anh lấy ví dụ cho mảng detection and response (video đăng ngày 07/10/2026): nếu bạn ngồi parse log cả ngày, thì SRE, hoặc cái bot của PagerDuty, cũng sẽ thấy nó hữu ích. Nên build, tự bắt mình chịu trách nhiệm trước với những policy mình viết, rồi tổng quát hoá các nguyên tắc phía sau thành framework để cả công ty dùng cho agent của họ, theo anh sẽ giúp được rất nhiều.

18. Agent sprawl, microservice và lời cảm ơn

Trong video đăng ngày 07/10/2026, Ashish nói thú vị. Điều đó cũng khiến anh nghĩ rằng agent sprawl (agent mọc lan tràn) sẽ rất phổ biến trên toàn tổ chức. Và dấu hiệu của một công ty AI trưởng thành sẽ là những nơi đã build một AI platform với cách chuẩn hoá cho agent: "đây là các agent cho security của chúng tôi". Để dễ hình dung hơn nữa, anh nói đây cũng là điều chúng ta từng làm với microservice thời cloud: chúng ta build microservice cho đúng những việc đó, giờ chỉ là gọi chúng là agent. Anh hỏi đó có phải cách nhìn đúng không, và nói anh chỉ đang chia sẻ khi nghĩ tới nó.

Prahathess nói, như một ví dụ chung thì đúng (video đăng ngày 07/10/2026). Agent tự chủ hơn microservice một chút, nhưng ngoài điều đó ra thì nhìn chung là đúng. Chúng ta bảo vệ microservice bằng platform, và chúng ta có thể bảo vệ agent bằng những platform riêng được build cho chúng. Anh nói rõ, trong trường hợp này anh đang nói tới coding agent.

Trong video đăng ngày 07/10/2026, Ashish nói "Wow", còn quá nhiều việc phải làm, anh cảm thấy chuyện này nên có phần hai. Nhưng đó là toàn bộ thời gian của tập này, dù anh rất muốn mổ xẻ thêm một vài điều.

Ashish cảm ơn Prahathess đã dành thời gian và đã tham gia. Prahathess cảm ơn vì đã được mời, và nói anh đã rất vui.