Câu hỏi mà tôi thấy ít người hỏi nhất khi setup coding agent lại là câu quan trọng nhất: nếu nó sai, nó phá được bao xa?

Model thông minh hay không ảnh hưởng đến tỷ lệ lỗi. Nhưng blast radius mới quyết định lỗi đó có thành incident hay không. Một agent trung bình với quyền bị giới hạn tốt sẽ ít nguy hiểm hơn nhiều so với một agent giỏi được cấp full access vào mọi thứ.

Coding agent có quyền giống một dev junior cộng terminal

Một coding agent hiện đại có quyền đọc và sửa cả repo, chạy command tùy ý trên máy, gọi network ra ngoài, kéo secret từ environment, và deploy. Một số còn kết nối MCP tools với side-effect riêng.

Đây là quyền rất lớn. Nếu agent bị prompt injection, hiểu sai task, hoặc tự tin quá mức, hậu quả không chỉ là code xấu. Nó có thể là secret exposure, data leak, destructive command, hoặc deploy nhầm.

Đừng dùng cùng một môi trường cho mọi mức rủi ro

Prototype toy app không giống production app.

Workflow nên tách:

  • Local sandbox cho exploration.
  • Branch riêng cho code changes.
  • Preview environment cho deploy thử.
  • Read-only credentials cho audit.
  • No production database trong agent session mặc định.
  • Manual approval cho command có write/network/credential.

Nếu agent cần production access, đó phải là exception có lý do, không phải default.

Permission prompt phải cụ thể

Prompt yếu:

Be careful.

Prompt tốt:

Do not access production systems.
Do not read secrets unless the task explicitly requires it.
Do not run destructive commands.
Ask before installing packages, changing database schema, calling external APIs, or deploying.
If a step fails, stop and report instead of retrying broadly.

Policy tốt là policy agent có thể thi hành. “Be careful” không thi hành được.

Kiểm blast radius trước khi chạy agent

Trước một task lớn, hỏi:

If this agent makes a wrong change, what can it affect?

Ba câu hỏi không thể bỏ qua:

  • Nó có token cloud hoặc database URL thật không?
  • Nó có thể deploy hoặc ghi file ra ngoài repo không?
  • Có branch/rollback point chưa?

Ngoài ra: quyền network, quyền xóa file, MCP tool có side-effect. Cái nào không rõ thì mặc định coi là “có”.

Nếu câu trả lời là “không biết”, chưa nên chạy tự động dài.

Shadow agents là vấn đề inventory

Một số bài viết security gần đây cảnh báo self-running agents tạo rủi ro vì security team không biết chúng tồn tại. Agent có thể có tool endpoint, server, token, workspace, hoặc automation riêng.

Điểm này áp dụng cả ở scale nhỏ.

Founder, PM, designer hoặc marketer có thể tự tạo một agent workflow để build internal tool. Nó chạy được, nên mọi người dùng. Nhưng không ai biết nó giữ token ở đâu, đọc data gì, deploy lên đâu, và ai chịu trách nhiệm khi hỏng.

Vibe coding có kiểm soát cần inventory:

  • App này do ai own?
  • Agent/tool nào có quyền vào repo?
  • Token nào được dùng?
  • Data nào được upload?
  • Link nào public?
  • Deploy target nào?
  • Rollback ở đâu?

Không có inventory thì không có security.

Chốt lại

Blast radius là thứ duy nhất bạn kiểm soát được trước khi agent chạy. Model quality, prompt quality, hay độ phức tạp của task thì đều không chắc. Nhưng “agent này không có database URL thật” là một sự thật bạn có thể đảm bảo ngay bây giờ, trước khi gõ một chữ nào vào chat.

Đó là lý do ranh giới quan trọng hơn prompt.

Tham khảo