Watch the lesson video: Bảo mật Đại lý AI với Biên lai Mã hóa
(Video bài học và hình thu nhỏ sẽ được nhóm nội dung Microsoft thêm sau khi gộp, theo mẫu bài học 14 / 15.)
Bài học này sẽ bao gồm:
Sau khi hoàn thành bài học này, bạn sẽ biết cách:
Hãy tưởng tượng bạn đã triển khai một đại lý AI cho Contoso Travel. Đại lý nghe yêu cầu của khách, gọi API chuyến bay để tra cứu các lựa chọn và đặt chỗ thay mặt khách. Quý trước, đại lý đã xử lý 50.000 lượt đặt chỗ.
Hôm nay, một kiểm toán viên đến. Họ hỏi một câu đơn giản: “Cho tôi xem đại lý của bạn đã làm gì.”
Bạn giao nộp các tệp nhật ký. Kiểm toán viên xem chúng và hỏi câu khó hơn: “Làm sao tôi biết những nhật ký này không bị sửa đổi?”
Đây chính là vấn đề dấu vết kiểm toán. Hầu hết các triển khai đại lý hiện nay dựa vào:
Không giải pháp nào trong số này có thể trả lời câu hỏi của kiểm toán viên mà không yêu cầu sự tin tưởng vào ai đó (bạn, nhà cung cấp đám mây, nhà cung cấp cơ sở dữ liệu). Với sử dụng nội bộ, sự tin tưởng này thường chấp nhận được. Với khối lượng công việc bị quy định (tài chính, y tế, bất cứ thứ gì chịu tác động của Luật AI EU), thì không thể.
Biên lai mã hóa giải quyết điều này bằng cách khiến mỗi hành động của đại lý có thể được xác minh độc lập. Kiểm toán viên không cần tin bạn. Họ chỉ cần khóa công khai và biên lai.
Biên lai là một đối tượng JSON ghi lại những gì đại lý đã làm, được ký bằng chữ ký số.
flowchart LR
A[Đại lý gọi công cụ] --> B[Xây dựng tải trọng biên lai]
B --> C[Chuẩn hóa JSON RFC 8785]
C --> D[Băm SHA-256]
D --> E[Ký Ed25519]
E --> F[Biên lai có chữ ký]
F --> G[Kiểm toán viên xác minh ngoại tuyến]
G --> H{Chữ ký hợp lệ?}
H -- yes --> I[Bằng chứng chống giả mạo]
H -- no --> J[Biên lai bị từ chối]
Một biên lai tối thiểu trông như sau:
{
"type": "agent.tool_call.v1",
"agent_id": "contoso-travel-bot",
"tool_name": "lookup_flights",
"tool_args_hash": "sha256:a3f9c1...",
"result_hash": "sha256:7b2e1d...",
"policy_id": "contoso-travel-policy-v3",
"timestamp": "2026-04-25T14:30:00Z",
"sequence": 47,
"previous_receipt_hash": "sha256:9d4e6a...",
"signature": {
"alg": "EdDSA",
"sig": "c5af83...",
"public_key": "8f3b2c..."
}
}
Ba thuộc tính thực hiện công việc:
Chữ ký. Biên lai được ký bởi cổng đại lý sử dụng khóa riêng Ed25519. Bất cứ ai có khóa công khai tương ứng đều có thể xác minh chữ ký ngoại tuyến. Việc chỉnh sửa bất kỳ trường nào khiến chữ ký không hợp lệ.
Mã hóa chuẩn hóa. Trước khi ký, biên lai được tuần tự hóa theo JSON Canonicalization Scheme (JCS, RFC 8785). Điều này đảm bảo hai triển khai tạo cùng một biên lai logic sẽ tạo ra đầu ra byte-identical. Nếu không chuẩn hóa, các trình tuần tự hóa JSON khác nhau sẽ tạo ra chữ ký khác nhau cho cùng nội dung.
Liên kết hàm băm. Trường previous_receipt_hash liên kết mỗi biên lai với biên lai trước nó. Việc loại bỏ hoặc thay đổi thứ tự một biên lai sẽ phá vỡ các biên lai đến sau đó. Gian lận trở nên dễ thấy ở cấp chuỗi ngay cả khi vượt qua được chữ ký đơn lẻ.
Cùng nhau, các thuộc tính này cung cấp ba đảm bảo:
Bạn không cần thư viện đặc biệt để tạo biên lai. Các nguyên thủy mã hóa phổ biến và logic chỉ dài vài chục dòng Python.
Các bài tập thực hành trong code_samples/18-signed-receipts.ipynb sẽ hướng dẫn toàn bộ quy trình. Phiên bản tóm tắt:
import json
import hashlib
import base64
from nacl import signing
from jcs import canonicalize # JSON chuẩn RFC 8785
def b64url_nopad(data: bytes) -> str:
return base64.urlsafe_b64encode(data).decode("ascii").rstrip("=")
def sha256_canonical(obj) -> str:
"""SHA-256 of a Python object's JCS-canonical JSON form."""
return f"sha256:{hashlib.sha256(canonicalize(obj)).hexdigest()}"
# Tạo hoặc tải khóa ký (trong môi trường sản xuất, lưu trữ trong kho khóa)
signing_key = signing.SigningKey.generate()
verify_key = signing_key.verify_key
# Xây dựng nội dung biên lai (chưa có chữ ký)
tool_args = {"origin": "SYD", "destination": "LAX"}
tool_result = [{"flight": "QF11", "price": 1850, "stops": 0}]
payload = {
"type": "agent.tool_call.v1",
"agent_id": "contoso-travel-bot",
"tool_name": "lookup_flights",
"tool_args_hash": sha256_canonical(tool_args),
"result_hash": sha256_canonical(tool_result),
"policy_id": "contoso-travel-policy-v3",
"timestamp": "2026-04-25T14:30:00Z",
"sequence": 0,
"previous_receipt_hash": None,
}
# Chuẩn hóa, băm, ký.
canonical_bytes = canonicalize(payload)
message_hash = hashlib.sha256(canonical_bytes).digest()
signature_bytes = signing_key.sign(message_hash).signature
# Đính kèm một đối tượng chữ ký có cấu trúc.
receipt = {
**payload,
"signature": {
"alg": "EdDSA",
"sig": b64url_nopad(signature_bytes),
"public_key": b64url_nopad(bytes(verify_key)),
},
}
Đó là toàn bộ đường dẫn ký. Các bài tập trong notebook sẽ lần lượt qua từng bước.
Xác minh là thao tác nghịch đảo:
import base64
import hashlib
from nacl import signing
from nacl.exceptions import BadSignatureError
from jcs import canonicalize
def b64url_decode(s: str) -> bytes:
padding = "=" * ((4 - len(s) % 4) % 4)
return base64.urlsafe_b64decode(s + padding)
def verify_receipt(receipt: dict) -> bool:
# Chữ ký là một đối tượng có cấu trúc: {"alg", "sig", "public_key"}.
sig_obj = receipt.get("signature")
if not sig_obj or sig_obj.get("alg") != "EdDSA":
return False
# Tái tạo lại phần payload thực sự đã được ký (mọi thứ ngoại trừ chữ ký).
payload = {k: v for k, v in receipt.items() if k != "signature"}
canonical_bytes = canonicalize(payload)
message_hash = hashlib.sha256(canonical_bytes).digest()
try:
verify_key = signing.VerifyKey(b64url_decode(sig_obj["public_key"]))
verify_key.verify(message_hash, b64url_decode(sig_obj["sig"]))
return True
except BadSignatureError:
return False
Hàm này nhận một biên lai và trả về True nếu chữ ký hợp lệ, False nếu không. Không gọi mạng, không phụ thuộc dịch vụ, không phải tin tưởng bất kỳ bên thứ ba nào.
Để thấy ví dụ về phát hiện gian lận, notebook sẽ hướng dẫn:
tool_args_hash.Đây là minh chứng thực tế rằng biên lai dễ phát hiện chỉnh sửa: bất kỳ sửa đổi nào, dù nhỏ, cũng làm vỡ chữ ký.
Một biên lai đã ký bảo vệ một hành động. Một chuỗi biên lai bảo vệ một chuỗi hành động.
flowchart LR
R0[Biên nhận 0<br/>khởi đầu] --> R1[Biên nhận 1]
R1 --> R2[Biên nhận 2]
R2 --> R3[Biên nhận 3]
R1 -. previous_receipt_hash .-> R0
R2 -. previous_receipt_hash .-> R1
R3 -. previous_receipt_hash .-> R2
Mỗi biên lai ghi hàm băm của biên lai trước đó. Để lặng lẽ xóa biên lai số 2, kẻ tấn công sẽ phải:
previous_receipt_hash của biên lai 3 (phá vỡ chữ ký của biên lai 3), HOẶCNếu khóa riêng nằm trong khoá phần cứng và bạn công bố khóa công khai cùng mỗi biên lai, thì cả hai cuộc tấn công đều không thực hiện được mà không bị phát hiện.
Notebook sẽ hướng dẫn:
previous_receipt_hash của mỗi biên lai khớp với hàm băm thực của biên lai trước đó.Đây là cách bạn tạo dấu vết kiểm toán mà kiểm toán viên bên ngoài có thể xác minh mà không cần tin bạn.
Đây là phần quan trọng nhất của bài học. Biên lai rất mạnh nhưng quyền lực của chúng có giới hạn.
Biên lai chứng minh ba điều:
Biên lai KHÔNG chứng minh:
policy_id thực sự đã được đánh giá, hoặc rằng nó sẽ cho phép hành động này nếu được kiểm tra. Biên lai chỉ ghi lại những gì được tuyên bố, không phải những gì được thi hành.Ranh giới này quan trọng vì hai lý do:
Một sai lầm phổ biến là nghĩ rằng “chúng ta có biên lai” nghĩa là “chúng ta được quản trị.” Không phải vậy. Biên lai là nền tảng, quản trị là hệ thống bạn xây dựng lên trên đó.
Mã Python trong bài học này được giữ tối giản để bạn có thể đọc từng dòng và hiểu rõ điều gì đang xảy ra. Trong sản xuất, bạn có hai lựa chọn:
Xây dựng trực tiếp trên nguyên thủy mật mã. 50 dòng mã bạn thấy ở trên đủ cho nhiều trường hợp. PyNaCl (Ed25519) và gói jcs (JSON chuẩn hóa) là các thư viện được bảo trì và kiểm toán tốt.
Sử dụng thư viện biên lai sản xuất. Một số dự án nguồn mở triển khai cùng mẫu này với các tính năng bổ sung (quay vòng khóa, xác minh hàng loạt, phân phối JWK Set, tích hợp với bộ máy chính sách):
draft-farley-acta-signed-receipts) hiện đang trong quá trình tiêu chuẩn hóa.protect-mcp (npm) và @veritasacta/verify (npm) cung cấp triển khai Node cho ký biên lai và xác minh ngoại tuyến, dùng để bao bọc mọi máy chủ MCP với dấu vết kiểm toán phát hiện chỉnh sửa.Quyết định giữa tự viết và dùng thư viện giống với quyết định giữa tự viết thư viện JWT và dùng thư viện đã được kiểm thử: cả hai đều hợp lý; thư viện giúp tiết kiệm thời gian và giảm phạm vi kiểm toán; cách viết lại bắt buộc bạn hiểu kỹ từng nguyên thủy. Bài học này dạy cách viết lại để bạn có nền tảng vững chắc cho cả hai lựa chọn.
Kiểm tra hiểu biết trước khi chuyển sang bài tập thực hành.
1. Biên lai được ký bằng khóa riêng Ed25519 của đại lý. Kiểm toán viên chỉ có khóa công khai. Kiểm toán viên có thể xác minh biên lai ngoại tuyến không?
2. Kẻ tấn công thay đổi trường policy_id trong biên lai để tuyên bố nó được quản lý bởi chính sách cởi mở hơn. Chữ ký được tạo trên payload gốc. Điều gì xảy ra khi xác minh?
3. Tại sao biên lai lại có tool_args_hash và result_hash thay vì các đối số và kết quả thô?
4. Trường previous_receipt_hash liên kết mỗi biên lai với biên lai trước. Nếu kẻ tấn công lặng lẽ xoá một biên lai ở giữa chuỗi, điều gì trở nên không hợp lệ?
5. Một biên lai xác minh hợp lệ. Điều đó có chứng minh hành động của đại lý là đúng, chính xác hoặc tuân thủ chính sách không?
Mở code_samples/18-signed-receipts.ipynb và hoàn thành bốn phần sau:
Thử thách nâng cao 1: mở rộng lược đồ biên lai với một trường bổ sung do bạn chọn (ví dụ, ID yêu cầu để truy vết), cập nhật logic ký chuẩn hóa để bao gồm nó, và xác nhận biên lai vẫn có thể xác minh hoàn chỉnh. Sau đó sửa trường này sau khi ký và xác nhận xác minh thất bại. Điều này giúp bạn hiểu cách từng byte của mã hóa chuẩn hóa đóng góp vào chữ ký. Thử thách nâng cao 2: Băm SHA-256 hai biên lai của bạn cùng nhau (nối các byte chuẩn hóa của chúng theo thứ tự xác định) và nhúng bản tóm tắt kết quả đó làm trường mới trên biên lai thứ ba trước khi ký. Xác minh rằng cả ba biên lai vẫn có thể được chuyến đi hai chiều. Bạn vừa xây dựng một bằng chứng bao gồm một bước: bất kỳ ai giữ biên lai thứ ba có thể chứng minh rằng hai biên lai đầu tiên tồn tại tại thời điểm nó được ký, mà không cần phải tiết lộ nội dung của chúng. Đây là mô hình mà các biên lai tiết lộ có chọn lọc sử dụng ở quy mô lớn (cam kết Merkle, RFC 6962).
Biên lai mật mã cho các tác nhân AI một dấu vết kiểm tra mà:
Chúng không thay thế cho việc xác thực đầu vào, thực thi chính sách, hoặc hạ tầng định danh. Chúng là nền tảng cho các lớp đó. Khi bạn triển khai các tác nhân vào các khối công việc có quy định, quy trình đa tổ chức, hoặc bất kỳ môi trường nào mà kiểm toán viên tương lai không thể mặc định tin tưởng bạn, biên lai là cách bạn giữ cho dấu vết kiểm tra minh bạch.
Điều quan trọng nhất cần nhớ: biên lai chứng minh ai đã nói gì, khi nào. Chúng không chứng minh những gì được nói là đúng hay chính xác. Hãy giữ chặt sự phân biệt đó. Đây là sự khác biệt giữa hệ thống nguồn gốc trung thực và hệ thống gây hiểu lầm.
Khi bạn sẵn sàng chuyển từ bài học này sang triển khai tác nhân ký biên lai trong môi trường thực:
https://your-org.example.com/.well-known/agent-keys.json.Tham gia Microsoft Foundry Discord để gặp gỡ các học viên khác, tham dự giờ làm việc, và được giải đáp các câu hỏi về Tác nhân AI.
Bài học này bao gồm ký biên lai đơn lẻ và chuỗi băm liên kết. Các nguyên thủy giống nhau có thể kết hợp vào một số mẫu nâng cao hơn bạn có thể gặp khi tư thế quản trị phát triển:
authorization_*) và sau thực thi (result_*) với chữ ký độc lập, hữu ích khi quyết định ủy quyền và kết quả quan sát được do các tác nhân khác nhau hoặc ở thời điểm khác nhau sản xuất. Điều này được xây dựng bổ sung trên định dạng biên lai được dạy trong bài học này.result_hash. Tải trọng thực tế thường phong phú hơn một kết quả công cụ đơn lẻ: quá trình suy luận trước quyết định (dự đoán mô hình, các lựa chọn xem xét, bằng chứng và tính đầy đủ của nó, tư thế rủi ro, chuỗi trách nhiệm, kết quả cửa kiểm soát) có thể tất cả tồn tại trong tải trọng, được niêm phong bởi một biên lai duy nhất. Điều này giữ định dạng biên lai tối giản trong khi cho phép sơ đồ tải trọng phát triển theo từng miền.signature.alg có thể mang ML-DSA-65 (chuẩn chữ ký hậu lượng tử NIST) khi bạn cần di cư. Lập kế hoạch giai đoạn chuyển tiếp nơi biên lai được ký kép.Xây dựng Tác Nhân Sử Dụng Máy Tính (CUA)
(Sẽ do người quản lý chương trình học xác định)
Tuyên bố miễn trừ trách nhiệm: Tài liệu này đã được dịch bằng dịch vụ dịch thuật AI Co-op Translator. Mặc dù chúng tôi cố gắng đảm bảo độ chính xác, xin lưu ý rằng bản dịch tự động có thể chứa lỗi hoặc sai sót. Tài liệu gốc bằng ngôn ngữ gốc nên được coi là nguồn tin chính thức. Đối với thông tin quan trọng, nên sử dụng dịch vụ dịch thuật chuyên nghiệp bởi con người. Chúng tôi không chịu trách nhiệm về bất kỳ hiểu lầm hoặc giải thích sai nào phát sinh từ việc sử dụng bản dịch này.