Panoorin ang video ng leksyon: Pag-secure sa mga AI Agent gamit ang Cryptographic Receipts
(Ang video ng leksyon at thumbnail ay idaragdag ng Microsoft content team pagkatapos ng pagsasanib, na tumutugma sa pattern ng leksyon 14 / 15.)
Saklaw ng leksyong ito:
Pagkatapos makumpleto ang leksyong ito, malalaman mo kung paano:
Isipin mong mayroon kang isang AI agent para sa Contoso Travel. Binabasa ng agent ang mga kahilingan ng customer, tumatawag ng flights API para maghanap ng mga opsyon, at nagbu-book ng mga upuan para sa customer. Noong nakaraang quarter, ang agent ay nagproseso ng 50,000 booking.
Ngayon, dumating ang isang auditor. Nagtanong siya ng simpleng tanong: “Ipakita mo sa akin ang ginawa ng iyong agent.”
Ibinigay mo ang iyong mga log file. Tiningnan ng auditor ang mga iyon at nagtanong ng mas mahirap: “Paano ko malalaman na hindi inedit ang mga log na ito?”
Ito ang problema ng audit trail. Karamihan sa mga deployment ng agent ngayon ay umaasa sa:
Walang alinman ang makakasagot sa tanong ng auditor nang hindi kinakailangang pagkatiwalaan niya ang isang tao (ikaw, ang iyong cloud provider, o ang iyong database vendor). Para sa internal na gamit, madalas ay katanggap-tanggap ang tiwalang iyon. Para sa mga regulated na trabaho (pananalapi, pangangalagang pangkalusugan, kahit ano na saklaw ng EU AI Act), hindi ito tinatanggap.
Nilulutas ng cryptographic receipts ito sa pamamagitan ng paggawa ng bawat aksyon ng agent na independently verifiable. Hindi na kailangang pagkatiwalaan ng auditor ang iyo. Kailangan niya lamang ang iyong pampublikong susi at ang mismong receipt.
Ang receipt ay isang JSON object na nagtatala ng ginawa ng isang agent, na nilagdaan gamit ang digital signature.
flowchart LR
A[Ang ahente ay gumamit ng isang kasangkapan] --> B[Bumuo ng resibo ng payload]
B --> C[I-canonicalize ang JSON RFC 8785]
C --> D[SHA-256 hash]
D --> E[Ed25519 lagdaan]
E --> F[Resibo na may lagda]
F --> G[Sinusuri ng auditor offline]
G --> H{Wasto ba ang lagda?}
H -- oo --> I[Patunay na may ebidensiya ng pagbabago]
H -- hindi --> J[Tinatanggihan ang resibo]
Ang isang minimal na receipt ay ganito:
{
"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..."
}
}
Tatlong properties ang gumagawa ng trabaho:
Ang signature. Nilalagdaan ang receipt ng gateway ng agent gamit ang isang Ed25519 private key. Sinuman na may katugmang public key ay maaaring i-verify ang signature offline. Ang pamemeke sa anumang field ay nagpapawalang bisa ng signature.
Canonical encoding. Bago lagdaan, isinasagawa ang serializing ng receipt gamit ang JSON Canonicalization Scheme (JCS, RFC 8785). Tinitiyak nito na ang dalawang implementasyon na gumagawa ng kaparehong lohikal na receipt ay magkakaroon ng byte-identical na output. Kung walang canonicalization, iba’t ibang JSON serializer ang gagawa ng magkakaibang signature para sa iisang nilalaman.
Hash chaining. Ang field na previous_receipt_hash ay nag-uugnay ng bawat receipt sa naunang receipt. Ang pagtanggal o pagbabago ng isang receipt ay nagwawasak ng bawat receipt na sumusunod dito. Nagiging visible ang pamemeke sa antas ng chain kahit na lampas sa individual na mga signature.
Sama-sama, nagbibigay ang mga properties na ito ng tatlong garantiya:
Hindi mo kailangan ng espesyal na library para gumawa ng receipt. Malawak ang availability ng cryptographic primitives at ilan lang na linya ng Python ang logic.
Ang hands-on exercises sa code_samples/18-signed-receipts.ipynb ay naglalakad sa buong proseso. Ang pinaikling bersyon:
import json
import hashlib
import base64
from nacl import signing
from jcs import canonicalize # RFC 8785 canonical JSON
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()}"
# Bumuo o mag-load ng signing key (sa produksyon, itago sa key vault)
signing_key = signing.SigningKey.generate()
verify_key = signing_key.verify_key
# Ibuo ang payload ng resibo (walang lagda muna)
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,
}
# Gawing canonical, i-hash, lagdaan.
canonical_bytes = canonicalize(payload)
message_hash = hashlib.sha256(canonical_bytes).digest()
signature_bytes = signing_key.sign(message_hash).signature
# Ilakip ang nakaayos na signature object.
receipt = {
**payload,
"signature": {
"alg": "EdDSA",
"sig": b64url_nopad(signature_bytes),
"public_key": b64url_nopad(bytes(verify_key)),
},
}
Iyan ang buong signing pipeline. Ang mga pagsasanay sa notebook ay sunud-sunod na nagpapakita ng bawat hakbang.
Ang verification ay ang kabaligtaran na operasyon:
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:
# Ang pirma ay isang istrukturadong bagay: {"alg", "sig", "public_key"}.
sig_obj = receipt.get("signature")
if not sig_obj or sig_obj.get("alg") != "EdDSA":
return False
# I-rekonstrukt ang payload na talaga namang pinirmahan (lahat maliban sa pirma).
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
Tumatanggap ang function na ito ng isang receipt at nagbabalik ng True kung valid ang signature, False kung hindi. Walang network call, walang dependency sa serbisyo, walang kailangang tiwala sa anumang third party.
Para makita ang pagtuklas ng pamemeke sa aksyon, ipinapakita ng notebook ang:
tool_args_hash.Ito ang praktikal na demonstrasyon na ang mga receipt ay tamper-evident: anumang pag-modify, gaano man kaliit, ay sumisira sa signature.
Isang solong signed receipt ang pumoprotekta sa isang aksyon. Isang chain ng mga receipt ang pumoprotekta sa isang sunod-sunod.
flowchart LR
R0[Resibo 0<br/>pinagmulan] --> R1[Resibo 1]
R1 --> R2[Resibo 2]
R2 --> R3[Resibo 3]
R1 -. previous_receipt_hash .-> R0
R2 -. previous_receipt_hash .-> R1
R3 -. previous_receipt_hash .-> R2
Nagtatala ang bawat receipt ng hash ng naunang receipt. Para tanggalin nang palihim ang receipt 2, kailangang:
previous_receipt_hash ng receipt 3 (lalabag sa signature ng receipt 3), OKung ang private key ay nasa hardware key vault at nailathala mo ang public key kasama ng bawat receipt, walang alinman sa mga pag-atakeng iyon ang posibleng gawin nang hindi nadedetect.
Pinapakita ng notebook ang:
previous_receipt_hash ng bawat receipt sa tunay na hash ng naunang receipt.Ganito ka gumagawa ng audit trail na maaaring i-verify ng panlabas na auditor nang hindi pinagkakatiwalaan ka.
Ito ang pinakamahalagang seksyon ng leksyong ito. Malakas ang mga receipt ngunit may hangganan ang kanilang kapangyarihan.
Tatlong bagay ang pinatutunayan ng mga receipt:
Hindi pinatutunayan ng mga receipt:
policy_id ay talagang na-evaluate, o na papayagan sana ang aksyon kung sinuri. Itinatala ng receipt ang inangkin, hindi ang ipinapatupad.Mahalaga ang hangganang ito dahil:
Karaniwang pagkakamali ang isipin na “may receipts tayo” ay nangangahulugang “napapamahalaan na tayo.” Hindi iyan totoo. Ang mga receipt ay pundasyon. Ang pamamahala ay ang sistemang itinatayo mo sa ibabaw nito.
Ang Python code sa leksyong ito ay sinadyang minimal para mabasa mo ang bawat linya at maintindihan nang eksakto ang nangyayari. Sa produksyon, may dalawang opsyon ka:
Direktang gumamit ng cryptographic primitives. Ang 50 linya na ipinakita sa itaas ay sapat na para sa maraming gamit. Ang PyNaCl (Ed25519) at ang package na jcs (canonical JSON) ay mahusay na pinapanatili at inaudit na mga library.
Gumamit ng production receipt library. May ilang open-source proyekto na nagpapatupad ng parehong pattern na may dagdag na features (key rotation, batch verification, JWK Set distribution, integration sa mga policy engine):
draft-farley-acta-signed-receipts) na kasalukuyang nasa proseso ng pagiging standard.protect-mcp (npm) at @veritasacta/verify (npm) ay nagbibigay ng Node-based na implementasyon ng pag-sign ng receipt at offline na verification, na nilayon para balutan ang anumang MCP server na may tamper-evident audit trail.Ang pagpili sa pagitan ng paggawa ng sarili mo at paggamit ng isang library ay katulad ng pagpili sa pagitan ng pagsulat ng JWT library mo o paggamit ng subok na library: parehong makatwiran; nakakatipid ang library ng oras at nagpapababa ng audit surface; pinipilitan kang maunawaan nang bawat primitive kapag ikaw ang gumawa. Tinuruan ka ng leksyong ito sa pagpipiliang gumawa mula sa simula upang magkaroon ka ng pundasyon para sa kahit anong pagpili.
Subukan ang iyong pag-unawa bago pumunta sa practice exercise.
1. Nilalagdaan ang isang receipt gamit ang pribadong Ed25519 key ng agent. Ang auditor ay may pampublikong susi lamang. Maaari ba niyang i-verify ang receipt offline?
2. Binago ng attacker ang field na policy_id ng isang receipt upang iangkin na ito ay pinamamahalaan ng mas payapang patakaran. Ang signature ay ginawa sa orihinal na payload. Ano ang mangyayari sa verification?
3. Bakit kasama sa receipt ang tool_args_hash at result_hash sa halip na ang raw na argumento at resulta?
4. Nag-uugnay ang field na previous_receipt_hash ng bawat receipt sa nauna nito. Kung palihim na tatanggalin ng attacker ang isang receipt mula sa gitna ng chain, ano ang nagiging invalid?
5. Malinis na na-verify ang isang receipt. Patutunayan ba nito na tama, matibay, o sumusunod sa polisiya ang aksyon ng agent?
Buksan ang code_samples/18-signed-receipts.ipynb at kumpletuhin ang apat na seksyon:
Pang-extend na hamon 1: dagdagan ang schema ng receipt ng isa pang field na pinili mo (halimbawa, isang request ID para sa pagsubaybay), i-update ang canonical signing logic para isama ito, at kumpirmahin na ang receipt ay dumaan pa rin sa verification. Pagkatapos baguhin ang field pagkatapos ng pagpirma at tiyaking bumigo ang verification. Ito ay pipilitin kang maintindihan kung paano nakakatulong ang bawat byte ng canonical encoding sa signature. Hamong pag-unat 2: I-SHA-256-hash ang dalawa sa iyong mga resibo nang magkasama (pagsamahin ang kanilang mga canonical bytes sa isang tiyak na pagkakasunod-sunod) at isama ang nagresultang digest bilang isang bagong patlang sa isang ikatlong resibo bago ito pirmahan. Patunayan na ang lahat ng tatlong resibo ay maaari pa ring dumaan sa round-trip. Nakabuo ka lang ng isang one-step inclusion proof: sinumang may hawak ng ikatlong resibo ay maaaring patunayan na ang unang dalawang resibo ay umiiral noong ito ay pirmado, nang hindi kinakailangang ibunyag ang kanilang nilalaman. Ito ang pattern na ginagamit ng selective-disclosure receipts sa malakihang sukat (Merkle commitments, RFC 6962).
Ang mga cryptographic receipts ay nagbibigay sa mga AI agent ng audit trail na:
Hindi ito kapalit ng input validation, pagpapatupad ng polisiya, o identity infrastructure. Ito ay pundasyon para sa mga layer na iyon. Kapag nagde-deploy ka ng mga agent sa regulated na mga workload, workflows ng maraming organisasyon, o anumang lugar kung saan hindi maaaring asahan ng isang hinaharap na auditor na pagkatiwalaan ka, ang mga resibo ang paraan upang gawing totoo ang audit trail.
Ang pinakamahalagang aral: pinapatunayan ng mga resibo kung sino ang nagsabi ng ano, at kailan. Hindi nito pinatutunayan na ang sinabi ay totoo o tama. Mahigpit na hawakan ang pagkakaibang iyon. Ito ang pagkakaiba sa pagitan ng isang matapat na sistema ng provenance at isang nakalilinlang.
Kapag handa ka nang umusad mula sa leksyong ito patungo sa pag-deploy ng mga receipt-signed agents sa totoong kapaligiran:
https://your-org.example.com/.well-known/agent-keys.json.Sumali sa Microsoft Foundry Discord upang makipagkita sa iba pang mga nag-aaral, dumalo sa office hours, at sagutin ang iyong mga tanong tungkol sa AI Agents.
Sinasaklaw ng leksyong ito ang single-receipt signing at hash-chained sequences. Ang parehong mga primitive ay bumubuo ng iba pang mas advanced na mga pattern na maaari mong matugunan habang lumalalim ang iyong governance posture:
authorization_*) at post-execution (result_*) na kalahati na may independenteng mga pirma, kapaki-pakinabang kapag ang desisyon sa authorization at ang naobserbahang resulta ay ginawa ng magkaibang partido o sa magkaibang oras. Ito ay komposisyunal na idinadagdag sa format ng resibo na itinuro sa leksyong ito.result_hash. Ang mga totoong payload ay madalas na mas masagana kaysa sa resulta ng isang tool call: ang pre-decision reasoning (model prediction, mga opsyong isinasaalang-alang, ebidensya at pagiging kumpleto nito, risk posture, chain ng pananagutan, resulta ng gate) ay maaaring naroon sa loob ng payload na selyado ng isang resibo. Pinapanatili nitong minimal ang format ng resibo habang pinapayagan ang pag-evolve ng mga schema ng payload ayon sa domain.signature.alg ay maaaring magdala ng ML-DSA-65 (ang NIST post-quantum signature standard) kapag kailangan mong mag-migrate. Magplano para sa transition period kung saan ang mga resibo ay may dual-signature.Pagbuo ng mga Computer Use Agents (CUA)
(Itatakda ng mga tagapangasiwa ng kurikulum)
Pagtatanggi: Ang dokumentong ito ay isinalin gamit ang serbisyo ng AI translation na Co-op Translator. Bagama’t nagsusumikap kami para sa katumpakan, pakatandaan na ang awtomatikong pagsasalin ay maaaring maglaman ng mga pagkakamali o hindi pagkakatugma. Ang orihinal na dokumento sa orihinal nitong wika ang dapat ituring na pangunahing sanggunian. Para sa mahahalagang impormasyon, inirerekomenda ang propesyonal na pagsasalin ng tao. Hindi kami mananagot sa anumang maling pagkakaintindi o maling interpretasyon na nagmula sa paggamit ng pagsasaling ito.