Nhãn ghi trên credential không phải là phạm vi của credential.

Phần mật mã là bất khả xâm phạm. RFC 5054 SRP-6a, AES-256-GCM, so sánh constant-time, zero-knowledge proof. 1Password đã làm đúng phần mật mã. Cái họ làm sai là nhãn trên vỏ hộp.

Tháng này, hai kỹ sư tại Token Security dành ba ngày để reverse-engineer giao thức xác thực SRP độc quyền của 1Password. Họ không đi tìm lỗ hổng. Họ đang cố thay một SCIM bridge bằng một Python client cho công cụ quản lý non-human identity. Những gì họ tìm ra là khoảng cách giữa những gì credential nói nó có thể làm và những gì nó thực sự có thể làm [1][2].

Một service-account token được giới hạn ở một vault, với quyền read, có thể liệt kê mọi người dùng trong tổ chức. Mọi nhóm. Mọi thành viên nhóm. Mọi quyền cấp vault trên mọi vault. Tên, email, trạng thái, mốc thời gian xác thực gần nhất. Nhãn của token ghi "một vault." API thì nói khác [1].

1Password đã xác nhận. Hành vi này là the design. Granular scoping nằm trong roadmap nhưng không có ngày cụ thể [2].

Token thực sự chạm tới những gì

Gil Portnoy và Henry, viết cho Token Security, đã ghi lại năm API endpoint mà một service-account token "một-vault" có thể gọi thành công trọn vẹn [1]:

/api/v2/users trả về mọi người dùng trong tổ chức: UUID, tên, email, trạng thái, loại, mốc thời gian xác thực gần nhất. /api/v1/groups trả về mọi nhóm kèm quyền và trạng thái. Các lệnh CLI cho thành viên nhóm, người dùng và quyền của vault, và các nhóm của vault đều trả về dữ liệu trực tiếp. /api/v3/account trả về metadata tài khoản. /api/v2/vault/{id}/vaultaccess trả về thông tin truy cập vault.

Không endpoint nào trong số này được giới hạn ở đúng vault mà token được cấp. Token được bảo "read một vault." API đưa cho nó tấm bản đồ của toàn bộ tổ chức [1].

Điểm sắc bén hơn ở đây: phép liệt kê không hoạt động qua SDK chính thức của 1Password. Đường đó trả về UNSUPPORTED hoặc FORBIDDEN. Nó hoạt động qua API nội bộ của CLI, thứ mà các nhà nghiên cứu phải reverse-engineer. "Phạm vi" là một hạn chế phía client trong SDK. Credential phía dưới là read toàn tổ chức. Kẻ tấn công không dùng SDK của bạn [1].

Các nhà nghiên cứu dựng client trong khoảng 420 dòng Python. Năm API endpoint. Toàn bộ tầm nhìn về tổ chức. Họ đăng bài viết ngày 16 tháng 7 [1].

Vấn đề không nằm ở ổ khóa. Mà nằm ở chùm chìa khóa.

Các nhà nghiên cứu thận trọng ở điểm này. Phần mật mã thực sự mạnh. Cách triển khai SRP dùng zero-knowledge proof theo chuẩn RFC: server không bao giờ thấy mật khẩu, client không bao giờ thấy salt, và mọi lần xác thực thất bại đều trả về cùng một thông báo lỗi để kẻ tấn công không học được gì. 1Password đã ghi lại các sai lệch phi chuẩn của chính họ (bao gồm một câu lời bài hát của The Beatles trong "Penny Lane" chôn trong một hằng số mật mã như một quả trứng phục sinh) và các sai lệch đó trung lập về bảo mật [1].

Vấn đề không nằm ở ổ khóa. Mà nằm ở thứ mà chìa mở ra. Khi một credential được dán nhãn "giới hạn ở một vault," quản trị viên cấp nó cho agent với niềm tin rằng bán kính ảnh hưởng hẹp. Agent nhận một credential. Credential nhận được sơ đồ tổ chức. Không ai định như vậy, nhưng cũng không ai nhìn thấy điều đó đang xảy ra [1].

Khi bạn đưa cho agent một token "được giới hạn," agent hoạt động trong phạm vi mà API thực thi, chứ không phải phạm vi mà nhãn mô tả. Nếu agent bị xâm phạm, qua prompt injection, một convention file bị đầu độc, một cuộc tấn công chuỗi cung ứng, hay bất kỳ vector nào mà các biện pháp phòng thủ dựa trên văn bản không thể bịt kín hoàn toàn, kẻ tấn công không nhận được một vault. Họ nhận được cấu trúc tổ chức: ai ở nhóm nào, ai có quyền vào vault nào, mỗi người xác thực gần nhất vào lúc nào. Đó là giai đoạn trinh sát của một cuộc xâm phạm, được giao trong một lời gọi API duy nhất [1].

Khoảng cách giữa phạm vi được ghi trong tài liệu và phạm vi thực tế không chỉ có ở 1Password. Mọi API quản lý credential đều đưa ra các quyết định ủy quyền ngầm mà quản trị viên không bao giờ nhìn thấy. Những gì Token Security chứng minh là khoảng cách đó có thật, đo lường được, và khai thác được chỉ với một cuối tuần làm việc và một Frida hook [1].

Một vault được xây cho việc này làm khác đi thế nào

Nhiệm vụ của credential là sống sót trong môi trường nó nằm ở đó. Nếu một token "được giới hạn" có thể âm thầm vẽ lại tổ chức của bạn, thì phạm vi đó chưa bao giờ là thật. Nó chỉ là một nhãn.

Clavitor không dán nhãn credential rồi hy vọng. Agent nhận đúng một credential được đặt tên tường minh, được lấy trực tiếp tại thời điểm gọi, được đưa vào một request duy nhất, rồi biến mất. Không có token thường trực nào để kẻ tấn công tái sử dụng. Không có endpoint vẽ sơ đồ tổ chức nào ẩn sau nhãn phạm vi mà không ai xác minh. Vault không mở khả năng liệt kê cho agent. Agent chạm tới đúng thứ nó được đặt tên để chạm tới, và không gì khác.

Mọi truy cập được ghi log theo đúng agent đã thực hiện, trên vault, chứ không trên endpoint mà agent chạy. Nếu một token bị xâm phạm, bán kính ảnh hưởng là phạm vi của đúng lời gọi đó, chứ không phải cấu trúc tổ chức phía sau.

Các nguyên tắc đằng sau một vault thực thi phạm vi, thay vì dán nhãn nó: Mười quy tắc quản lý credential

Clavitor (@clavitorai) là vault credential được xây cho AI agent, và để chống lại chính chúng. clavitor.ai

Nguồn

[1] Token Security (Gil Portnoy, Henry) — Reversing 1Password's Proprietary SRP Authentication Protocol — @TheTokenSec

[2] @TheTokenSec — chuỗi bài trên X về phát hiện leo thang phạm vi, ngày 16 tháng 7, 2026 — "1Password xác nhận đây là the design, để hỗ trợ các quy trình quản lý vault"