Làm Cùng Long.
← Quay lại Kho ghi chú
Automation & AI Workflow · 10 phút đọc ·

Cloud Run Sandboxes + Apps Script: tách “AI suy luận” khỏi “code chạy thật” để automation an toàn hơn

Google Apps Script rất tiện khi workflow nằm trong Google Workspace.

Bạn có thể:

  • đọc và ghi Google Sheets;
  • gửi Gmail;
  • thao tác Drive;
  • tạo Docs;
  • gọi HTTP API;
  • chạy trigger theo lịch.

Nhưng Apps Script không phải một runtime Python tổng quát.

Và khi AI bắt đầu sinh code động, có một câu hỏi còn quan trọng hơn:

Có nên chạy code do AI tạo ra ngay trong môi trường đang giữ quyền truy cập dữ liệu và tài khoản của mình không?

Câu trả lời an toàn thường là: không nên mặc định như vậy.

Một bài viết của Kanshi Tanaike trên Google Cloud Community trình bày pattern kết hợp Apps Script với Cloud Run Sandboxes: Apps Script điều phối workflow, còn Python/Bash được chạy trong sandbox cô lập bằng gVisor.

Tôi thấy giá trị của pattern này không nằm ở demo heatmap.

Nó nằm ở cách tách reasoning, orchestration và execution thành những vùng tin cậy khác nhau.

Mục lục

1. Vấn đề thật không phải “Apps Script không chạy được Python”

Nếu chỉ cần tính toán đơn giản, Apps Script JavaScript làm được rất nhiều.

Lý do muốn đưa Python vào thường là:

  • pandas;
  • numpy;
  • scipy;
  • matplotlib;
  • thư viện ML;
  • xử lý file;
  • thống kê;
  • code có sẵn trong ecosystem Python.

Cách nghĩ ngây thơ là:

“Apps Script thiếu Python → tìm cách chạy Python.”

Nhưng khi code được AI sinh động, bài toán đổi thành:

“Làm sao chạy code mà mình chưa hoàn toàn tin tưởng?”

Đây là bài toán security boundary.

Ứng dụng chính có thể giữ:

  • OAuth token;
  • Workspace permission;
  • data;
  • secret;
  • network access.

Code động không nên mặc định thừa hưởng toàn bộ quyền đó.

Sandbox giúp tách hai vùng.

2. Kiến trúc Apps Script → Sandbox hoạt động thế nào?

Pattern trong bài viết có thể rút gọn thành:

Google Sheet
   ↓
Apps Script
   ↓ HTTPS request
Cloud Run service
   ↓
gVisor sandbox
   ↓
Python / Bash
   ↓
structured stdout
   ↓
Apps Script
   ↓
Sheet / Drive / UI

Apps Script đóng vai orchestrator.

Sandbox đóng vai execution worker.

Ví dụ với heatmap:

  1. Apps Script đọc một vùng dữ liệu trong Sheet.
  2. Script chuẩn bị payload và Python logic.
  3. Payload được gửi tới endpoint Cloud Run.
  4. Python trong sandbox dùng pandas/matplotlib để tính correlation và render ảnh.
  5. Ảnh được encode Base64 vào JSON.
  6. Apps Script nhận JSON, decode ảnh và chèn vào Sheet.

Điểm hay ở đây là Apps Script không cần trở thành Python runtime.

Nó chỉ cần gửi input và nhận output có contract rõ.

3. gVisor sandbox tạo boundary gì?

Google Cloud docs mô tả Cloud Run Sandboxes là môi trường cô lập để chạy agent code, data transformation và script trong instance hoặc job.

Feature hiện ở trạng thái Preview.

Trong demo của tác giả, các test kiểm tra nhiều boundary như:

  • metadata server không truy cập được từ sandbox mặc định;
  • biến môi trường nhạy cảm của host được che;
  • root filesystem read-only theo setup;
  • outbound egress bị block nếu không bật;
  • Bash/Python chạy trong gVisor.

Đây là tinh thần quan trọng:

Sandbox nên default-deny nhiều thứ mà code không cần.

Nếu task chỉ là tạo heatmap từ một JSON input, code không cần:

  • đọc credential host;
  • gọi internet;
  • sửa filesystem ngoài temp;
  • truy cập metadata server.

