Bảo mật AI Agent nhà máy: thiết kế OT, RFP và nghiệm thu

Bảo mật AI Agent nhà máy bắt đầu từ ranh giới vận hành, không phải điểm benchmark của mô hình: Agent được đọc gì, được thay đổi gì, và tại đâu con người hoặc bộ điều khiển tất định phải luôn có quyền chặn? Một câu trả lời sai của chatbot có thể chỉ nằm trên màn hình. Nhưng Agent có công cụ kết nối phiếu bảo trì, lịch ERP, lệnh MES, PLC hoặc robot có thể biến một quyết định sai thành dừng máy, sai lệch chất lượng hoặc hư hỏng thiết bị. Bài viết này dành cho lãnh đạo nhà máy và nhóm OT/IT tại Thái Lan, Việt Nam và Đông Nam Á đang thiết kế cấp năng lực, đặc quyền tối thiểu, phê duyệt, phân đoạn, kill switch, bằng chứng audit và FAT/SAT.

Kết luận trước: xây bảo mật OT của AI Agent ở bên ngoài mô hình

Điểm khởi đầu an toàn không phải là tin LLM như một thiết bị bảo vệ. Mô hình có thể đề xuất hoặc lập kế hoạch, nhưng không phải là thẩm quyền cuối cùng về quyền hạn, giới hạn giá trị, thứ tự lệnh, trạng thái máy, dừng khẩn cấp hay fail-safe. Safety PLC, Safety Instrumented System (SIS), mạch bảo vệ đã chứng nhận, interlock của máy và trách nhiệm con người phải độc lập với mô hình.

Một thiết kế có thể triển khai kết hợp chín kiểm soát:

1. Danh tính duy nhất, chủ sở hữu, mục đích và ngày hết hạn cho từng Agent.
2. Các cấp năng lực tách đọc, tư vấn, ghi có ràng buộc và thực thi trực tiếp.
3. Đặc quyền tối thiểu theo công cụ, tài sản, dữ liệu, khung giờ và dải giá trị.
4. Tách tài liệu hoặc đầu vào không tin cậy khỏi công cụ thực thi.
5. Dịch vụ phê duyệt và phân tách nhiệm vụ cho hành động rủi ro cao.
6. Interlock tất định và trạng thái an toàn nằm ngoài mô hình.
7. AI Agent kill switch có thể thu hồi quyền thực thi ngay lập tức.
8. Telemetry liên kết chỉ dẫn, ngữ cảnh, tool call, phê duyệt và kết quả.
9. Rollback, ứng phó sự cố, quản lý thay đổi và bàn giao bằng chứng.

Hướng dẫn sản xuất của Google Cloud ngày 14/9/2026 khuyến nghị tích hợp bảo mật xuyên suốt vòng đời Agent, hợp nhất khả năng quan sát IT/OT, duy trì danh tính và registry của Agent, đồng thời phát hiện Agent trái phép. Đây là hướng dẫn hữu ích của một nhà cung cấp, không phải tiêu chuẩn trung lập hay chứng nhận an toàn sản phẩm. Doanh nghiệp phải kết hợp nó với đánh giá rủi ro tại site, yêu cầu của hãng thiết bị, functional safety, cybersecurity và pháp luật địa phương.

AI Agent nhà máy khác chatbot ở điểm nào?

Khác biệt quyết định là công cụ có thể thay đổi trạng thái hay không. Tìm kiếm và tóm tắt chủ yếu ảnh hưởng quyết định của con người. Agent có công cụ có thể mở work order, giữ chỗ phụ tùng, đổi lịch sản xuất, gửi recipe đề xuất, điều phối AGV hoặc yêu cầu robot chuyển động. Nó còn có thể gọi nhiều công cụ liên tiếp, dùng kết quả trước làm ngữ cảnh cho hành động sau.

Bài “agentic factory” của Google Cloud ngày 10/9/2026 mô tả Agent nối ngữ cảnh số với hành động vật lý dưới sự giám sát của con người. Bài viết nêu, với tư cách ví dụ Google/GE, rằng GE Appliances có hơn 800 Agent tùy biến; một Agent cộng tác với hơn 600 nhà cung cấp được báo cáo giúp giảm 25% backorder. Các con số thuộc tổ chức và use case đó, không phải cam kết hiệu quả chung. Ví dụ FANUC nối lệnh ngôn ngữ tự nhiên với chuyển động cơ khí cũng là trường hợp của nhà cung cấp, không chứng minh mọi nhà máy đã sẵn sàng tự chủ closed loop.

