# Give the Agent Its Own Machine

Dan Ndombe · Docker · WeAreDevelopers World Congress NA 2026

> Container chưa đủ cho agent: sandbox giữ secret ngoài tầm nhìn của agent, network proxy inject secret, policy cho từng call và audit trail.

Topics: Sandboxes, Security, Agents

Canonical: https://homus.dev/talks/give-the-agent-its-own-machine

## 1. Luận điểm và ba mục tiêu của talk

![Slide mở đầu Give the Agent Its Own Machine, speaker đứng bên trái Stage 1](https://homus.dev/photos/IMG_3786.JPG)

Slide 01/24 "Give the Agent Its Own Machine", Stage 1.

Mỗi talk ngắn ở Stage 1 là phần giới thiệu cho một workshop hai tiếng. Workshop của Dan đã diễn ra buổi sáng, nên khoảng 30 phút này đi lại những ý chính.

Talk có ba mục tiêu:

- Đi lại phần cơ bản của **SBX**, tức **Docker Sandboxes**.

- Kể, hoặc ít nhất mô tả, cách Docker đang chạy AI agent một cách an toàn trong nội bộ, và cho thấy khán giả dùng được đúng công nghệ đó ngay hôm nay.

- Trả lời câu hỏi về sandbox, hoặc bất cứ điều gì khán giả đã nghe trong ngày, thay mặt team Docker.

Anh bắt đầu từ điều mọi người đã biết về Docker để dịch sang khái niệm mới.

Theo anh, 15 năm qua Docker được biết tới như cách ưa thích để làm cho code **portable**, theo một cách hiệu quả, hay như anh thích nói, theo một cách **complete** (trọn gói). Ngoài việc ship code, developer còn có thể đóng vào **một image duy nhất** cả service, database, library, mọi thứ code cần để chạy, rồi đem image đó phân phối: gửi cho anh, cho khách hàng, cho user, cho kỹ sư khác, mà không phải lo code sẽ không chạy.

## 2. Docker 15 năm qua: làm code portable, và bước chuyển sang agent

![Slide From image to running container: Your API, Base OS libraries, ASP.NET Core Runtime thành Docker Image, push lên Container Registry, pull về Production Box](https://homus.dev/photos/IMG_3788.JPG)

Slide "The foundation: From image to running container".

Speaker nói tiếp: vì ngoài phần code là trái tim của phần mềm, image còn chứa mọi thứ code cần để chạy, nên nó portable. Từ đó bạn có thể đưa code lên [Docker Hub](https://hub.docker.com/), hay bất kỳ container registry nào; Docker Hub là cái đa số trong phòng biết. Ai lấy image của bạn từ registry sẽ nhận được nhiều hơn là code: họ nhận các API, database, và không chỉ "một database" mà đúng **một version cụ thể** của database đó; không chỉ Java mà đúng version Java; không chỉ JavaScript mà đúng version JavaScript. Điều này làm phần mềm portable, và cũng làm rõ cái gì nằm trong gói, cái gì thuộc toàn bộ hệ sinh thái mà bạn đang dùng hoặc đang ship.

Rồi anh chuyển ý: hôm nay không nói về image và container, mà nói về **SBX**, tức sandboxes. Nhưng ý tưởng giống nhau. Với cái anh gọi là "legacy Docker", tức Docker mà đa số mọi người biết, Docker cho **code** một cái máy, một cái hộp để sống. Ngày nay thứ khiến người ta lo hơn là **AI agent đang viết code**, chứ không chỉ bản thân code. Câu hỏi thành: làm sao để agent cũng portable, complete, và secure đúng mức mình muốn, để khi có chuyện hỏng (vì chuyện hỏng thì lúc nào cũng xảy ra) thì **blast radius** (phạm vi thiệt hại) bị giới hạn.

Ý chuyển từ "hộp cho code" sang "máy cho agent" mà speaker nói ở phần này.

Anh nhắc lại slide đã chiếu ở workshop (vài người trong phòng đã xem): không khó để tìm sự cố mới nhất của "công ty yêu thích của bạn". Ví dụ thứ nhất: ai đó vô tình push secret và API key lên GitHub. Ví dụ thứ hai: ai đó bảo agent "dọn data cũ", và agent xoá luôn vài database hoặc vài bảng, vì với nó đó là "data cũ". Anh nói thêm: giờ ai cũng dựa vào README và các file `.md` hướng dẫn agent; nếu kẻ xấu tìm được đường vào một file chứa instructions mà agent đang đọc, họ có thể bắt agent làm đủ thứ, kể cả kiểu như ví dụ thứ hai, nơi agent được bảo làm một việc nó không nên làm.

"README and MD files" ở đây là các file markdown như AGENTS.md, CLAUDE.md. Speaker không nêu tên công ty trong ví dụ xoá database. Một vụ công khai rất giống: tháng 7/2025, agent của Replit xoá database production của SaaStr trong lúc đang "code freeze" ([The Register, 21/07/2025](https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/)). Không chắc speaker ám chỉ vụ này.

## 3. Ba sự cố điển hình và sáu stage của AI agent

Tiếp ví dụ thứ hai: agent có quyền truy cập mọi thứ, vì nó chạy "bare bone", tức chạy trần trên server, không có lớp cách ly nào, và nó đăng vài internal key lên web. Speaker nói tất cả chúng ta đang tiến tới một thế giới autonomous, một tương lai autonomous; đó là tương lai mà ai cũng được hứa. Vì vậy ngày càng có nhiều autonomous agent được giao làm audit, phân tích trọn một codebase và tự quyết định hướng hành động.

Ví dụ thứ ba: một autonomous agent gặp một loạt dependency conflict, tự quyết định sửa, rồi kéo về một đống package ngẫu nhiên trên mạng. Và tất nhiên, chuyện xấu xảy ra.

![Slide Where agents sit today: 6 stage Autocomplete, Assistant, Specialist, Semi-Autonomous, Autonomous, Steward](https://homus.dev/photos/IMG_3789.JPG)

Slide "Where agents sit today", speaker nói mượn từ đồng nghiệp tên Michael.

Phần bối cảnh thứ hai mà anh muốn "level set" là slide này, mượn của đồng nghiệp Michael. Nó cho thấy sự tiến hoá của agent, ít nhất theo góc nhìn của Docker: Docker làm nhiều buổi như thế này, nói chuyện với nhiều developer, và có rất nhiều khách hàng. Hai năm trước, AI agent là **autocomplete**: GitHub Copilot, bạn gõ code và nó gợi ý phần còn lại. Hồi đó cảm giác như phép màu, giờ thì thấy khá nhàm. Chúng ta đang đi về cái anh gọi là **Stage 6**: steward agent hoàn toàn autonomous. Loại đó chưa có nhiều, anh không chắc nó đã tồn tại, nhưng đó là tương lai được hứa.

Anh khảo sát khán phòng bằng giơ tay:

- **Stage 1** hoặc đã qua stage 1, tức từng dùng autocomplete với AI: đa số giơ tay. Anh nói cũng có người chưa bao giờ dùng autocomplete mà nhảy thẳng lên stage 2, nên điều đó cũng có thể.

- **Stage 2**: ChatGPT, Claude Code. Có lẽ là đa số trong phòng.

- **Stage 3**: agentic workflow, một specialist agent phụ trách một việc cụ thể và hy vọng làm tốt việc đó. Vẫn còn khá nhiều tay.

- **Stage 4**, semi-autonomous: anh đếm được ba, bốn, năm người.

- **Stage 5**: vẫn có người giơ tay, anh khen "that's awesome".

## 4. Đa số vẫn đang loay hoay; context file chỉ là "lời gợi ý"

**Stage 6** thì không ai giơ tay. Trước khi đi tiếp, anh nhắc lại điều đã nói ở workshop: rất dễ tưởng rằng ai cũng đã đi rất xa, ai cũng biết mình đang làm gì, còn công ty mình thì tụt lại. Thực tế Docker thấy là mọi người **vẫn đang tìm cách làm "cái AI này"**. Nghe thì cơ bản, nhưng đa số công ty chưa tìm ra cách tạo agent tốt, làm việc đúng một cách ổn định. Và đa số, đó là lý do mọi người có mặt ở đây, chưa tìm ra cách làm điều đó **an toàn**.

Docker nhìn SBX như **lớp nền (foundational layer)** trong lúc mọi người còn đang xác định mình muốn agent làm gì. Khi model ngày càng giỏi hơn, Docker cùng khách hàng học dần cách làm cho an toàn. Anh ví SBX với "Docker năm 2013", lúc container còn chưa thành chuẩn. Anh khẳng định: vài năm nữa sandbox, dù của Docker hay của ai khác, sẽ là cách mặc định người ta chạy agent an toàn.

Lý do mình muốn tiến về stage 6 là nó cho nhiều autonomy hơn; nhiều autonomy hơn nghĩa là năng suất cao hơn, nhiều việc tốt được làm hơn. Nhưng anh hỏi phòng: có đồng ý là autonomy cần guardrail không? Hiển nhiên. Có đồng ý là không thể tin LLM tự đặt guardrail cho chính nó không? Không ai phản đối.

![Slide What most teams do vs. what actually works: soft controls bên trái, hard mechanisms bên phải](https://homus.dev/photos/IMG_3790.JPG)

Slide 09/24 "Security needs layers: What most teams do vs. what actually works". Slide này được nói trong cả phần 4 và phần 5.

Anh nói điều đáng buồn là thứ Docker vẫn đang thấy: ở một số công ty, "top of the line security" hiện nay vẫn là một **context file** với một đống "làm cái này, đừng làm cái kia". Anh gọi đó là **suggestions**, lời gợi ý. Ai biết LLM hoạt động thế nào đều biết context tới một lúc sẽ bị "rửa trôi": nó mờ dần, biến mất, thành không còn liên quan. Nên việc dùng prompt để bảo agent về bảo mật hay về quyền truy cập, cái gì được làm, cái gì không, về cơ bản là vô ích.

## 5. Vì sao container không đủ, và thứ mình thật sự muốn

Context file có thể có tác dụng lúc đầu, rồi đúng lúc bạn ít ngờ nhất, nó không còn đó nữa. Tiếp theo, anh nói "chúng tôi là Docker và chúng tôi làm container", vậy có dùng container để cách ly agent được không? **Về kỹ thuật thì được, nhưng nó không làm điều bạn tưởng.** Cái bạn muốn là cách ly khỏi máy thật của mình. Container chưa bao giờ được thiết kế cho AI agent: Docker container sinh ra cho code rất tĩnh, code không chủ động tìm cách thoát khỏi cái hộp. Nên câu trả lời là không, đừng dùng container cho việc này. Ý định tốt, nhưng đừng làm.

The kernel is still shared" và "MicroVM kernel isolation" trên slide 09/24. Docker giải thích kỹ hơn ở [Why MicroVMs: The Architecture Behind Docker Sandboxes](https://www.docker.com/blog/why-microvms-the-architecture-behind-docker-sandboxes/).

Còn credential để trong một environment file, nếu AI agent đọc được file đó, sửa được file đó, và tự quyết định lúc nào đọc hay không đọc, thì **đó thật sự không phải là một security model**. Thứ mình muốn là cột bên phải của slide.

Anh hỏi ai đã dùng [OpenClaw](https://openclaw.ai/). Trong số đó, bao nhiêu người cài thẳng lên máy mình, không có lớp nào, "bare bones"? Vài tay giơ lên, anh gọi đó là "những người can đảm". Anh đoán những người còn lại dùng một chiếc Mac cũ, một máy tính cũ, hoặc một VM, và vài người gật đầu. Theo anh, đó chính là điều mình muốn. Anh cũng tò mò vì sao người ta làm vậy với OpenClaw mà lại không làm với Claude Code, nhưng đó là chuyện của hôm khác.

Điều mình muốn, theo speaker:

- **Cách ly ở mức VM**, cách ly chi tiết (granular isolation). Không muốn AI agent chạm được tới process và các chức năng cơ bản, tầng nền của máy host nơi nó được cài. Cách thủ công là cài agent lên một máy dư, một MacBook Air cũ hay một Mac mini, "nếu bạn còn tìm được".

- **Ranh giới file và network được cưỡng chế ở ngoài tầm với của agent.** Nhớ lại context file: nếu agent có quyền chọn tuân theo hay không, thì đó có đáng gọi là security model không? Mình muốn luật được áp và được tuân theo **mọi lần**.

- **Credential.** Nếu làm việc thật, agent gần như chắc chắn sẽ gọi một API hay một online service nào đó, và cần secret, credential, đủ loại mật khẩu.

## 6. Secret không nhìn thấy, policy mỗi call, audit trail: đó là SBX

Nhưng nếu đưa những thứ đó cho agent, nó có thể leak. Nên lý tưởng là có cách **inject** secret, cho agent dùng mà không bao giờ nhìn thấy chúng. Tới đây có người trong phòng reo lên, anh đáp là anh cũng hào hứng về điểm này, nó thật sự hay. Tiếp theo là **policy**: được tuân thủ và được đánh giá trên **mọi call**, không tuỳ chọn. Và cuối cùng là **audit trail** đầy đủ, xem được cái gì đã được thử, cái gì đã làm, cái gì bị từ chối, cái gì được cho phép, đặc biệt cần trong môi trường enterprise.

"Và đó chính xác là điều Docker Sandboxes làm." Anh nói sẽ không đi hết mọi tính năng, chỉ vài use case đơn giản, và tập trung vào **kiến trúc** để hiểu vì sao nó chạy được và vì sao đây là cách nên chạy agent. TL;DR của anh: **ranh giới bảo mật cứng**, không phải lời gợi ý; chúng được cưỡng chế chủ động trên mọi call và cưỡng chế ở runtime, không có chuyện tuỳ chọn.

![Slide Run agents in isolation: Its own machine, One directory, A governed network, Secrets it never sees](https://homus.dev/photos/IMG_3791.JPG)

Slide "Docker SBX: Run agents in isolation".

Vậy làm sao cho agent một cái máy riêng, và có thể một hoặc vài thư mục trên máy thật của mình? Speaker bảo hãy nghĩ tới **use case local**: "Tôi là developer, tôi muốn dùng OpenClaw, NanoClaw, Claude Code, Codex hay gì đó trên máy mình mà không cho nó quyền YOLO toàn bộ."

- Anh muốn agent có **máy riêng**.

- Anh muốn nó có quyền vào một thư mục mà anh gọi là **workspace**. Vì agent làm việc thật, mình và nó đang "co-working". Anh không muốn agent tự tạo một thư mục ở đâu đó rồi mình phải đi tìm cách mount. Nên cho nó quyền rất hạn chế vào máy, vào một thư mục nơi có tài liệu và mọi thứ cần, để hai bên cùng làm và agent thật sự có năng suất.

- Anh muốn **network có quản trị**: agent truy cập được những gì là điều quan trọng. Sáng tạo là tốt, nhưng đôi khi kiểm soát tốt hơn là cho truy cập mọi thứ.

- Anh muốn một cách để secret **dùng được**, nhưng agent không nhìn thấy.

Rồi anh hỏi phòng: vì sao agent không có quyền truy cập secret lại là điều tốt?

## 7. Không thấy thì không leak; kiến trúc SBX bắt đầu từ `sbx create`

Có người trả lời, và anh chốt: đơn giản vậy thôi, **không thể leak thứ mà agent chưa từng nhìn thấy**. Anh nói thêm: khi nói "leak", người ta hay tưởng là một vụ hack lớn. Thực ra thường chỉ là commit nhầm một file chứa GitHub key vào version control. Chuyện rất cơ bản. Và nếu key đó hiển thị được với agent theo bất kỳ cách nào, vì nó cần key để chạy process, thì luôn có khả năng key bị leak: đăng lên đâu đó, gửi qua email, dán vào Slack.

SBX đã có cho tất cả mọi người, anh nói chắc mọi người đã nghe câu này "rất, rất, rất nhiều lần" hôm nay. Anh khuyên cài thử, rất dễ cài, theo anh nhớ có trên macOS, Windows và có lẽ cả Linux; tài liệu trên web rất nhiều ([Docker Docs: Docker Sandboxes](https://docs.docker.com/ai/sandboxes/), [Get started](https://docs.docker.com/ai/sandboxes/get-started/)).

![Slide SBX architecture: Host machine chứa Workspace directories, Network policies, Secrets, MicroVM-based sandbox chạy Claude, Network proxy, đi ra Anthropic](https://homus.dev/photos/IMG_3794.JPG)

Slide "Docker SBX: SBX architecture", được giải thích trong phần 7 và 8.

Giờ tới kiến trúc thật, phần anh nói là nơi mọi người hiểu vì sao cách này chạy được và vì sao đây là cách nên dùng để sandbox AI agent. Hãy coi khung xanh là laptop của anh, hoặc server của bạn. Mình chạy `sbx create` (docs chính thức có `sbx create` và `sbx run`, xem [Architecture](https://docs.docker.com/ai/sandboxes/architecture/)) để tạo một sandbox mới. Với sandbox này mình chọn Claude; nhưng cũng có thể dùng Codex, OpenCode, NanoClaw, Hermes, hay bất cứ agent nào ([danh sách agent được hỗ trợ](https://docs.docker.com/ai/sandboxes/agents/)).

Anh nhấn mạnh, rồi nói lại cho rõ: **bạn chạy được bao nhiêu sandbox tuỳ thích trên máy mình**, chấm hết. Ở ví dụ này mình dựng sandbox đầu tiên, nhận được một sandbox dựa trên microVM, bên trong có Claude. Khi dựng còn nhiều thứ khác diễn ra. Đầu tiên là gắn một **workspace directory**: một thư mục trên máy thật, cụ thể là thư mục anh muốn agent được vào. Đó là nơi công việc diễn ra, nơi anh thả tài liệu vào, có khi một sandbox khác hay agent khác cũng thả đồ vào đó. Và gắn được nhiều hơn một thư mục.

## 8. Workspace mount, network proxy và "phép màu" inject secret

Mình quyết định kiểu permission cho từng thư mục. Có thư mục **read-only**, ví dụ để chứa tài liệu. Có thư mục chỉ **một số sandbox cụ thể** được vào. Có thư mục **dùng chung**. Tuỳ bạn. Ở ví dụ này cho đơn giản thì chỉ có một thư mục.

Anh đoán trước câu hỏi mà có người đã hỏi ở workshop: cho agent vào một thư mục, chẳng phải là cho nó vào cả máy sao? Nó không `cd ..` rồi đi ra ngoài được à? Câu trả lời: không phải chỉ đơn giản là cấp quyền thư mục. Còn nhiều thứ diễn ra ở dưới. Anh nghĩ đó là một kiểu **live mounting**: hãy hình dung như một **bản sao được mirror** của thư mục đó, và thứ duy nhất agent trong sandbox nhìn thấy là thư mục bạn chia sẻ, đóng vai home directory của nó.

Docs của Docker mô tả workspace được mount bằng "filesystem passthrough", giữ nguyên đường dẫn tuyệt đối như trên host; ngoài ra có chế độ không mount (file nằm trong sandbox) và chế độ clone (repo host được mount read-only) ([Docker Docs: Architecture](https://docs.docker.com/ai/sandboxes/architecture/)). Chữ "mirrored copy" là cách speaker ví cho dễ hình dung.

Thành phần tiếp theo là **network proxy**, nằm giữa sandbox và mọi traffic: mọi thứ đi ra hay đi vào sandbox đều qua proxy. Vì sao quan trọng? Vì ở đó mình áp được một loạt **policy**, quy định agent được vào đâu, không được vào đâu, và làm "trò inject secret thần kỳ": cho agent dùng secret, key, API mà không bao giờ để chúng hiện ra với agent.

Anh giải thích bằng một hình dung "cực kỳ đơn giản hoá nhưng dễ hiểu":

Năm bước của một request có credential. Key không bao giờ đi vào microVM.

- Claude agent gọi ra ngoài **không kèm authentication**. Ngoài đời thật thì mình sẽ nhận lỗi ngay.

- Nhưng ở đây, khi agent gọi mà không có API key, mình **chặn traffic đó ở network proxy**. Mình biết service nào đang được gọi, traffic định đi đâu, và mình **chèn key vào**. Key đó nằm trên host, không nằm trong sandbox, nên vẫn ngoài tầm với.

- Request có đúng key được forward tới Anthropic.

- Traffic quay về với response.

- Mình **gỡ mọi thứ agent không nên thấy**, rồi mới trả traffic về sandbox.

Kết quả: sandbox nói chuyện được với Anthropic, YouTube, GitHub hay bất cứ service nào bạn cho phép, nhưng **không bao giờ thật sự cầm credential**, vì credential được chèn ở runtime.

Docs mô tả cơ chế này cụ thể hơn: trong sandbox chỉ có một giá trị "sentinel" (giá trị giả), proxy trên host thay sentinel bằng credential thật sau khi request đã rời microVM, và "the real credential stays outside the sandbox throughout the request" ([Docker Docs: Architecture](https://docs.docker.com/ai/sandboxes/architecture/); cấu hình credential ở [Configuration](https://docs.docker.com/ai/sandboxes/configuration/)).

## 9. Chạy nhiều sandbox cùng lúc, một control tower cho mọi agent

"Đơn giản vậy thôi." Cách chạy một sandbox cũng là cách chạy nhiều sandbox. Trên máy cá nhân của anh, anh nghĩ đang có khoảng **15 sandbox chạy cùng lúc**, làm đủ thứ việc, vài cái là Claude, Codex, hay gì đó. Bạn tự quyết định làm gì với framework được trao.

Sandbox nối chung thư mục và proxy, secret và policy có thể khác nhau cho từng sandbox.

Ví dụ bạn có thể cho một loạt sandbox cùng nối vào đúng một thư mục, cùng một proxy. Có secret chỉ một số sandbox dùng được, số khác thì không. Có network policy áp cho vài sandbox mà không áp cho sandbox khác. Đây là một **framework**: nó cho bạn độ chắc chắn, độ an toàn, ranh giới cứng; nhưng dùng ranh giới đó như thế nào là tuỳ bạn. Và đó là phần cơ bản của những gì SBX làm. Còn làm được đủ thứ khác, nhưng vì thiếu thời gian nên anh không đi hết; tài liệu thì rất nhiều, và có lẽ mọi người đã xem ở các talk trước.

Anh tin đây là cách người ta sẽ dùng agent trong tương lai. Tất nhiên đã có cách sandbox "out of the box" trong từng agent; ví dụ Claude làm khá tốt việc tránh làm điều sai và tự kiểm tra. Nhưng nếu là developer muốn có Codex, Claude, [NanoClaw](https://github.com/qwibitai/nanoclaw) và OpenClaw chạy cùng nhau trong một "mớ hỗn độn hay một tác phẩm đẹp, tuỳ bạn gọi", thì bạn sẽ phải trông chờ **từng nhà cung cấp** tự làm sandbox chạy được với provider hay model của họ.

SBX **không quan tâm** bạn dùng agent đóng gói sẵn từ Anthropic, từ OpenAI, OpenClaw, NanoClaw, [Hermes](https://github.com/NousResearch/hermes-agent), hay một agent bạn vừa viết sáng nay. Lớp nền, hệ thống, ranh giới cứng đều giống nhau, và bạn có **một control tower** cho biết agent nào đang làm gì.

Và khi agent "go rogue", chạy `rm -rf`, thì chuyện xấu sẽ xảy ra, nhưng chỉ xảy ra **trong phạm vi quyền bạn đã cấp**. Trong trường hợp của anh, nó chỉ xoá được những gì nằm trong thư mục anh cho phép.

## 10. Phục hồi khi agent phá, SBX kits, và lời mời thử

Còn nếu bạn đã làm những việc cơ bản mà developer nào cũng làm, như version control, dùng GitHub, có backup, thì khi thư mục bị xoá sạch, bạn chỉ cần quay về trạng thái tốt gần nhất (known good state) và chạy lại được ngay.

Với **SBX kits**, bạn có những "công thức" (recipe) giống như Dockerfile: dựng lại sandbox rất nhanh, trong vài giây, và quay lại làm việc gần như tức thì ([Docker Docs: Customize, gồm template và kit](https://docs.docker.com/ai/sandboxes/customize/); danh sách kit cộng đồng: [awesome-docker-sbx](https://github.com/ajeetraina/awesome-docker-sbx)).

Ba lớp speaker ghép lại ở phần kết.

Lời kết: hãy thử SBX, nó đã có sẵn; Google "Docker sbx" là thấy ([trang sản phẩm Docker Sandboxes](https://www.docker.com/products/docker-sandboxes/)). Anh cũng nhắc Docker đang chuẩn bị một bản **cloud** của SBX. Anh nói Docker rất hào hứng về sản phẩm này: đây là cách Docker đang chạy agent trong nội bộ, và anh hy vọng mọi người cũng sẽ dùng.

## Nguồn và link

- Agenda, xác định speaker và slot 15:00 Stage 1: [Luma, WeAreDevelopers World Congress North America (with Docker & GitHub)](https://luma.com/fdz7uw6n)

- Tài liệu chính thức: [Docker Sandboxes](https://docs.docker.com/ai/sandboxes/) · [Get started](https://docs.docker.com/ai/sandboxes/get-started/) · [Architecture](https://docs.docker.com/ai/sandboxes/architecture/) · [Security](https://docs.docker.com/ai/sandboxes/security/) · [Configuration](https://docs.docker.com/ai/sandboxes/configuration/) · [Customize (kits)](https://docs.docker.com/ai/sandboxes/customize/) · [Agents](https://docs.docker.com/ai/sandboxes/agents/)

- Trang sản phẩm: [Docker Sandboxes](https://www.docker.com/products/docker-sandboxes/); blog kiến trúc: [Why MicroVMs](https://www.docker.com/blog/why-microvms-the-architecture-behind-docker-sandboxes/)

- Nền tảng Docker cũ: [Docker overview](https://docs.docker.com/get-started/docker-overview/) · [Docker Hub](https://hub.docker.com/)

- Agent được nhắc: [OpenClaw](https://openclaw.ai/) · [NanoClaw](https://github.com/qwibitai/nanoclaw) · [Hermes Agent](https://github.com/NousResearch/hermes-agent) · [Claude Code](https://code.claude.com/docs/en/overview) · [Codex CLI](https://github.com/openai/codex) · [OpenCode](https://opencode.ai/) · [GitHub Copilot](https://github.com/features/copilot)

- Sự cố tương tự ví dụ "dọn data cũ": [The Register về vụ Replit và SaaStr](https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/) (speaker không nêu tên, đây là ví dụ tôi thêm)

- Slide của Michael (sáu stage): chưa tìm được nguồn.