పాఠం వీడియో చూడండి: క్రిప్టోగ్రాఫిక్ రసీదులతో AI ఏజెంట్లను రక్షించడం
(Microsoft కంటెంట్ బృందం విలీనం తర్వాత పాఠం వీడియో మరియు థంబ్నెయిల్ జతచేయబడతాయి, పాఠం 14 / 15 నమూనాతో సరిపోతుంది.)
ఈ పాఠం ఇందులో తెలుగు చేస్తుంది:
ఈ పాఠం పూర్తిచేసిన తర్వాత, మీరు ఎలా చేయాలో తెలుసుకుంటారు:
మీరు Contoso Travel కోసం AI ఏజెంట్ ని అమలు చేసారని ఊహించుకోండి. ఏజెంట్ కస్టమర్ అభ్యర్థనలు చదివి, ఫ్లైట్స్ API ద్వారా ఎంపికలను చూస్తుంది మరియు కస్టమర్ తరఫున సీట్లను బుక్ చేస్తుంది. గత త్రైమాసికంలో, ఏజెంట్ 50,000 బుకింగ్లను ప్రాసెస్ చేశాడు.
ఈరోజు ఓ ఆడిటర్ వచ్చారు. వారు అడుగుతారు: “మీ ఏజెంట్ ఏం చేసిందో చూపించండి.”
మీరు మీ లాగ్ ఫైల్స్ అందిస్తారు. ఆడిటర్ వాటిని చూసి కష్టం గల ప్రశ్న అడుగుతారు: “నేను ఎలా తెలుసుకోగలను ఈ లాగులు సవరించబడలేదని?”
ఇది ఆడిట్-ట్రెయిల్ సమస్య. ఈ రోజుతో చాలా ఏజెంట్ అమ్లనా:
ఈ లాగులు ఆడిటర్ ప్రశ్నకు జవాబు ఇవ్వలేవు ఏదైనా ఒకరిపై (మీ, క్లౌడ్ ప్రొవైడర్, డేటాబేస్ విక్రేత) నమ్మకం అవలంబించవలసి ఉంటుంది. అంతర్గత వాడుక కోసం అది గమనించద్రువమైనది, నియంత్రిత లోడ్ల (ఫైనాన్స్, ఆరోగ్యం, EU AI చట్టం కోసం) కోసం అవును కాదు.
క్రిప్టోగ్రాఫిక్ రసీదులు ఈ సమస్యను పరిష్కరిస్తాయి, ప్రతి ఏజెంట్ చర్యను స్వతంత్రంగా ధృవీకరించగలుగుతున్నది. ఆడిటర్ మీమీద నమ్మకము అవసరం లేదు. వారికి మీ పబ్లిక్ కీ మరియు రసీదు మాత్రమే కావాలి.
ఒక రసీదు అనేది ఏజెంట్ చేసిన దాన్ని రికార్డ్ చేసే JSON ఆబ్జెక్ట్, డిజిటల్ సంతకంతో సంతకం చేయబడింది.
flowchart LR
A[ఏజెంట్ ఒక టూల్ను కాల్ చేస్తాడు] --> B[రిసీట్ లోడ్ తయారు చేయండి]
B --> C[JSON RFC 8785 ని కెనానికలైజ్ చేయండి]
C --> D[SHA-256 హ్యాష్]
D --> E[Ed25519 సంతకం]
E --> F[సంతకంతో కూడిన రిసీట్]
F --> G[ఆడిటర్ ఆఫ్లైన్లో ధృవీకరిస్తాడు]
G --> H{సంతకం చెల్లుబాటు కదా?}
H -- అవును --> I[టాంపర్-సాక్ష్య పూర్వక ప్రమాణం]
H -- కాదు --> J[రిసీట్ తిరస్కరించబడింది]
కనిష్ట రసీదు ఇలా ఉంటుంది:
{
"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..."
}
}
మూడు గుణాలు పనులు చేస్తున్నాయి:
సంతకం. ఈ రసీదు ఏజెంట్ గేట్వే ద్వారా Ed25519 ప్రైవేట్ కీతో సంతకం చేయబడింది. సంబంధిత పబ్లిక్ కీ ఉన్న ఎవరు అయినా ఆన్లైన్ కాని ఆఫ్లైన్ ధృవీకరించవచ్చు. ఏ ఫీల్డ్ లోని మార్పు సంతకాన్ని అవాస్తవం చేస్తుంది.
కెనానికల్ ఎంకోడింగ్. సంతకం ముందు రసీదు JSON కెనానికలైజేషన్ స్కీమ్ (JCS, RFC 8785) తో సీరియలైజ్ చేయబడుతుంది. ఇది రెండు అమలేల ఒకే లాజికల్ రసీదు సృష్టించినప్పుడు బైట్-సరసన అవుట్పుట్ ఇస్తుందని నిర్ధారిస్తుంది. కెనానికలైజేషన్ లేకుంటే వేరే JSON సీరియలైజర్లు వేర్వేరు సంతకాలు ఉత్పత్తి చేస్తాయి.
హ్యాష్ చెయినింగ్. previous_receipt_hash ఫీల్డ్ ప్రతి రసీదును మునుపటి రసీదు తో లింక్ చేస్తుంది. ఒక రసీదును తీసేయడం లేదా పునఃఆర్డర్ చేయడం తరువాత వచ్చిన ప్రతి రసీదును పాడుచేస్తుంది. మార్పిడి చెయిన్ స్థాయిలో కనిపిస్తుంది, ఎIndividual signatures ఆపేయబడినప్పటికీ.
ఈ లక్షణాలు కలిసి మూడు హామీలు ఇస్తాయి:
రసీదు చేర్చడానికి ప్రత్యేక లైబ్రరీ అవసరం లేదు. క్రిప్టోగ్రాఫిక్ ప్రిమిటివ్లు విస్తృతంగా అందుబాటులో ఉంటాయి, లాజిక్ కొన్ని పాఠాల Python కోడ్ మాత్రమే.
code_samples/18-signed-receipts.ipynb లో హ్యాండ్-ఆన్ వ్యాయామాలు పూర్తి సహాయంగా ఉంటాయి. సంక్షిప్తం:
import json
import hashlib
import base64
from nacl import signing
from jcs import canonicalize # RFC 8785 క్యానానికల్ 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()}"
# సంతకం కోసం కీని ఉత్పత్తి చేయండి లేదా లోడ్ చేయండి (ఉత్పత్తిలో, కీ వాల్ట్లో నిల్వ చేయండి)
signing_key = signing.SigningKey.generate()
verify_key = signing_key.verify_key
# రసీదు లోడ payloadని నిర్మించండి (ఇప్పుడిగానీ సంతకం లేదు)
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,
}
# క్యానానికలైజ్ చేయండి, హ్యాష్ చేయండి, సంతకం చేయండి.
canonical_bytes = canonicalize(payload)
message_hash = hashlib.sha256(canonical_bytes).digest()
signature_bytes = signing_key.sign(message_hash).signature
# ఘటనా సంతకం ఆబ్జెక్టును జతచేయండి.
receipt = {
**payload,
"signature": {
"alg": "EdDSA",
"sig": b64url_nopad(signature_bytes),
"public_key": b64url_nopad(bytes(verify_key)),
},
}
ఇది మొత్తం సంతకం పైప్లైన్. నోట్బుక్里的 ప్రయోగాలు ప్రతి దశను స్పష్టంగా చూపిస్తాయి.
ధృవీకరణ వ్యతిరేక చర్య:
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:
# సంతకం ఒక నిర్మాణాత్మక αντικరం: {"alg", "sig", "public_key"}.
sig_obj = receipt.get("signature")
if not sig_obj or sig_obj.get("alg") != "EdDSA":
return False
# వాస్తవానికి సంతకం చేయబడిన పేమెంట్ను పునర్నిర్మించండి (సంతకాన్ని తప్పించి అన్ని).
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
ఈ ఫంక్షన్ రసీదును తీసుకుంటుంది మరియు సంతకం సరైనదైతే True ని, కాదైతే False ని ఇస్తుంది. నెట్వర్క్ కాల్, సర్వీస్ ఆధారితం అవసరం లేదు.
మార్పిడిని ప్రదర్శించడానికి నోట్బుక్ లో:
tool_args_hash ఫీల్డ్లో ఒక్క బైట్ మార్చడం.ఇది రసీదులు మార్పులు గమనించగలిగినవి అన్న ఆచరణాత్మక నిరూపణ.
ఒకే ఒక్క సంతకం చేసిన రసీదు ఒక చర్యను రక్షిస్తుంది. రసీదుల చెయిన్ శ్రేణిని రక్షిస్తుంది.
flowchart LR
R0[రసీదు 0<br/>సృష్టి] --> R1[రసీదు 1]
R1 --> R2[రసీదు 2]
R2 --> R3[రసీదు 3]
R1 -. previous_receipt_hash .-> R0
R2 -. previous_receipt_hash .-> R1
R3 -. previous_receipt_hash .-> R2
ప్రతి రసీదు గత రసీదు యొక్క హ్యాష్ను రికార్డు చేస్తుంది. మద్యలో 2వ రసీదును నిశ్శబ్దంగా తీసేసేందుకు, దొంగ ఈ క్రింది రెండు పనులు చేయవలసి ఉంటుంది:
previous_receipt_hash ఫీల్డ్ ని మార్చడం (రసీదు 3 సంతకం తిరస్కరించబడుతుంది), లేదాప్రైవేట్ కీ హార్డ్వేర్ కీ వాల్ట్లో ఉంటే మరియు ప్రతి రసీదుతో పబ్లిక్ కీ ప్రచురిస్తే, ఎటువంటి దాడి గుర్తింపు లేకుండా సాధ్యం కాదు.
నోట్బుక్ లో:
previous_receipt_hash నిజమైన హ్యాష్ కి సరిపోతుందో ధృవీకరించడం.ఇలా మీరు మీ మీద ఆధారపడకుండా బాహ్య ఆడిటర్ ధృవీకరించగల ఆడిట్ ట్రెయిల్ సృజించవచ్చు.
ఈ భాగం ఈ పాఠంలోని అత్యంత ముఖ్యమైనది. రసీదులు శక్తివంతమైనవి కాబట్టి శక్తి పరిమితమైనది.
రసీదులు మూడు విషయాలను సాక్ష్యం ఇస్తాయి:
రసీదులు సాక్ష్యం ఇస్తూ లేవు:
policy_idలో పేర్కొన్న విధానం పరిశీలించబడిందా లేదా అది ఆచరణలో ఉంటే ఈ చర్య అనుమతిస్తుందా అని కాదు. రసీదు క్లెయిమ్ చేసినది మాత్రమే రికార్డ్ చేస్తుంది, అమలు చేసినదే కాదు.ఈ భేదాలు రెండు కారణాలతో ముఖ్యం:
“మన কাছে రసీదులు ఉన్నాయంటే మనం గవర్న్ అవుతున్నాం” అన్నది సాధారణ తప్పు. అదేమిటంటే రసీదులు ఒక పునాది మాత్రమే. గవర్నెన్స్ మేం నిర్మించే వ్యవస్థ.
ఈ పాఠంలోని Python కోడ్ చాలా క్లిష్టతరంగా లేదు, ప్రతి పంక్తిని చదవడం మరియు సంఘటనల్ని అర్థం చేసుకోవడానికి. ఉత్పత్తిలో, రెండు ఎంపికలు:
ప్రత్యక్షంగా క్రిప్టోగ్రాఫిక్ ప్రిమిటివ్స్ పై నిర్మించండి. పై చూపిన 50 పంక్తులు అనేక ఉపయోగాలకు సరిపోతాయి. PyNaCl (Ed25519) మరియు jcs ప్యాకేజీ (కెనానికల్ JSON) పరిశుభ్రంగా నిర్వహింపబడుతున్న ఆయుధాలు.
ఉత్పత్తి రసీదు లైబ్రరీ ఉపయోగించండి. కొన్ని ఓపెన్ సోర్సు ప్రాజెక్టులు అదనపు ఫీచర్లతో ఇదే నమూనాను అమలు చేస్తాయి (కీ రొటేషన్, బ్యాచ్ ధృవీకరణ, JWK సెట్ పంపిణీ, విధాన యంత్రాలతో ఇంటిగ్రేషన్):
draft-farley-acta-signed-receipts) లో ప్రస్తుతం ప్రమాణాల ప్రక్రియలో ఉంది.protect-mcp (npm) మరియు @veritasacta/verify (npm) ప్యాకేజీలు Node ఆధారిత సంతకం మరియు ఆఫ్లైన్ ధృవీకరణ అమలు చేస్తాయి, ఏ MCP సర్వర్ను టాంపర్-ఎవిడెంట్ ఆడిట్ ట్రెయిల్తో ర్యాప్ చేయడానికి.మీరు స్వయంగా JWT లైబ్రరీ వ్రాయడం మరియు ఓ పరీక్షించబడినది ఉపయోగించడం మధ్య నిర్ణయం తీసుకోవటంతో ఇది పోలికగా ఉంటుంది: రెండూ న్యాయమైనవి; లైబ్రరీ సమయాన్ని ఆదా చేస్తుంది మరియు ఆడిట్ పరిమాణాన్ని తగ్గిస్తుంది; స్క్రాచ్ నుండి సృష్టించడం ప్రతి ప్రిమిటివ్ను అర్థం చేసుకోవాలని బాధిస్తుంది. ఈ పాఠం స్క్రాచ్ మార్గం నేర్పుతుంది కాబట్టి మీకు ఇరువైపునూ ప్రాథమిక జ్ఞానం ఉంటుంది.
అభ్యాస వ్యాయామానికి ముందు మీ అర్థం పరీక్షించుకోండి.
1. రసీదు ఏజెంట్ ప్రైవేట్ Ed25519 కీతో సంతకం చేయబడింది. ఆడిటర్ వద్ద కేవలం పబ్లిక్ కీ మాత్రమే ఉంది. ఆడిటర్ ఆఫ్లైన్లో రసీదును ధృవీకరించగలవా?
2. దొంగ రసీదు policy_id ఫీల్డ్ను మరింత అనుమతించే విధానంగా మార్చి క్లెయిమ్ చేశాడు. సంతకం అసలు పేటీపై మాత్రమే ఉంది. ధృవీకరణ సమయంలో ఏమవుతుంది?
3. రసీదులో రా ఆర్గుమెంట్లు మరియు ఫలితానికి బదులు tool_args_hash మరియు result_hash చేర్చడం ఎందుకు?
4. previous_receipt_hash ప్రతి రసీదును ముందున్నదికి లింక్ చేస్తుంది. దొంగ ఒక రసీదును మధ్యలో నిశ్శబ్దంగా తీసేసినట్లయితే ఏది అనుచితమవుతుంది?
5. రసీదు సరిగ్గా ధృవీకరించబడింది. అంటే ఏజెంట్ చర్య సరైనది, శబ్దంగా లేదా విధానానికి అనుగుణంగా ఉందని అర్థమా?
code_samples/18-signed-receipts.ipynb ని తెరిచి నాలుగు విభాగాలు పూర్తిచేయండి:
విస్తృత సవాలు 1: మీరు ఎంచుకునే అదనపు ఫీల్డ్తో రసీదు స్కీంను విస్తరించండి (ఉదాహరణకి ట్రేసింగ్ కోసం రిక్వెస్ట్ ID), సంతకం లాజిక్ను అందులో చేర్చండి, మరియు రసీదు మళ్ళీ ధృవీకరణకు చక్రం తిరుగుతుందో నిర్ధారించండి. తర్వాత సంతకం తర్వాత ఆ ఫీల్డ్ను మార్చి ధృవీకరణ విఫలమయ్యేలా ధృవీకరించండి. ఇది కెనానికల్ ఎంకోడింగ్ ప్రతి బైట్ సంతకం పైన ఎలా ప్రభావం చూపుతుందో అర్థం చేసుకోవడానికి సహాయపడుతుంది. స్ట్రెచ్ ఛాలెంజ్ 2: మీ రెసీట్లు రెండు SHA-256-హ్యాష్ చేయండి (వారి కానానికల్ బైట్స్ను నిర్ణీత క్రమంలో కలపండి) మరియు ఉత్పన్నమైన డైజెస్ట్ను సంతకం చేయడానికి ముందు మూడవ రెసీట్లో కొత్త ఫీల్డ్గా చేర్చండి. అన్ని మూడు రెసీట్లు ఇంకా సరైన రిటర్న్ చేస్తాయో నిర్ధారించండి. మీరు ఒక-దశగా చేర్చిన నిరూపణను కేవలం నిర్మించారు: మూడవ రెసీటును కలిగిన వాడు తొలి రెండు ఉన్నాయి అని నిర్ధారించవచ్చు, సంతకం చేసిన సమయంలో, వాటి కంటెంట్లు వెల్లడించాల్సిన అవసరం లేకుండా. ఇది ఎంపిక-ప్రకటన రెసీట్లు పెద్ద ఎత్తున ఉపయోగించే నమూనా (Merkle కమిట్మెంట్లు, RFC 6962).
క్రిప్టోగ్రాఫిక్ రెసీట్లు AI ఏజెంట్లకు ఆడిట్ ట్రైల్ ఇస్తాయి:
ఇవి ఇన్పుట్ ధృవీకరణ, పాలసీ అమలు, లేదా గుర్తింపు మౌలిక వసతుల స్థానంలో ఉండవు. అవి ఆ లేయర్ల కోసం పునాది. మీరు నియంత్రిత వర్క్లోడ్స్, బహుళ-సంఘ ఆపరేషన్లలో లేదా భవిష్యత్ ఆడిటర్ నమ్మకం ఉంటుందని అనుకోలేని పరిస్థితుల్లో ఏజెంట్లను నిర్వర్తిస్తున్నపుడు, రెసీట్లు ఆడిట్ ట్రైల్ను నిజాయితీగా ఉంచడానికి మార్గం.
ముఖ్యమైన పాఠం: రెసీట్లు ఎవరు ఏమన్నారు, ఎప్పుడు చెప్పారు నిరూపిస్తాయి. వారు చెప్పినది నిజమో సరియో అనేది నిరూపించవు. ఆ తేడాను గట్టిగా పట్టుకోండి. ఇది నిజాయితీగా ఉన్న మూలం వ్యవస్థ మరియు గోప్యంగా మార్చే వ్యవస్థ మధ్య తేడా.
ఈ పాఠం నుండి రెసీట్లు-సంతకం చేసిన ఏజెంట్లను నిజమైన వాతావరణంలో చేయడానికి సిద్ధంగా ఉన్నపుడు:
https://your-org.example.com/.well-known/agent-keys.json.ఇతర అభ్యాసకులతో కలసి మాట్లాడటానికి, కార్యాలయ సమయాల్లో పాల్గొనటానికి మరియు మీ AI ఏజెంట్ల ప్రశ్నలకు సమాధానాలు పొందడానికి Microsoft Foundry Discord లో చేరండి.
ఈ పాఠం ఒక్క రెసీట్లు సంతకం మరియు హ్యాష్-చెయిన్ క్రమాలపై కేంద్రీకరణ. అదే ప్రిమిటివ్స్ మరికొన్ని మునుపటి సాంకేతిక నమూనాల్లో కలిసిపోతాయి:
authorization_*) మరియు పోస్ట్-ఎగ్జిక్యూషన్ (result_*) అర్ధాలుగా విడగొట్టుతుంది స్వతంత్ర సంతకాలతో, ఇది మార్గనిర్ణయం మరియు ఫలితాన్ని వేరు వ్యవహారకులు లేదా వేరు సమయంలో ఉత్పత్తి చేసినపుడు ఉపయోగపడుతుంది. ఇది ఈ పాఠంలో నేర్పిన రెసీట్లు ఫార్మాట్ పై అదనంగా అమలు అవుతుంది.result_hash లో ఉంచిన బైట్లను సీల్ చేస్తుంది. వాస్తవ ప్రపంచ పేప్లోడ్లు సాధారణంగా ఒకే టూల్ కాల్ ఫలితం కన్నా సమృద్ధిగా ఉంటాయి: ముందున జారీ తర్కం (మోడల్ అంచనా, పరిగణించిన ఎంపికలు, సాక్ష్యాలు మరియు అవి పూర్తిగా ఉన్నాయా, ప్రమాద స్థితి, బాధ్యతా గొలుసు, తలంపు ఫలితం) అన్నీ పేప్లోడ్ లో ఉండి ఒకే రెసీటు ద్వారా సీల్ చేసుకోవచ్చు. ఇది రెసీటు ఫార్మాట్ను సూక్ష్మంగా ఉంచుతూనే పేప్లోడ్ స్కీమాలు వేరువేరు డొమైంలను అనుసరిస్తుంటాయి.signature.alg ఫీల్డ్ ML-DSA-65 (NIST పోస్ట్-క్వాంటమ్ సంతకం ప్రమాణం) ను తీసుకువెళుతుంది. రెసీట్లు రెండు సంతకాలు పొందిన కాలం కొనసాగించడానికి ప్రణాళిక చేసుకోండి.కంప్యూటర్ ఉపయోగ ఏజెంట్లు (CUA) నిర్మాణం
(పాఠ్యక్రమ నిర్వహణదారుల ద్వారా నిర్ణయించబడుతుంది)
అస్వీకరణ: ఈ పత్రం AI అనువాద సేవ Co-op Translator ఉపయోగించి అనువదించబడింది. మేము ఖచ్చితత్వానికి ప్రయత్నిస్తున్నప్పటికీ, ఆటోమేటెడ్ అనువాదాలు తప్పులు లేదా అసమగ్రతలను కలిగి ఉండవచ్చు. దాని స్వదేశ భాషలో ఉన్న అసలు పత్రాన్ని అధికారం కలిగిన మూలంగా పరిగణించాలి. కీలకమైన సమాచారం కోసం, ప్రొఫెషనల్ మానవ అనువాదాన్ని సిఫారసు చేస్తాము. ఈ అనువాదం ఉపయోగం వల్ల కలిగే ఏవైనా అపార్థాలు లేదా తప్పుదారులు కోసం మేము బాధ్యత వహించము.