Tách ba vùng vận hành

Bài viết tập trung ranh giới giữa vùng sát OT và thực thi OT. Nó không đề xuất LLM thay Safety PLC hay SIS. AI có thể đề nghị dừng, còn cơ chế tất định đã chứng nhận vẫn chịu trách nhiệm bảo đảm hành động bảo vệ.

Ghi bốn cấp năng lực vào hợp đồng

NIST thảo luận cách phân loại công cụ Agent theo chức năng và mẫu truy cập—read-only, constrained write, write—cùng môi trường tin cậy hoặc không tin cậy. NIST cũng nêu robot arm và công cụ phòng thí nghiệm/nhà máy như phần mở rộng vật lý. Mô hình L0–L3 sau đây là tổng hợp của TOMAS TECH cho mua sắm sản xuất, không phải thuật ngữ chính thức của NIST.

Không duyệt “AI Agent” như một khối không thể chia. Cùng một Agent có thể đọc rung động ở L0, tạo phiếu bảo trì ở L2 và không có quyền ghi PLC. Việc nâng cấp phải xác định use case, asset, action, khung giờ và đúng phiên bản model, prompt, policy, tool. Điều này ngăn connector mới âm thầm biến L2 thành L3 trên thực tế.

Threat model: không chỉ nhìn hallucination

MITRE ATLAS “OpenClaw Investigation” năm 2026 là case study về một công cụ Agent. Tài liệu ghi nhận prompt smuggling, indirect prompt injection, thỏa hiệp third-party skill/supply chain, context hoặc memory poisoning, thu thập credential và tool invocation nguy hiểm. Không nên suy rộng phát hiện của một sản phẩm cho mọi Agent, nhưng đây là nguồn tốt để xây câu hỏi mua sắm công nghiệp.

Trong thông báo ngày 1/9/2026, OWASP GenAI Security Project cho biết LLM Top 10 năm 2026 đã đưa vào bằng chứng từ sự cố thực tế và giới thiệu Agent Control Standard như hướng dẫn thực hành về enforcement khi chạy. Đây là nguồn công khai hữu ích để cấu trúc threat và execution control, không phải chứng nhận functional safety cho thiết bị công nghiệp. Phần sau kết hợp chúng với machine state, interlock và safe state riêng của nhà máy.

1. Chỉ dẫn không tin cậy đi vào đường thực thi

PDF bảo trì, email, webpage, supplier portal, QR và free text trong log có thể chứa lệnh ngôn ngữ tự nhiên. Nếu mô hình không phân biệt chắc chắn bằng chứng với chỉ dẫn, văn bản được truy xuất có thể điều khiển tool call. Banner cảnh báo là chưa đủ: session tiêu thụ dữ liệu không tin cậy phải bị vô hiệu hóa write tool bằng kỹ thuật.

2. Quyền quá mức và credential dùng chung

Service account ERP, MES hoặc OT quá rộng che khuất Agent nào đã hành động. Không đưa secret vào prompt hoặc model context. Tool broker cấp token ngắn hạn, giới hạn target, action, range và count. Không tự động kế thừa toàn bộ quyền của người yêu cầu; người có quyền hợp lệ không có nghĩa Agent cần cùng phạm vi.

3. Memory bị đầu độc và trạng thái lỗi thời

Memory lâu dài có thể giữ quan hệ thiết bị sai, recipe cũ hoặc chuỗi tấn công để dùng lại. Lưu provenance, tác giả, thời gian, asset scope, trạng thái duyệt và expiry cùng memory. Trước thực thi phải đọc lại system of record và review trước khi nâng text của người dùng thành operational memory lâu dài.

4. Supply chain của model, skill và connector

Năng lực thực thi phụ thuộc model API, agent framework, plugin/MCP server, package, container, connector và prompt template. Quản lý không chỉ SBOM mà cả version được phép, signature/hash, nguồn, người duyệt, bằng chứng test và version rollback.

5. Hành động vật lý không an toàn do thiếu ngữ cảnh

Lệnh hợp lý về logic có thể nguy hiểm khi sensor thiếu, clock lệch, máy ở maintenance mode, lockout/tagout đang hoạt động, phôi sai vị trí hoặc có người trong vùng. Không dùng “confidence” của model làm quyết định an toàn. Rule tất định phải từ chối khi tín hiệu bắt buộc thiếu hoặc không hợp lệ.

