Cho AI agent truy cập môi trường production bằng OIDC thay vì mật khẩu tĩnh

Formal vừa chia sẻ câu chuyện nội bộ về việc để các AI coding agent trên cloud truy vấn trực tiếp vào hạ tầng production của công ty. Điểm mấu chốt không nằm ở việc cấp thêm quyền, mà ở chỗ thay thế hoàn toàn mật khẩu dài hạn bằng OpenID Connect (OIDC) — cơ chế xác thực dựa trên danh tính hạ tầng, cho phép cấp token ngắn hạn, có thể kiểm toán và giới hạn theo chính sách.

Vì sao mật khẩu tĩnh là vấn đề với AI agent?

Formal đặt mục tiêu đưa số lượng secret tồn tại lâu dài trong hạ tầng về bằng không. Với các cloud coding agent như Cursor hay Devin, cách làm cũ là phát cho chúng một API key hoặc mật khẩu tĩnh — nghĩa là một thông tin xác thực có thể bị tái sử dụng, khó thu hồi và gần như không gắn được với từng phiên làm việc cụ thể.

Điều này khiến nhiều đội ngũ e ngại khi cho agent truy cập vào cơ sở dữ liệu hay cụm cloud thật. Nếu không có cách giới hạn phạm vi quyền một cách chi tiết, rủi ro bảo mật là quá lớn so với lợi ích mà agent mang lại.

Luồng xác thực OIDC cho workload máy

OIDC hoạt động như thế nào?

Với workload máy, luồng OIDC diễn ra theo các bước quen thuộc:

• Workload lấy một JWT ngắn hạn từ nhà cung cấp danh tính (IdP) của mình, thường qua biến môi trường hoặc gọi tới metadata endpoint.
• Token này được gửi tới dịch vụ đích (relying party) dưới dạng bearer token.
• Dịch vụ đích tải JWKS endpoint của IdP để lấy khóa công khai, xác minh chữ ký JWT và kiểm tra các claim như audience.
• Nếu mọi điều kiện hợp lệ, yêu cầu được chấp nhận và danh tính máy được ánh xạ sang một identity tương ứng.

Điểm quan trọng là token chỉ tồn tại trong thời gian ngắn, gắn với một audience cụ thể và không thể dùng lại cho dịch vụ khác.

Cách Formal triển khai

Formal bổ sung một số chi tiết đáng chú ý vào luồng chuẩn. Khách hàng có thể đặt điều kiện CEL cho từng tích hợp, nghĩa là token chỉ được chấp nhận khi biểu thức điều kiện trả về đúng. Các trường claim của OIDC cũng được đưa vào hệ thống phân quyền, cho phép định nghĩa điều kiện chi tiết hơn cho từng yêu cầu API.

Nền tảng còn cung cấp endpoint CreateFederationToken để đổi token OIDC lấy một access token ngắn hạn của Connector. Nhờ đó, workload có thể dùng Connector như một proxy chèn thông tin xác thực mà không cần tự lưu trữ credential dài hạn. Các workload dùng SPIFFE cũng được hỗ trợ tự nhiên: Formal xác minh JWT-SVID từ SPIRE giống như mọi token OIDC khác.

Gắn danh tính con người vào phiên agent

Mỗi tích hợp OIDC ánh xạ tới một người dùng máy. Tuy nhiên, phần lớn workload thực tế không hành động thay mặt chính nó: một job CI thường do một người đẩy commit khởi chạy, còn agent trên cloud thường được ai đó kích hoạt từ Slack. Vì vậy, mỗi tích hợp có thể khai báo thêm một claim để Formal quy về danh tính con người, danh tính này xuất hiện trong log và trong đầu vào của chính sách.

Cần phân biệt rõ hai mức độ tin cậy. Danh tính máy được xác thực bằng mật mã, còn danh tính con người chỉ được bên gọi khẳng định. Formal chấp nhận claim đó vì khách hàng tin tưởng hệ thống phát ra nó và đã cấu hình rõ ràng.

Cách tiếp cận này vốn được xây dựng cho một bài toán khác: kiểm soát truy cập cơ sở dữ liệu từ các công cụ BI như Metabase, nơi mỗi truy vấn cần được gắn với người dùng đang đăng nhập. Hóa ra nó khớp gần như hoàn hảo với các cloud coding agent dùng chung trong nhóm.

Những việc agent giờ có thể làm

Sau khi chuyển sang OIDC, Formal áp dụng cho ba nhóm công việc chính:

• Phân tích sản phẩm: agent viết truy vấn SQL trên cơ sở dữ liệu phân tích và tự đọc kết quả. Trước đây kỹ sư phải chạy tay, xuất CSV rồi dán lại vào ngữ cảnh của agent. Nay agent có thể xin phê duyệt từ người sở hữu qua Slack, nêu rõ lý do và thời hạn cần truy cập, sau khi được duyệt thì quyền chỉ gắn với ID phiên agent và đúng cơ sở dữ liệu đã yêu cầu.
• Gỡ lỗi luồng bất đồng bộ: nhà cung cấp workflow orchestration không có MCP server từ xa, nên trước kia không thể cấp quyền mà không dùng credential dài hạn. Nay agent có thể xin quyền đọc ngắn hạn, mọi yêu cầu đều được ghi log và quy về cả agent lẫn kỹ sư khởi chạy.
• Kiểm thử tính năng cloud-native: agent liên kết OIDC với tenant phát triển của Formal và một tài khoản cloud thử nghiệm để kiểm chứng thay đổi trong môi trường thật, thay vì dựa vào mock dễ vỡ.

Bài học cho đội ngũ kỹ thuật tại Việt Nam

Với các doanh nghiệp đang đưa AI agent vào quy trình phát triển, câu chuyện của Formal là gợi ý thực tế: không nên coi agent chỉ là một workload máy khác có thêm một secret dài hạn. Thay vào đó, hãy mô hình hóa mỗi lần chạy của agent như một sự ủy quyền tạm thời, gắn với người khởi chạy, kho mã nguồn và phiên làm việc cụ thể.

Cách làm này giữ quyền truy cập production ở mức chỉ đọc và cần phê duyệt, trong khi môi trường phát triển có thể mở rộng hơn mà không trở thành vĩnh viễn. Khi ranh giới đó rõ ràng, việc cho agent chạm vào hạ tầng thật trở nên ít đáng sợ hơn — và hữu ích hơn nhiều.