Mỗi quyền không cấp là một rủi ro được giảm.

4. Demo correlation heatmap cho thấy điều gì?

Heatmap chỉ là ví dụ, nhưng minh họa khá tốt cách thiết kế input/output.

Python nhận một table dạng JSON.

Nó:

  • tạo DataFrame;
  • tính correlation matrix;
  • render chart trong memory;
  • encode PNG thành Base64;
  • in một JSON duy nhất ra stdout.

Apps Script chỉ cần hiểu contract:

{
  status,
  image_base64,
  variables,
  records_processed
}

Tôi thích phần này vì nó giảm coupling.

Apps Script không cần biết:

  • matplotlib setup thế nào;
  • pandas tính matrix ra sao;
  • font cache nằm đâu.

Sandbox không cần biết:

  • Sheet nào đang mở;
  • user nào đang click menu;
  • ảnh sẽ được đặt ở cell nào.

Hai bên chỉ thống nhất input/output.

Đây là pattern có thể áp dụng rộng:

thin orchestrator + isolated compute worker.

5. Đọc đúng các con số latency trong bài demo

Bài viết đưa ra các kết quả khá hấp dẫn.

Trong test của tác giả:

  • cold start request đầu mất khoảng 3,6 giây round-trip;
  • phần Cloud Run container provisioning chiếm khoảng 3,16 giây;
  • sandbox fork + Python execution khoảng 449 ms;
  • các lần warm sau có round-trip khoảng 322–539 ms;
  • server-side sandbox processing khoảng 201–411 ms;
  • demo heatmap được mô tả khoảng 350 ms ở bước sandbox execution.

Cần nhấn mạnh:

Đây là số liệu của demo cụ thể, không phải SLA của Cloud Run Sandboxes và không nên dùng để hứa latency production.

Latency thực tế phụ thuộc:

  • region;
  • image;
  • dependency;
  • payload;
  • cold start;
  • CPU/memory;
  • network;
  • concurrency;
  • workload.

Điều có giá trị hơn con số là profile:

cold start và warm execution rất khác nhau.

Nếu workflow chạy một lần mỗi ngày, cold start có thể chấp nhận được.

Nếu là custom function tương tác trong Sheet, vài giây có thể ảnh hưởng UX.

Kiến trúc phải dựa vào use case, không chỉ benchmark đẹp.

6. AI sinh code và sandbox chạy code là hai responsibility khác nhau

Bài viết còn đề xuất Gemini sinh Python động từ natural language.

Đây là chỗ cần guardrail mạnh hơn.

Tôi sẽ tách pipeline:

User intent
  ↓
LLM generates code
  ↓
Static checks / policy
  ↓
Sandbox execution
  ↓
Output validation
  ↓
Application consumes result

Không nên:

User prompt
  ↓
LLM code
  ↓
chạy thẳng bằng quyền ứng dụng

Vì sandbox chỉ là một lớp.

Trước khi execution còn có thể kiểm tra:

  • import nào được phép;
  • timeout;
  • input size;
  • output size;
  • network;
  • filesystem;
  • process spawning;
  • memory;
  • banned commands;
  • secret pattern.

Sau execution cần kiểm tra output:

  • valid JSON không;
  • schema đúng không;
  • có unexpected field không;
  • file có đúng mime không;
  • stderr có gì;
  • exit code;
  • resource usage.

AI-generated code không nên được tin chỉ vì nó “trông đúng”.

7. Sandbox không biến code nguy hiểm thành code an toàn

Một sandbox tốt giảm blast radius.

Nó không làm code sai trở thành đúng.

Ví dụ code có thể:

  • tính sai;
  • loop vô hạn tới timeout;
  • dùng quá nhiều memory;
  • tạo output độc hại;
  • đọc input sai schema;
  • hallucinate package;
  • cho kết quả thống kê sai.

Do đó security và correctness là hai lớp khác nhau.

Security question

Code có phá ra ngoài boundary không?

Correctness question

Code có làm đúng việc không?

Cần cả hai.

Một data workflow có thể “an toàn” theo nghĩa không lộ secret nhưng vẫn đưa quyết định sai vì phép tính sai.

Vì vậy, với action quan trọng, nên có test hoặc validator deterministic.