6. Mất nguồn gốc và trách nhiệm

“AI quyết định” không phải hồ sơ sự cố. Dùng correlation ID nối yêu cầu gốc, dữ liệu và timestamp, model/prompt/tool version, đề xuất, policy result, người duyệt, command và phản hồi thiết bị. Đồng thời không sao chép secret hay dữ liệu cá nhân vô hạn vào log; đặt access và retention.

Kiến trúc đích: đặt execution broker giữa AI và OT

Tránh session trực tiếp từ Agent đến PLC hoặc robot. Luồng tham chiếu là AI AGENT → API GATE → OT DMZ → PLC/ROBOT. APPROVAL giữ hành động rủi ro cao ở đường riêng. SAFE STOP bỏ qua model và đến safety layer tất định của nhà máy.

Danh tính và registry của Agent

Đăng ký owner, mục tiêu nghiệp vụ, tier, model, tool, site, data classification, người chịu trách nhiệm, expiry và lần review cuối. Khi chạy, ghi Agent, người/service gọi, session và tool version. Broker từ chối danh tính chưa đăng ký hoặc hết hạn.

Tách đường đọc và đường ghi

Khi khả thi, đọc Historian, MES và dữ liệu chất lượng qua read-only replica hoặc outbound API. Cân nhắc one-way transfer/data diode cho use case phù hợp. Dùng network, credential và endpoint khác cho ghi. Nhu cầu real time vẫn không biện minh quyền rộng; chỉ expose tag hoặc function chọn lọc qua broker.

API gate và tool broker

Không cấp generic SQL, shell hoặc tải chương trình PLC. Expose business action hẹp như create-maintenance-draft hoặc request-line3-speed-candidate. Broker kiểm schema, type, unit, range, machine mode, rate, concurrency, time và command ID trùng. Idempotency phải bảo đảm retry không thực thi hành động vật lý hai lần.

Dịch vụ phê duyệt và phân tách nhiệm vụ

Phê duyệt không phải chữ “OK” mơ hồ trong chat. Approval object phải cố định asset, current value, proposed value, difference, rationale, impact và expiry. Tách requester với approver; tách người sửa model với người promote production. Nếu input hoặc trạng thái máy thay đổi đáng kể, phê duyệt hết hiệu lực và phải đánh giá lại.

OT DMZ và segmentation

Tách cloud/IT, OT DMZ, cell/area và equipment network, nêu hướng và đích được phép. Không cho traffic tùy ý từ nền tảng AI vào OT. DMZ xử lý protocol conversion, policy, queue, rate limit và audit. Khi mất liên lạc, áp dụng chính sách theo use case—dừng, giữ trạng thái, hoặc tiếp tục local control—không để model đoán.

Interlock tất định

Nhiệt độ, áp suất, tốc độ, cửa bảo vệ, worker detection, machine mode và lockout/tagout phải được đánh giá trong PLC, Safety PLC, SIS hoặc machine controller. Dù đề xuất trong dải danh định, interlock nhà máy vẫn phải có quyền từ chối. Agent không có quyền vô hiệu safeguard.

Safe state và AI Agent kill switch

Kill switch không chỉ dừng ứng dụng. Nó phải chặn tool call mới, thu hồi token đã cấp, cách ly queue chờ, hoàn tất hoặc hủy in-flight work theo quy trình, trả quyền về local control, cảnh báo người chịu trách nhiệm và yêu cầu phê duyệt có kiểm soát để restart.

Safe state khác nhau theo asset. Dừng conveyor ngay có thể làm rơi tải; furnace có thể không chịu hard stop; batch đang chạy có thể cần hoàn tất có kiểm soát. Engineering, operations, safety, quality và maintenance phải thống nhất transition được thực thi độc lập với AI.

Lập ma trận AI Agent đặc quyền tối thiểu

Role name là chưa đủ. Phải định nghĩa subject, tool, action, target, condition, approval, limit và expiry.

Test negative: line khác, tag ngoài dải, sai giờ, vượt rate, approval hết hạn, sai unit, thiếu signal, ID trùng và thứ tự đảo. Bằng chứng FAT/SAT phải cho thấy yêu cầu bị chặn trước khi đến OT.

Industrial AI RFP phải yêu cầu gì?

1. Inventory đầy đủ tool và action

