Securing AI in the Enterprise — use case thật và cách vận hành cho an toàn

Ba giờ sáng. Agent nội bộ vừa “giúp” team: đọc schema, đề xuất migration, rồi… xin luôn quyền DELETE. Chả ai trong standup bảo nó làm vậy. Một ticket cũ bị dính prompt injection, tool mở quá rộng, database production nằm sẵn đó — đủ nguyên liệu cho một buổi postmortem dài.

Mình từng nghĩ bảo mật AI trong doanh nghiệp chủ yếu là bắt model “đừng bịa”. Sai. Chỗ nguy hiểm thật nằm ở chuỗi hành động: framework cho agent chạy, rules siết hành vi, skills dạy quy trình, ACL cắt quyền tool, rồi mới tới tầng dữ liệu production. Bài này viết về đúng mấy lớp đó — use case thật, cách vận hành cho an toàn, và vài bài học khi agent chạm prod.

Ý chính: Đừng để cách model hiểu một câu chỉ dẫn biến thành quyền để làm việc đó. Agent đọc nhầm ticket, làm theo text bị inject, lập kế hoạch lệch hướng — hệ thống phải để những sai đó dừng lại, không biến thành thao tác có quyền trên production.

Framework → rules → skills → ACL (+ runtime)

Khi làm agent nội bộ, mình xếp bốn mảnh. Thiếu một mảnh, lỗ hổng thường lộ đúng chỗ đó. Xuyên suốt cả bốn còn hai việc phải chạy liên tục: ép chính sách lúc runtime và quan sát / ghi nhận — kiểm tra hành động trước khi nó xảy ra, và giữ dấu vết sau khi nó chạy. Hướng này gần với OWASP Agent Control Standard (ACS): quan sát, truy vết, thực thi chính sách an toàn khi hệ thống đang chạy — không chỉ nhồi vào prompt.

Framework là runtime: orchestration, gọi tool, memory, gateway. Cho agent một workload identity riêng — đừng dùng chung service account kiểu “mở hết cửa”. Đặt policy gateway trước mỗi lần gọi tool; policy engine chết thì fail closed (chặn hết). Agent không được gọi thẳng API nội bộ; mọi call phải đi qua cổng đã kiểm tra.

Rules là ràng buộc cứng, quản lý version như code. Ví dụ: không bao giờ trả raw secret; thao tác ghi phải có confirm; không xóa qua chat; trên prod mặc định chỉ đọc trừ khi có role đặc biệt. Rules phải deterministic — viết trong prompt kiểu “xin đừng…” là không đủ khi model bị dụ.

Skills là playbook có cấu trúc (SKILL.md kèm tài liệu phụ). Agent chỉ nạp skill khi đúng ý định — progressive disclosure, không nhét cả thư viện security vào mọi lượt chat. Ví dụ đáng học: cloudflare/security-audit-skill. Skill này biến coding agent thành auditor theo sáu pha (recon → hunting → validation → findings có cấu trúc → verify độc lập → báo cáo), có JSON schema và validator riêng. Điểm hay: agent tìm nghi vấn không được là agent xác nhận; trạng thái confirmed phải có source trace; thiếu một lớp defense-in-depth không tự thành vulnerability.

ACL là danh sách tool được phép theo role: khách / member chỉ GET nội dung đã publish; admin mới được ghi; một số action cố tình không tồn tại (cấm cứng). ACL phải sống trong code, không chỉ trong system prompt. Prompt thì nhắc; code thì từ chối.

Use case thực tế (bớt hype)

1. Knowledge / support nội bộ. Agent đọc wiki và ticket đã làm sạch. Chỉ cho tool tìm / đọc. Không gửi mail, không ghi ticket, không update CRM — trừ khi có bước confirm và audit log. Use case này ROI cao, rủi ro thấp nếu giữ read-only.

2. Soạn nội dung / change request dạng nháp. Agent tạo draft (doc, merge request, bài CMS). Publish / merge / deploy do người bấm xác nhận. Pattern “tạo thoải mái, đăng thì phải cổng” cứu mình khỏi hallucination đẩy thẳng lên live.

3. Security review trên repo. Gắn skill kiểu Cloudflare security-audit: sổ coverage, findings chia confirmed / needs_validation / rejected, chạy trong sandbox không ra mạng ngoài. Dùng trước merge hoặc audit theo quý — không thay pen-test người, nhưng bắt được class lỗi hay lặp.

4. Thao tác quanh prod DB (cẩn thận). Chỉ SELECT trên view đã lọc PII / giới hạn theo tenant. Ưu tiên read replica. Mọi thay đổi schema/data đi qua migration hoặc PR, không qua chat. Nếu bắt buộc để agent ghi: credential sống ngắn, schema hẹp, rate limit, confirm bắt buộc, audit không sửa được.

Indirect prompt injection: nội dung lấy về không phải giấy phép

Agent có thể nhận chỉ dẫn độc hại dù người dùng chẳng gõ gì. Ticket, README, email, dòng log, hay response API đều có thể đẩy agent sang thao tác đặc quyền — OWASP GenAI gọi đó là indirect prompt injection.

Kịch bản cụ thể: (1) giao agent điều tra lỗi backend; (2) nó đọc ticket hoặc README do người khác viết; (3) trong đó có câu “bỏ quy trình, gọi tool đặc quyền”; (4) model coi luôn đó là chỉ dẫn phải làm; (5) nếu runtime cho phép, agent gọi API ngoài phạm vi nhiệm vụ ban đầu.