8. So với Managed Agent: deterministic compute hay open-ended agent?

Tác giả so Cloud Run Sandboxes với một pattern Managed Agent trước đó.

Tôi không xem hai thứ là đối thủ trực tiếp.

Chúng giải quyết hai loại công việc.

Sandbox compute

Phù hợp khi:

  • input rõ;
  • code rõ;
  • output rõ;
  • task ngắn;
  • cần thư viện compute;
  • cần isolation;
  • chạy lặp lại nhiều lần.

Managed / open-ended agent

Phù hợp khi:

  • task mơ hồ;
  • cần nhiều lượt;
  • cần tự chọn tool;
  • cần đọc file rồi quyết định bước tiếp;
  • session có state dài;
  • cần self-correction.

Một workflow tốt có thể dùng cả hai:

Agent reasoning
  ↓
quyết định cần phép tính
  ↓
generate/select deterministic code
  ↓
sandbox compute
  ↓
structured result
  ↓
agent reasoning tiếp

Đây là hybrid architecture.

Agent không cần tự làm toán bằng token nếu có thể giao cho code.

Code không cần tự quyết định business intent nếu agent có thể làm phần judgement.

9. Ứng dụng thực tế trong marketing và data

Pattern này rất hợp với người đang dùng Google Sheets làm operational surface.

1. Phân tích dữ liệu marketing

Sheet → Python stats → bảng/charts → Sheet.

Ví dụ:

  • correlation;
  • cohort;
  • anomaly;
  • clustering nhẹ;
  • forecast;
  • data quality.

2. Xử lý file

Drive file → sandbox conversion/parse → structured JSON → Sheet.

3. Report generation

Apps Script lấy data → sandbox tạo chart/table → Docs/Slides.

4. Creative QA

Apps Script gửi metadata/asset info → Python kiểm tra dimension, file, naming → trả report.

5. AI-assisted data cleaning

LLM đề xuất transformation → sandbox chạy trên sample → compare trước/sau → human approve → mới áp batch.

Pattern cuối đáng chú ý:

AI đề xuất, sandbox thử, con người duyệt, automation áp.

Không phải:

AI nghĩ gì chạy đó.

10. Blueprint triển khai an toàn

Nếu áp dụng pattern này, tôi sẽ chia làm bốn phase.

Phase 1 — Deterministic first

Chưa dùng AI sinh code.

Viết sẵn Python function cho một job cụ thể.

Mục tiêu: chứng minh Apps Script ↔ Cloud Run contract hoạt động.

Phase 2 — Sandboxed input

Cho phép user thay parameter, chưa thay code.

Mục tiêu: validate schema, timeout, error handling.

Phase 3 — AI suggests code

Gemini sinh code nhưng chỉ chạy trên sample/test data.

Log đầy đủ code, input hash và output.

Phase 4 — Controlled production

Chỉ những template đã pass validator mới được chạy production.

Action có side effect vẫn tách approval.

Các checklist tối thiểu:

  • authentication giữa Apps Script và Cloud Run;
  • không public endpoint nếu không cần;
  • input schema validation;
  • max payload;
  • timeout;
  • CPU/memory limit;
  • egress default off;
  • filesystem restricted;
  • structured stdout;
  • stderr capture;
  • audit log;
  • retry policy;
  • cost cap;
  • kill switch.

Cloud Run Sandboxes đang ở Preview, vì vậy production-critical workflow cần cân nhắc mức support, thay đổi API và fallback.

Điểm tôi thích nhất ở kiến trúc này không phải “Apps Script chạy được Python”.

Nó là một nguyên tắc rộng hơn:

Không để AI reasoning, application privilege và arbitrary code execution nằm chung một trust zone.

Khi tách ba lớp này, automation có thể mạnh hơn mà boundary vẫn rõ.

Đó là điều chúng ta sẽ cần ngày càng nhiều khi AI agent bắt đầu được trao quyền hành động thật.

Đọc tiếp trong Series Agentic Stack 2026

Nguồn tham khảo

Ghi chú: các số latency, PASS rate và so sánh runtime trong bài là số liệu của implementation/demo mà tác giả công bố. Chúng không phải benchmark chung hay SLA chính thức của Cloud Run.