Yêu cầu mọi tool standard, optional, third party cùng phân loại read/write, data, target, protocol, credential, dependency và network path. Nếu Agent có thể discover, generate hoặc install tool khi chạy, yêu cầu mô tả kiểm soát, review, signature và sandbox.

2. Trust boundary và data flow

Yêu cầu sơ đồ user, external document, RAG, model, memory, broker, IT, OT DMZ và equipment. Hỏi input nào là untrusted và write tool bị vô hiệu ra sao sau khi input đó vào session.

3. Identity và permission

Tách human, Agent, service và tool identity. Yêu cầu credential ngắn hạn, secret storage, rotation, emergency revocation, scope theo site và segregation of duties. Admin permission change cũng phải audit.

4. Supply chain của model và skill

Yêu cầu model/version, hosting, điều khoản training/retention, framework, skill, connector, dependency, SBOM, signature, xử lý vulnerability, support life, thông báo thay đổi và rollback. Auto update không được vượt production promotion gate.

5. Audit và replay

Lưu mọi prompt có thể tạo kho dữ liệu nhạy cảm mới. Xác định cùng nhau bằng chứng cần thiết, redaction, access, retention, clock sync, correlation ID, chống sửa, SIEM, search/export và quy trình reconstruct.

6. Emergency stop, recovery và rollback

Yêu cầu thủ tục disable Agent, revoke token, isolate queue, chạy OT local, làm tay, escalation và điều kiện restart. Hỏi đơn vị rollback cùng recovery time cho model, prompt, policy, tool, configuration, memory và connector.

7. Incident response và change control

Phân trách nhiệm detection, containment, bảo toàn chứng cứ, equipment safety, communication, root cause và corrective action. Thay đổi rủi ro cao kích hoạt FAT/SAT lại; emergency change có post-approval trong thời hạn.

8. Bằng chứng bàn giao

Biến architecture, permission matrix, threat model, test record, residual risk, known limitation, sample log, restore test, training record, runbook và component inventory thành deliverable hợp đồng. “Supported” không phải bằng chứng; cần configuration, policy, API schema và negative-test log.

Để xem toàn chương trình, đọchướng dẫn triển khai AI Agent. Về kiến trúc dữ liệu và privacy, xemmôi trường generative AI an toàn. Bài này thu hẹphướng dẫn nghiệm thu AI Agent vào kết nối OT và tác động vật lý.

FAT/SAT: chứng minh từ chối và safe state

FAT xác minh design, configuration và boundary ở môi trường nhà cung cấp. SAT lặp lại test phù hợp với network, mode, operator, clock, load và procedure của site thật. Các test này không thay functional-safety certification hay kiểm định theo luật. Chúng chứng minh đường AI không vượt safeguard sẵn có.

Lưu prerequisite, data, version, người chịu trách nhiệm, expected/actual, machine-readable log, deviation, correction và retest. Không chỉ nhìn pass percentage. Một critical boundary bypass có thể đủ để dừng release.

Kế hoạch triển khai thực tế trong 90 ngày

Chín mươi ngày là khung minh họa, không phải cam kết. Sửa máy, đánh giá functional safety, quy định và cửa sổ shutdown có thể cần lâu hơn.

Ngày 0–15: xác định use case và hazard boundary

Kiểm kê site, asset, user, data và tool. Walkdown interlock hiện tại, emergency stop, manual operation và failure recovery. Mặc định bắt đầu L0/L1, ghi lý do cho công việc cần L2. Giao owner cho operations, maintenance, safety, quality, OT, IT, cyber và legal.

Ngày 16–30: triển khai identity, network và permission

Tạo Agent registry, ID riêng, token ngắn hạn, tool allowlist, read-only path, OT DMZ và correlated logging. Giới hạn write API vào business action hẹp; kiểm schema, range, unit, target, frequency và time. Diễn tập bàn giấy kill switch cùng safe-state transition.

Ngày 31–60: đánh giá L0/L1 bằng dữ liệu nhà máy

Test provenance, freshness, missing/abnormal value và equipment mode trên dữ liệu gần production. Đánh giá không chỉ chất lượng khuyến nghị mà cả khả năng operator nhận ra lời khuyên sai, hành vi khi tải cao, vận hành đa ngôn ngữ, xóa memory và audit search. Bao gồm injection qua tài liệu untrusted.

Ngày 61–75: FAT/SAT cho một L2 hẹp