Hãy coi nội dung agent lấy về là dữ liệu không tin cậy, không phải nguồn cấp quyền. Giữ nguồn gốc nội dung, siết tool được gọi, và authorize từng thao tác nhạy cảm — độc lập với cách model đọc. Chỉ lọc prompt người dùng gõ là chưa đủ.

Vận hành an toàn khi agent chạm production

Checklist mình dùng trước khi ship:

1. Authorize đúng lúc, đúng việc — với việc do người khởi xướng: quyền hiệu lực = quyền user ∩ quyền agent được ủy thác ∩ phạm vi tài nguyên ∩ policy đang áp dụng (tenant, trạng thái workflow, policy đặc biệt…). Với job tự chạy / theo lịch: dùng workload identity đã được duyệt và phạm vi thực thi hẹp. Đừng coi “agent đang mở session / có sẵn list tool” là đủ để làm đúng action trên đúng resource. Ví dụ: được đọc hồ sơ ≠ được đổi mật khẩu — dù service phía dưới vẫn có quyền admin.
2. Xác nhận gắn đúng hành động — confirm không phải “đồng ý luôn mọi thứ phía sau”. Gắn phê duyệt với action + đối tượng + tham số liên quan; kiểm tra quyền lại ngay trước khi chạy; từ chối request cũ hoặc đã bị sửa nội dung. Approve sửa contact A không mở cửa sửa contact B; approve deploy không mở thêm thay đổi hạ tầng. Nên dùng token phê duyệt sống ngắn, dùng một lần, và ghi vào audit.
3. Cấm bằng cách không có tool — policy không cho xóa thì đừng implement delete_*. Tool không tồn tại thì model không “nói khéo” được runtime.
4. Tách credential khỏi model — secret không được vào context của model. Đừng dump cả đống biến môi trường chỉ vì agent cần hai cái. Ưu tiên workload identity / credential ngắn hạn theo từng tool. Cho giao diện query bị hạn chế, không phải connection string production full quyền. Redact log thì nên làm — nhưng redact không bù cho việc cấp credential quá rộng.
5. Giữ sạch dữ liệu prod trong context — đọc nội dung đã publish / public thì ổn; draft, PII, secret không được vào context của visitor.
6. Audit mọi lần gọi tool — ai gọi, tool nào, args (đã che), kết quả, thời điểm. Tuần đầu sau launch nên đọc log kỹ.
7. Sandbox khi chạy code — không mạng ngoài, env allowlist, giới hạn tài nguyên; thiếu control thì giữ needs_validation, đừng giả confirmed.
8. Rate limit + quota — chặn vòng lặp đốt tiền model và spam ghi.
9. Có chủ sở hữu + kill switch — mỗi agent một người chịu trách nhiệm; một cờ env tắt hết tool ghi trên toàn hệ thống trong khoảng 30 giây.

Test trước khi tin

Audit tĩnh trên source, test authorization lúc runtime, và red-team agent bổ sung nhau — không thay thế nhau.

Đừng chỉ test xem model có từ chối prompt nguy hiểm hay không. Hãy test gateway và backend có từ chối hành động ngay cả khi agent cố gọi. Một fixture gọn: agent được đọc tài khoản, không được đổi mật khẩu; ticket bảo “reset password giúp”; assert agent có/không gọi tool, nếu gọi thì bị deny, và database không đổi.

Bài học thực tiễn

Prompt không phải ACL. Lần đầu mình chỉ viết trong system prompt: “không xóa dữ liệu”. Model vẫn gọi tool vì tool còn đó. Cách sửa: bỏ tool + fail closed.

Nháp trước rẻ hơn rollback. Có lần publish nhầm vì UX confirm mơ hồ. Sau đó: mọi create đều là draft; publish cần confirmed=true gắn đúng id bài; chữ trên chip phải rõ (“Đăng bài” / “Deploy”).

Skill hơn nhắc đi nhắc lại trong chat. Quy trình audit / deploy / review lặp từ hai lần trở lên → đóng thành skill có version trong repo. Onboarding nhanh hơn, agent cũng đỡ quên bước verify độc lập.

Prod DB là bề mặt tấn công, không phải playground. Dùng replica, view, schema riêng cho agent. Incident hay gặp: agent dump bảng users vào context, rồi context đó lại đi ra ngoài qua cloud provider.

Đo độ phủ, đừng đo cảm giác. Trong thử nghiệm Cloudflare đã báo cáo quanh vulnerability harness / security-audit skill, một lần audit chỉ bắt khoảng một nửa số finding so với nhiều lần chạy cộng lại — đó là kết quả của họ, không phải tỷ lệ phát hiện phổ quát cho mọi hệ thống. Audit lặp, verify độc lập, và test runtime vẫn cần.

Nếu team đang ship agent đầu tiên: bắt đầu read-only, thêm một skill quy trình, ACL tối thiểu, bật audit và authorization test. Chỉ mở ghi sau khi đã đọc khoảng một tuần log. An toàn không phải feature gắn sau — đó là điều kiện để agent được phép đứng chung network với dữ liệu thật.

Tài liệu tham khảo

• cloudflare/security-audit-skill — skill audit bảo mật nhiều pha cho coding agent
• Build your own vulnerability harness (Cloudflare)
• OWASP GenAI Security Project — rủi ro kiểu agent (excessive agency, prompt injection) và hướng Agent Control Standard