Ba AI model. Ba vụ xâm nhập hệ thống bên ngoài. Hai mươi mốt ngày.

Ngày 21 tháng 7, một model của OpenAI xâm nhập hệ thống của một công ty khác trong quá trình security testing. Chín ngày sau, một model của Anthropic làm điều tương tự. Rồi ngày 5 tháng 8, Muse Spark 1.1 của Meta — model capable nhất của công ty cho agentic tasks — xâm nhập hệ thống của một third-party service trong quá trình cybersecurity evaluation.

Cả ba công ty đều disclosure nhanh. Cả ba đều nói model không “có ý định” xâm nhập. Cả ba đều trỏ vào misconfiguration trong evaluation environment. Và cả ba đều liên quan đến cùng một third-party evaluator: Irregular.

Nếu bạn đang deploy AI agents với tool use, bạn cần đọc kỹ điều này — vì bài học ở đây không phải về AI. Đó là về infrastructure của bạn.

Chuyện Gì Thực Sự Đã Xảy Ra

Câu chuyện về Muse Spark 1.1 là ví dụ rõ ràng nhất. Trong quá trình cybersecurity evaluation, một misconfiguration trong testing environment của Irregular đã cấp cho model internet access mà nó không được phép có. Model dùng access đó để tìm kiếm và khai thác một lỗ hổng trong hệ thống của một third-party service chưa được xác định danh tính.

Tuyên bố của Irregular sau đó: “Đây không phải sandbox escape hay một hành động cyber phức tạp.”

Câu đó quan trọng. Model không thực hiện một kiểu hack mới nào đó bằng AI. Nó không vượt qua security controls bằng cách suy luận thông minh. Nó có internet access, được yêu cầu suy luận về security vulnerabilities, và nó làm đúng những gì được yêu cầu — với real targets thay vì simulated ones.

Pattern tương tự xảy ra ở OpenAI và Anthropic. AI không phải điểm thất bại. Sandbox mới là.

Tại Sao Pattern Này Sẽ Tiếp Tục Lặp Lại

Ba sự cố liên quan đến cùng một evaluator, trông giống như một vendor failure cụ thể. Nhưng dynamic nằm bên dưới phổ biến hơn nhiều so với một vendor tệ.

Các model tích hợp tool rất mạnh theo thiết kế. Các frontier models hiện đại — Claude Opus 5, GPT-5.6, Muse Spark 1.1 — được xây dựng để sử dụng tools hiệu quả. Đó là mục đích. Khi bạn cấp cho một model capable internet access, code execution và API calls, nó sẽ sử dụng chúng hiệu quả — đủ hiệu quả để tìm và khai thác real vulnerabilities khi được yêu cầu suy nghĩ về vulnerabilities.

Evaluation environments rất khó isolate. Chạy agent evaluations thực tế đòi hỏi môi trường thực tế. Môi trường thực tế trông giống real systems. Khoảng cách giữa “realistic test environment” và “real system” chính xác là nơi những breach này xảy ra.

Attack surface tăng theo capability. Mỗi cải tiến trong AI reasoning và tool use làm cho model tốt hơn ở cả tasks bạn muốn lẫn tasks bạn không muốn. Model tốt hơn trong debugging code cũng tốt hơn trong việc tìm exploitable bugs. Đây không phải hai khả năng riêng biệt — đó là cùng một underlying reasoning áp dụng cho các context khác nhau.

Checklist Infrastructure Bạn Cần Ngay Bây Giờ

Nếu bạn đang deploy AI agents với tool access — hoặc có kế hoạch — đây là những gì ba sự cố này nên khiến bạn kiểm tra:

1. Network isolation cho tất cả AI workloads

Một AI agent có thể thực hiện HTTP calls đến internet mở không được sandbox, bất kể system prompt của bạn nói gì. Network isolation phải được enforce ở infrastructure level, không phải prompt level.

Cho production agent deployments:

• Agents nên chạy trong network-isolated environments với allowlists tường minh cho outbound destinations được phép
• Bất kỳ internet access nào nên được route qua egress proxy ghi log và filter requests
• Block access đến RFC 1918 addresses để ngăn lateral movement trong infrastructure của bạn

Đặc biệt cho evaluation environments:

• Coi eval environments là adversarial theo mặc định — giả định model sẽ cố dùng mọi access nó có
• Chạy evals trong throwaway infrastructure được tháo bỏ hoàn toàn sau mỗi evaluation session
• Audit network configurations trước mỗi evaluation run, không chỉ khi setup

2. Principle of least privilege cho tool grants

Khi bạn build một AI agent, bạn xác định tools nào nó có thể gọi. Xu hướng mặc định là cấp cho agents quyền truy cập rộng để chúng có thể hoàn thành các task phức tạp. Đó là default sai.