Chọn một action đã duyệt, một nhóm asset và một khung giờ. Test duplicate, reversed order, network loss, stale approval, rate limit, wrong asset, missing sensor và kill switch. Không thêm L3 nếu chưa có safety case và executive authorization riêng.

Ngày 76–90: nâng cấp, tiếp tục hoặc dừng theo bằng chứng

Review defect mở, residual risk, tải vận hành, training, log completeness và recovery time. Chọn “tiếp tục L0/L1”, “nâng L2 có giới hạn”, “tiếp tục có điều kiện”, “retest” hoặc “stop”. Lập review sau go-live ngày 30, 60, 90 và trigger retest khi đổi model/tool.

Ví dụ risk scoring minh bạch

Ví dụ sau chỉ minh họa, không phải threshold chính thức của OWASP AIVSS. AIVSS v0.8 cung cấp phương pháp chấm vulnerability tập trung agentic AI để bổ sung framework hiện có. Dự án thật phải kiểm tra phiên bản hiện hành và quy tắc chấp nhận của doanh nghiệp.

Giả định likelihood 1–5, impact 1–5 và risk score = likelihood × impact, dải 1–25.

Impact ở hàng hai vẫn là 5 theo giả định thận trọng rằng mức nghiêm trọng khi sự cố xảy ra không đổi dù likelihood giảm. Ghi rõ ai chấp nhận residual risk. Không tuyên bố an toàn từ tổng hoặc trung bình; cấm đoán của functional safety, luật và absolute gate của công ty được ưu tiên.

Theo dõi ranh giới sau go-live

Độ chính xác model không phát hiện được boundary drift. Theo dõi unauthorized Agent, denied tool call, permission change, approval latency/expiry, dùng data cũ, downgrade khi thiếu signal, duplicate command, kill-switch drill, logging gap, model/skill change, manual intervention và rollback.

Không dùng nhiều denial làm lý do tự động mở quyền. Đó có thể là workflow sai, training kém, attack hoặc configuration drift. Denial giảm không phải cải tiến nếu bằng chứng audit biến mất. Hàng tháng đối soát registry với network route, tool và credential thực tế, rồi xóa capability không dùng.

Lỗi triển khai thường gặp

• Cấp admin cho PoC: ngoại lệ ngắn hạn trở thành baseline production. Hãy test least privilege ngay trong PoC.
• Cho rằng có người duyệt là an toàn: người có thể bỏ sót unit, stale value hoặc machine state. Cần cả approval UI và deterministic validation.
• Coi kill switch là terminate process: token đã cấp, queue, in-flight work và equipment recovery vẫn còn.
• Log mọi thứ: secret và dữ liệu cá nhân tạo rủi ro thứ cấp. Chỉ giữ bằng chứng tối thiểu có bảo vệ để reconstruct.
• Một site pass rồi scale mọi nhà máy: asset, process, network và procedure khác nhau. Authorize capability theo use case/site.
• Cho AI sửa Safety PLC: làm mất độc lập của safety layer. Cấm đường AI vô hiệu safeguard.

Checklist triển khai

Trước RFP

• [ ] Tách IT assistance, OT-adjacent và OT execution.
• [ ] Phân loại mỗi use case từ L0 đến L3.
• [ ] Giữ Safety PLC, SIS, interlock và trách nhiệm con người độc lập.
• [ ] Kiểm kê tool, data, credential, network và supplier.
• [ ] Xác định safe state và phạm vi kill switch theo asset.

Trước FAT/SAT

• [ ] Có Agent ID riêng và capability authorization hết hạn.
• [ ] Tách read/write path và credential.
• [ ] Route write qua business API trong allowlist.
• [ ] Approval cố định scope, difference, expiry và hết hạn khi state đổi.
• [ ] Test injection, missing signal, stale context, network loss, duplicate và stop.
• [ ] Reconstruct request đến equipment response từ log.

Trước production

• [ ] Không còn critical boundary bypass chưa xử lý.
• [ ] Demo token revocation, queue isolation và manual recovery.
• [ ] Demo rollback model, policy, tool và memory.
• [ ] Operations, OT, IT, cyber, safety và quality duyệt bằng chứng.
• [ ] Đặt trigger FAT/SAT lại và review 30/60/90 ngày.

FAQ: bảo mật AI Agent nhà máy

Có nên nối AI Agent trực tiếp vào PLC từ đầu?

Không nên. Trước hết chứng minh data quality, provenance, audit và operation ở L0 read/L1 advise. Nếu cần ghi, bắt đầu L2 qua business API hẹp, approval, range, equipment-state check, idempotency và safety layer độc lập—không cấp generic PLC access.

RBAC thông thường có đủ cho đặc quyền tối thiểu của AI Agent?

Thường không đủ. Bổ sung asset, action, range, unit, time, rate, data freshness, approver và session expiry. Dùng kiểm thử âm để chứng minh mọi thao tác bị cấm đều bị từ chối.

AI Agent kill switch có giống emergency stop?

Không. Kill switch AI vô hiệu tool call, credential, queue và session. Emergency stop và safe shutdown của máy thuộc mạch an toàn, PLC, SIS hoặc cơ chế tất định đã chứng nhận. Phải định nghĩa cách hai lớp tương tác.

Có người phê duyệt thì L3 direct execute đã an toàn chưa?

Chưa. Thiếu hiển thị, mệt mỏi, dữ liệu cũ và sai đơn vị vẫn xảy ra. Cần safety layer độc lập, broker, state validation, limit, monitoring, stop và recovery. Với nhiều use case, không dùng L3 là quyết định đúng.

Chỉ dùng OWASP AIVSS để quyết định go/no-go được không?

Điểm số giúp so sánh và thảo luận, không thay functional safety, quy định, điều kiện của hãng thiết bị hoặc cấm đoán doanh nghiệp. Ghi version phương pháp, giả định, bằng chứng và owner của residual risk.

FAT/SAT này có thay chứng nhận functional safety không?

Không. Nó test boundary, permission, denial, safe-state và evidence của AI Agent. Đánh giá functional safety theo thiết bị, chứng nhận, kiểm định pháp lý và procedure nhà máy vẫn là nghĩa vụ riêng.

Tóm tắt: chứng minh có thể dừng trước khi tăng năng lực

AI Agent công nghiệp càng gần hành động vật lý thì giá trị và tác động tiềm ẩn càng lớn. Hãy tách L0 Observe, L1 Advise, L2 Constrained execute và L3 Direct execute theo use case. Thiết kế identity, tool allowlist, read/write separation, OT DMZ, approval, deterministic interlock, safe state, kill switch và audit trước khi cấp năng lực. Trong RFP, yêu cầu bằng chứng rằng hành động bị cấm được từ chối, sự cố chuyển sang hành vi an toàn đã thống nhất, và có thể reconstruct lịch sử. Chỉ nâng use case đã qua negative FAT/SAT và có chấp nhận residual risk rõ ràng.

TOMAS TECH có thể hỗ trợ từ giai đoạn ý tưởng AI Agent nối OT đến phân cấp năng lực, threat model, Industrial AI RFP, thiết kế network/permission và kế hoạch bằng chứng FAT/SAT. Doanh nghiệp có thểliên hệ ngay khi đánh giá sản phẩm hoặc trước khi đi xa hơn L0/L1.

Nguồn tham khảo chính

• Google Cloud, “A manufacturing blueprint for secure agentic AI” (14 Sep 2026): https://cloud.google.com/transform/a-manufacturing-blueprint-for-secure-agentic-ai
• Google Cloud, “Inside the agentic factory” (10 Sep 2026): https://cloud.google.com/transform/agentic-factory-manufacturing-new-age-of-autonomy-industrial-ai
• OWASP GenAI Security Project, “2026 Top 10 for LLM Applications” announcement (1 Sep 2026): https://genai.owasp.org/2026/09/01/owasp-genai-security-project-unveils-2026-top-10-for-llm-applications-new-agent-control-standard-and-sponsors-as-community-tops-30000-members/
• NIST, “Lessons Learned from the Consortium: Tool Use in Agent Systems” (Aug 2025): https://www.nist.gov/news-events/news/2025/08/lessons-learned-consortium-tool-use-agent-systems
• MITRE ATLAS, “OpenClaw Investigation” (9 Feb 2026): https://www.mitre.org/sites/default/files/2026-02/PR-26-00176-1-MITRE-ATLAS-OpenClaw-Investigation.pdf
• OWASP, AIVSS v0.8 project page: https://aivss.owasp.org/

Bài viết là hướng dẫn triển khai và mua sắm chung dựa trên thông tin công khai được kiểm tra đến ngày 19/9/2026. Nó không thay chứng nhận functional safety theo thiết bị, tuân thủ pháp luật hoặc bảo đảm cybersecurity.