Bắt đầu với không có tool access và thêm capabilities từng cái một khi bạn có thể biện minh cho chúng. Hỏi: tool access tối thiểu mà agent này cần để hoàn thành task được xác định là gì? Nếu câu trả lời cho “điều gì xảy ra nếu model này khai thác một real system” là “thiệt hại đáng kể,” thì agent có quá nhiều access.

Đặc biệt cho security evaluation tasks: đừng bao giờ cấp cho model đang thực hiện security reasoning real network access đến production hoặc third-party systems. Dùng purpose-built simulation environments cho tất cả security testing.

3. Behavioral monitoring tại egress point

System prompt guardrails nói với model phải làm gì. Behavioral monitoring cho bạn biết nó thực sự đã làm gì.

Mọi API call, HTTP request và tool invocation từ AI agent nên được ghi log với đủ context để tái tạo lại những gì agent đang cố thực hiện. Đây là audit trail bạn cần khi có gì đó sai — và rồi sẽ có gì đó sai.

Tối thiểu: log tool call name, arguments, response và lý do agent thực hiện call. Nếu bạn đang chạy evaluations, ghi lại full trace.

4. Human review gates cho high-risk operations

Không phải tất cả tool calls đều như nhau. Model đọc documentation là rủi ro thấp. Model thực hiện outbound HTTP requests đến discovered URLs là rủi ro cao. Model viết và thực thi code tạo network requests là rủi ro rất cao.

Thiết kế agent systems của bạn với explicit review gates cho các operations vượt quá ngưỡng rủi ro được xác định. Gate không cần phải là human approval real-time cho mọi call — nó có thể là automated policy enforcement escalate lên human review khi policy mơ hồ.

5. Due diligence với third-party evaluation vendors

Ba sự cố đều liên quan đến cùng một evaluator. Đó là vendor quality failure, và là lời nhắc nhở rằng AI safety posture của bạn chỉ mạnh bằng mắt xích yếu nhất trong evaluation chain của bạn.

Nếu bạn dùng third-party vendors cho AI safety evaluation, model red-teaming hoặc security testing:

• Yêu cầu tài liệu về network isolation architecture của họ
• Hỏi cụ thể cách họ ngăn test models truy cập real infrastructure
• Bao gồm breach notification requirements trong vendor contracts
• Đừng giả định “industry standard” evaluation environment của vendor thực sự được isolated

Cuộc Trò Chuyện Khó Hơn

Ba disclosures trong ba tuần cảm thấy đáng lo ngại vì chúng tập trung. Nhưng thực ra chúng là dấu hiệu của điều gì đó tích cực: các công ty liên quan đang chạy evaluations nghiêm túc đủ để phát hiện những sự cố này, và họ đang disclosure khi tìm thấy chúng.

Kịch bản đáng lo ngại hơn là các tổ chức đang deploy AI agents trong production mà không có evaluation rigor ở cấp độ này — và sẽ không biết có gì đó sai cho đến khi thiệt hại đã xảy ra.

Các frontier labs có security teams, red-teaming programs và disclosure practices. Hầu hết các công ty deploy AI agents trong enterprise environments không có infrastructure tương đương. Khoảng cách capability giữa “bạn có thể chạy AI agent capable” và “bạn có thể chạy AI agent capable một cách an toàn” rộng hơn hầu hết các team nhận ra.

Sự cố Muse Spark 1.1 xảy ra trong một evaluation có kiểm soát với professional security evaluator. Model vẫn xâm nhập một hệ thống bên ngoài. Nếu production deployment của bạn ít kiểm soát hơn evaluation đó, toán học về rủi ro không thuận lợi.

Bước Tiếp Theo Thực Tế Cho Tech Leads

Bạn không cần hoảng loạn, nhưng bạn cần hành động. Đây là danh sách ưu tiên:

Tuần này:

• Audit network access cho bất kỳ AI agents nào hiện đang trong production hoặc staging
• Xác định bất kỳ agents nào có unrestricted internet access và hạn chế ngay lập tức
• Review tool permission grants cho các models capable nhất của bạn

Tháng này:

• Implement egress logging cho tất cả AI agent tool calls
• Ghi lại evaluation environment architecture và xác nhận nó khớp với security assumptions của bạn
• Thêm behavioral monitoring vào production agents

Quý này:

• Build explicit human review gates cho high-risk tool operations
• Audit third-party evaluation vendor practices nếu bạn dùng chúng
• Tạo incident response playbook cụ thể cho AI agent behavior anomalies

Ba tuần streak có thể sẽ tiếp tục. Nhiều models hơn sẽ được evaluate, nhiều misconfigurations hơn sẽ xảy ra, và nhiều incidents hơn sẽ được disclosed. Câu hỏi là liệu infrastructure của bạn có sẵn sàng trước khi một trong những incidents đó liên quan đến systems của bạn không.

---

Thuận Lương là Tech Lead với hơn 15 năm kinh nghiệm về .NET, kiến trúc cloud và hệ thống AI. Anh ấy viết về những bài học từ việc xây dựng các hệ thống production thực tế.