ai-agents-for-beginners

పాఠం వీడియోను వీక్షించండి: గోప్యరహిత రసీదులతో AI ఏజెంట్లు సురక్షితం చేయడం

(పాఠం వీడియో మరియు థంబ్నెయిల్‌ను మైక్రోసాఫ్ట్ కంటెంట్ టీమ్ మર્જ్ తర్వాత జోడిస్తుంది, పాఠం 14 / 15 నమూనాకు అనుగుణంగా.)

గోప్యరహిత రసీదులతో AI ఏజెంట్లను సురక్షితం చేయడం

పరిచయం

ఈ పాఠం కింద బోధించే అంశాలు:

నేర్చుకునే లక్ష్యాలు

ఈ పాఠం పూర్తయిన తర్వాత, మీరు తెలుసుకుంటారు:

సమస్య: మీ ఏజెంట్ ఆడిట్ ట్రెయిల్

మీరు Contoso ట్రావెల్ కోసం ఒక 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 -- yes --> I[మార్పుల నిర్ధారణ సాక్ష్యం]
    H -- no --> 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..."
  }
}

మూడు లక్షణాలు పని చేస్తున్నారు:

  1. సంతకం. రసీదు ఏజెంట్ గేట్వే ద్వారా Ed25519 ప్రైవేట్ కీ తో సంతకం చేయబడుతుంది. సంబంధిత పబ్లిక్ కీ ఉన్న వాడు ఆ సంతకాన్ని ఆఫ్‌లైన్ లో ధృవీకరించగలడు. ఏ ఫీల్డ్‌లో అయినా మార్పు సంతకాన్ని చెలామణీ చేయదు.

  2. కెనానికల్ ఎంకోడింగ్. సంతకం చేయడానికి ముందు, రసీదును JSON కెనానికలైజేషన్ స్కీమ్ (JCS, RFC 8785) ఉపయోగించి సీరియలైజ్ చేస్తారు. ఇది ఒక మంచి అమలు రెండు సార్లు అదే లాజికల్ రసీదు ఇస్తే బైట్స్ పరంగా ఒకటే అవుతుందని నిర్ధారిస్తుంది. కెనానికలైజేషన్ లేకుంటే, వేర్వేరు JSON సీరియలైజర్ లు ఒకే కంటెంట్ పై వేరు సంతకాలు ఇస్తాయి.

  3. హాష్ చెయినింగ్. previous_receipt_hash ఫీల్డ్ ప్రతి రసీదును తనకు మునుపటి రసీదు కి లింక్ చేస్తుంది. ఒక రసీదును తీసివేయడం లేదా క్రమాన్ని మార్చడం తర్వాతి అన్ని రసీదుల చైన్ ని బద్దలుపరుస్తుంది. వ్యక్తిగత సంతకాలు తప్పించుకున్నా కూడా, మోసం చైన్ స్థాయిలో కనపడుతుంది.

ఈ లక్షణాల ద్వారా তিন రకాల హామీలు వస్తాయి:

Python లో రసీదు తయారు చేయడం

ఒక రసీదు తయారుచేయడానికి ప్రత్యేక లైబ్రరీ అవసరం లేదు. గోప్యరహిత ప్రిమిటివ్స్ (ప్రాథమిక పనులు) విస్తృతంగా అందుబాటులో ఉన్నాయి మరియు లాజిక్ కొద్దిగా 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

# రసీదు పేలలోడ్‌ను సృష్టించండి (ఇప్పటికీ సంతకం లేదు)
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. నెట్‌వర్క్ కాల్ అవసరం లేదు, సేవ ఆధారపడవలసినదేమీ లేదు, గూడ ఆడిటర్ ఏకైక పబ్లిక్ కీ తో ధృవీకరించగలడు.

మోస గుర్తింపు ఆచరణాత్మకంగా చూపించేందుకు, నోట్‌బుక్ ఇలా చేస్తుంది:

  1. చెలామణీ అయ్యే రసీదును తయారుచేయడం మరియు ధృవీకరణ కుదిరితే నిర్ధారించడం.
  2. tool_args_hash ఫీల్డ్ లో ఒక బైట్ మార్చడం.
  3. తిరిగి ధృవీకరణ చేసి అపజయాన్ని చూడటం.

ఇది రసీదులు మోసం బయటపడుతాయన్న ప్రాత्यक्षిక నిరూపణ: చిన్నగా అయినా ఏదైనా మార్పు సంతకాన్ని చెడబరుస్తుంది.

బహుళ దశల ఏజెంట్ల కోసం రసీదులను చెయినింగ్ చేయడం

ఒక్క సంతకం చేసిన రసీదు ఒక చర్యకి రక్షణ ఇస్తుంది. రసీదుల సారి ఒక క్రమం రక్షిస్తుంది.

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

ప్రతి రసీదు తనకు ముందు ఉన్న రసీదు యొక్క హాష్ రికార్డు చేస్తుంది. రెండవ రసీదును మౌనం గా తీసివేయాలంటే, దాడి చెయ్యేవాడు:

ప్రైవేట్ కీ హార్డ్‌వేర్ కీ వాల్ట్ లో ఉంటే మరియు మీరు ప్రతి రసీదుతో పబ్లిక్ కీని ప్రచురిస్తే, ఈ దాడులు లేక గుర్తించకుండా సాధ్యం కాదు.

నోట్‌బుక్ ఇలా చెయ్యడం చూపిస్తుంది:

  1. మూడు రసీదుల చైన్ తయారు చేయడం.
  2. ప్రతి రసీదు యొక్క previous_receipt_hash నిజమైన మునుపటి రసీదు హాష్ తో సరిపోతుందో ధృవీకరించడం.
  3. మధ్యలో ఒక రసీదును మోసపరచి చైన్ విరగడం చూడటం.

ఈ విధంగా మీరు మీపై ఆధారపడకుండా బాహ్య ఆడిటర్ ధృవీకరించగలిగే ఆడిట్ ట్రైల్ తయారు చేస్తారు.

రసీదులు ఏమి నిరూపిస్తాయి (మరియు ఏమి నిరూపించవు)

ఇది ఈ పాఠంలో అత్యంత ముఖ్యమైన విభాగం. రసీదులు శక్తివంతమైనవి కానీ వారి శక్తి పరిమితం.

రసీదులు మూడు విషయాలు నిరూపిస్తాయి:

  1. అట్రిబ్యూషన్: ఒక నిర్దిష్ట కీ ఒక నిర్దిష్ట పేపలోడ్ పై సంతకం చేసింది.
  2. ఇంటిగ్రిటీ: పేపలోడ్ సంతకం నుండి మారలేదు.
  3. క్రమం: ఈ రసీదు ఆ రసీదు తర్వాత చైన్ లో వచ్చింది.

రసీదులు నిరూపించవు:

  1. సరైనత: ఏజెంట్ చర్య సరైనదైతే. తప్పు సమాధానానికి కూడా రసీదు సంతకం చేయవచ్చు.
  2. పాలసీ అనుసరణ: policy_id లో ఉన్న పాలసీ నిజంగా అమలు చేయబడిందా లేదా ఇదే చర్యకు అనుమతిస్తుందా కాదా అన్నది. రసీదు ఏమి కావాలని వాదించిందో మాత్రమే రికార్డ్ చేస్తుంది, ఏమి అమలు చేయబడిందంటే కాదు.
  3. కీకి మించి గుర్తింపు: రసీదు “ఈ కీ ఈ కంటెంట్ సంతకం చేసింది” అని చెబుతుంది. “ఈ మనిషి ఆమోదించారా” అని కాదు. కీని వ్యక్తి లేదా సంస్థతో అనుసంధానం చేయడానికి వేరే గుర్తింపు వ్యవస్థ (డైరెక్టరీ, పబ్లిక్ కీ రిజిస్ట్రి) అవసరం.
  4. ఇన్పుట్ల నిజాయితీ: ఏజెంట్ మోసపూరిత ప్రాంప్ట్ అందుకొని చర్య చేపట్టినప్పటికీ, రసీదు ఆ చర్యను నిజంగా రికార్డు చేస్తుంది. రసీదులు ఇన్పుట్ ధృవీకరణ కన్నా తర్వాత వస్తాయి, ప్రత్యామ్నాయం కాదు.

ఈ సరిహద్దు రెండు కారణాలకి ముఖ్యం:

సాధారణ తప్పు “మాకు రసీదులు ఉన్నాయి” అంటే “మేము పాలించబడుతున్నాం” అనుకోవడం. ఇది కాదు. రసీదులు పునాది. పాలన మీరు నిర్మించేది.

ఒక మనిషి గానూ నిర్ధారించిన చర్యను నిరూపించడం

3వ అంశం ప్రత్యేక విభాగానికి తగినది: ఒక చర్య రసీదు “ఈ కీ ఈ కంటెంట్ సంతకం చేసింది” అని చెబుతుంది, “ఒక మనిషి ఆమోదించింది” అని కాదు. అధిక ప్రమాద చర్యలకు (రిఫండ్‌లు, తొలగింపులు, వైర్ బదిలీలు) పాలనా వ్యవస్థలు ఆ మిస్సింగ్ ప్రకటనను ఎక్కువగా కోరుతున్నాయి, మరియు మీరు ఈ పాఠంలో ఇప్పటికే నిర్మించిన ప్రిమిటివ్స్ తో తయారు చేయవచ్చు.

తదుపరి నోట్‌బుక్ code_samples/human-authorization-receipts.ipynb రెండవ రసీదు రకాన్ని human.approval.v1 జోడిస్తుంది, పాఠంలోని రసీదుల వంటి ఆకారంలో (టైప్ చేసిన పేపలోడ్, Ed25519 సంతకంతో దాని కెనానికల్ SHA-256 పై, signature ఆబ్జెక్ట్ సంతక bytes వెలుపల). ఒక పేరు ఉన్న ఆమోదదారు పూర్తి కెనానికల్ చర్య మరియు దాని డైజెస్ట్‌ను సంతకం చేస్తారు; ఏజెంట్ చర్య రసీదు కూడా అదే చర్య డైజెస్ట్ మరియు parent_approval_ref కలిగి ఉంటుంది, ఆ ఆమోదం యొక్క receipt_hash, మీరు పైగా తయారు చేసిన చైన్ లో previous_receipt_hash పద్ధతి వంటి. ఒక verify_chain ఇరువురు ఆర్టిఫాక్ట్స్ ను వేరే పిన్ చేసిన కీ రిజిస్ట్రిల కింద పరిశీలిస్తుంది (ఆమోదదారి కీలు వర్సెస్ ఏజెంట్ కీలు), కాబట్టి కోడ్ మార్గం భాగస్వామ్యం అయినా, అధికారాలు ఏం పంచుకోవు.

దీని గుణత లక్షణం జాగ్రత్తగా చెప్పబడింది: మనిషి ఈ ఖచ్చిత చర్యను ఆమోదించాడు, ఏజెంట్ అదే ఆమోదిత చర్యను అమలు చేసేది. నోట్‌బుక్ నిరాకరణ ఫిక్సర్లు ఈ గుణతను వాస్తవంగా చేస్తాయి, కేవలం వాదించటం కాదు:

ప్రతి విఫలత యందు వేరు కారణం ఉంటుంది, కాబట్టి ఆడిటర్ నిరాకరణ చదివినప్పుడు అధికారం పాతదైనా, అమలు చేసిన చర్య మారిపోయిందో తెలుసుకోవచ్చు. నోట్‌బుక్ నేర్చిన నియమం: సంతకం చేసిన ఆమోదమే అనధికారికత కాదు. అధికారము ఉంటుందంటే రెండు రసీదులు అమలు సమయంలో అదే కెనానికల్ చర్యతో బంధించబడినప్పుడు మాత్రమే. ఈ పాఠంలో పాటించే ఇంటర్నెట్-డ్రాఫ్ట్ (draft-farley-acta-signed-receipts) లోని కో-సంతకం మార్గం ఈ నమూనా యొక్క ప్రమాణపు మార్గం.

ఉత్పత్తి సూచనలు

ఈ పాఠంలోని Python కోడ్ సంయమనం గలదిగా ఉంటుంది మీకు ప్రతి లైన్ ను చదవడం మరియు ఏమి జరుగుతుందో అర్థం చేసుకోవడానికి. ఉత్పత్తిలో, మీకు రెండు ఎంపికలు ఉంటాయి:

  1. నేరుగా గోప్యరహిత ప్రిమిటివ్స్‌పై నిర్మించండి. మీరు పైగా చూసిన 50 లైన్లు చాలా ఉపయోగాలకి బాగా సరిపోతాయి. PyNaCl (Ed25519) మరియు jcs ప్యాకేజీ (కెనానికల్ JSON) మంచి-పరిచర్య మరియు ఆడిట్ చేసిన లైబ్రరీలు.

  2. ఉత్పత్తి రసీదు లైబ్రరీ ఉపయోగించండి. కొన్ని ఓపెన్-సోర్స్ ప్రాజెక్టులు అదనపు ఫీచర్లతో (కీ రొటేషన్, బ్యాచ్ ధృవీకరణ, JWK సెట్ పంపిణీ, పాలసీ ఇంజిన్‌లతో సమీಕರಣ) ఇదే నమూనా అమలు చేస్తున్నాయి:

    • ఈ పాఠం లో ఉపయోగించిన రసీదు ఫార్మాట్ IETF ఇంటర్నెట్-డ్రాఫ్ట్ (draft-farley-acta-signed-receipts, సంస్కరణ 02) స్టాండర్డుల ప్రక్రియలో ఉంది, మరియు భాగస్వామ్య అనుగుణత సూట్ (agent-governance-testvectors) తో స్వతంత్ర అమలులు బైట్స్ పరంగా సమానమైన అవుట్పుట్ ధృవీకరిస్తాయి.
    • Microsoft Agent Governance Toolkit Cedar ఆధారిత పాలసీ నిర్ణయాలతో రసీదులను సంయుక్తం చేస్తుంది; ఆ రిపోలో ట్యుటోరియల్ 33 లో పూర్తి ఉదాహరణ చూడండి.
    • protect-mcp (npm) మరియు @veritasacta/verify (npm) ప్యాకేజీలు నోడ్-ఆధారిత రసీదు సంతకం మరియు ఆఫ్‌లైన్ ధృవీకరణను అందిస్తాయి, ఎటువంటి MCP సర్వర్ కు టాంపర్-ఎవిడెంట్ ఆడిట్ ట్రైల్లో బిగించడం, అలాగే ఒక ఆపాత చర్య ఆమోద రసీదు జారీ చేసే హోల్డ్-ఫర్-కో-సైన్ ఫ్లో కలిగి ఉంది (డెస్క్‌టాప్ ఫ్లోలో WebAuthn ఆధారిత), ఇది పై మానవ-ఆమోద నోట్‌బుక్ లోని ఆమోద-రసీదు పద్ధతికి లోపలి అనుకరణ.
    • nobulex Python SDK (pip install nobulex) Python లో అదే Ed25519 + JCS సంతక నమూనాను LangChain మరియు CrewAI సమీకరణలతో అందిస్తుంది, ప్రచురిత క్రాస్-వాలిడేషన్ టెస్ట్ వెక్టర్లు మరియు OWASP PR #2210 ద్వారా బీమా మ్యాపింగ్ తో.

మీ సొంత JWT లైబ్రరీను రాయడం లేదా పరీక్షించబడిన JWT లైబ్రరీ ఉపయోగించడం మధ్య ఎంపిక ఇది మాదిరిగానే ఉంటుంది: రెండూ సరైనవి; లైబ్రరీ సేపు ఆదా చేస్తుంది మరియు ఆడిట్ విస్తీర్ణం తగ్గిస్తుంది; సొంతం నిర్మించడం ప్రతి ప్రిమిటివ్ ను అర్థం చేసుకోవడానికి సహాయం చేస్తుంది. ఈ పాఠం సొంతం నిర్మించే మార్గాన్ని నేర్పుతుంది కాబట్టి మీరు రెండు ఎంపికలకు కూడా ఆధారం పొందుతారు.

జ్ఞానం పరీక్ష

ప్రాక్టీస్ వ్యాయామానికి ముందు మీ అర్థం తెలుసుకోండి.

1. రసీదు ఏజెంట్ ప్రైవేట్ Ed25519 కీతో సంతకమవుతుంది. ఆడిటర్ కేవలం పబ్లిక్ కీ కలిగి ఉంటాడు. ఆడిటర్ ఆ రసీదును ఆఫ్‌లైన్ లో ధృవీకరించగలడా?

సమాధానం అవును. Ed25519 ధృవీకరణకు కేవలం పబ్లిక్ కీ మరియు సంతకం చేసిన బైట్లే అవసరం. నెట్‌వర్క్ కాల్ లేదు, సేవ ఆధారపడదు. ఇది రసీదులను ఎయిర్-గ్యాప్, బహుళ సంస్ధల, లేదా తక్కువ నమ్మక ఆడిట్ సెట్టింగుల్లో ఉపయోగించే లక్షణం.

2. దాడి చెయ్యేవాడు ఒక రసీదులోని policy_id ఫీల్డ్ ను మార్చి అది మరింత అనుమతించే పాలసీ కింద ఉందని వాదిస్తాడు. సంతకం అసలు పేప్లోడ్ పై ఉంది. ధృవీకరణ సమయంలో ఏమిటి జరుగుతుంది?

సమాధానం ధృవీకరణ విఫలమవుతోంది. సంతకం అసలు పేలోడ్ యొక్క కానానికల్ బైట్ల పై లెక్కించబడింది; ఏ భేదాన్నైనా మార్పు కానానికల్ బైట్లను మార్చుతుంది, ఇది SHA-256 హాష్‌ను మార్చుతుంది, తద్వారా సంతకం చెల్లనిది అవుతుంది. దాడి చేసే వారు తాజా చెల్లుబాటు అయ్యే సంతకాన్ని ఉత్పత్తి చేయడానికి ప్రైవేట్ కీ అవసరం, అది వారి వద్ద లేదు.

3. రసీదు tool_args_hash మరియు result_hash ని ముడి ఆర్గ్యుమెంట్లు మరియు ఫలితానికి బదులు ఎందుకు కలిగి ఉంది?

సమాధానం రెండు కారణాలు. మొదటి, రసీదును ఆర్కైవ్ చేయాల్సిమొదలగానే లేదా ముడి కంటెంట్ (PII, వ్యాపార డేటా) బయటపడటం సమస్యగా ఉండే పరిసరాల్లో ప్రసారం చేయాల్సి ఉంటుంది. హాషింగ్ రసీదును చిన్నదిగా మరియు కంటెంట్‌ను ప్రైవేట్‌గా ఉంచుతుంది; ఆడిటర్ హాష్ నిజమైన కంటెంట్ యొక్క వేరుగా నిల్వ చేసిన కాపీకి సరిపోతుందో లేదో ధృవీకరిస్తారు. రెండవది, హాష్‌లకు స్థిర పరిమాణం ఉంటుంది; హాష్‌లతో కూడిన రసీదు, ఇన్‌పుట్లు మరియు అవుట్‌పుట్లు ఎంత పెద్దగా ఉన్నా పరిమితి పరిమాణంలో ఉంటుంది.

4. previous_receipt_hash ఫీల్డ్ ప్రతి రసీదును దాని మునుపటి రసీదుతో లింక్ చేస్తుంది. ఒక దాడి చేసే వ్యక్తి శృంఖల మధ్యలో ఒక రసీదును నిశ్శబ్దంగా తీసివేస్తే ఏమి చెల్లనిది అవుతుంది?

సమాధానం తీసివేయబడిన రసీదుకు తర్వత వచ్చిన ప్రతి రసీదు. వారి `previous_receipt_hash` ఫీల్డులు అసలు శృంఖలతో సరిపోలవు (వారు సూచించిన రసీదు ఇక లేదు, లేదా శృంఖల ఇప్పుడు వేరే మునుపటి రసీదుకు చూపుతోంది). తీసివేతను దాచడానికి, దాడి దారుడు ప్రతి తరువాత రసీదును తిరిగి సంతకం చేయాలి, దీనికీ ప్రైవేట్ కీ అవసరం.

5. ఒక రసీదు సాఫీగా వెరిఫై అవుతుంది. అర్థం ఏంటి? ఏజెంట్ చర్య సరైనది, శబ్దమైనది లేదా విధానానుసారమైనది అని అది నిరూపించగలదా?

సమాధానం లేదు. చెల్లుబాటు అయ్యే రసీదు మూడు విషయాలని నిరూపిస్తుంది: కేటాయింపు (ఈ కీ ఈ కంటెంట్‌ను సంతకం చేసింది), సమగ్రమైనత (కంటెంట్ మార్చబడలేదు), మరియు ఆర్డరింగ్ (ఈ రసీదు ఆ రసీదుకి తర్వత వచ్చినది). అది చర్య సరైనది అని, `policy_id` లో పేరుపరచబడిన విధానం నిజంగా మూల్యాంకనం చేయబడిందని, లేదా ఏజెంట్ ప్రతి నియమాన్ని అనుసరించిందని నిరూపించదు. రసీదులు ఏజెంట్ ప్రవర్తనను ఆడిటబుల్‌గా చేస్తాయి, తప్ప తప్పనిసరి గా సరైనది కాదు. ఇది ఈ పాఠంలో అత్యంత ముఖ్యమైన పరిమితి.

ప్రాక్టీస్ వ్యాయామం

code_samples/18-signed-receipts.ipynb ను తెరవండి మరియు నాలుగు విభాగాలలో అందుబాటులో ఉన్నవన్నీ పూర్తి చేయండి:

  1. విభాగం 1: మీ మొదటి రసీదును సంతకం చేసి ధృవీకరించండి.
  2. విభాగం 2: రసీదుతో చట్టవిరుద్ధంగా మార్పులు చేయండి మరియు ధృవీకరణ విఫలమయ్యేట్టు గమనించండి.
  3. విభాగం 3: మూడు రసీదు చైన్లను నిర్మించి చైన్ సమగ్రతను ధృవీకరించండి.
  4. విభాగం 4: Microsoft Agent Framework తో రూపొందించిన ఏజెంట్ పై ఈ నమూనాను వర్తింపజేయండి: టూల్ కాల్‌ను రసీదు-సంతకం చేస్తూ చుట్టండి, తరువాత రసీదును స్వతంత్రంగా ధృవీకరించండి.

అదనపు ఛాలెంజ్ 1: మీరు ఎన్నుకున్న అదనపు ఫీల్డ్ (ఉదాహరణకు, ట్రేసింగ్ కోసం అభ్యర్థన ID) తో రసీదు స్కీమాను విస్తరించండి, కనానికల్ సంతకరణ లాజిక్‌ను అప్డేట్ చేసి దీనిని చేరవేయండి, రసీదు ధృవీకరణ మధ్యలో తిరిగి ప్రయాణిస్తుంది అని నిర్ధారించండి. తరువాత సంతకం చేసిన తర్వాత ఆ ఫీల్డ్‌ని మార్చి ధృవీకరణ విఫలమవుతుందని నిర్ధారించండి. ఈ ప్రక్రియ ద్వారా కనానికల్ ఎన్‌కోడింగ్ లో ప్రతి బైట్ సంతకానికి ఎంత పరిచర్య చేయడమో మీరు అర్థం చేసుకోవాలి.

అదనపు ఛాలెంజ్ 2: మీ రెండు రసీదులను SHA-256 హ్యాష్ చేయండి (వారి కానానికల్ బైట్లను నిర్ణీత క్రమంలో concatenation చేయండి) మరియు వచ్చిన డైజెస్ట్ ను మూడవ రసీదు పై కొత్త ఫీల్డ్ గా సంతకం ముందు ఎంబెడ్ చేయండి. అందరూ మూడు రసీదులు తిరిగి ప్రయాణిస్తాయనే నిర్ధారించండి. మీరు ఇప్పుడే ఒక-దశలో చేర్చుకునే సాక్ష్యాన్ని నిర్మించారు: మూడవ రసీదు కలిగి ఉన్న ఎవరైనా మొదటి రెండు రసీదులు సంతకం అయిన సమయంలో ఉన్నాయని, వారి కంటెంట్ బయటపెట్టకూడదనే నిరూపించగలరు. ఇది ఎంచుకున్న-ప్రకటన రసీదులు పెద్ద స్థాయిలో ఉపయోగించే నమూనా (Merkle కమిట్‌మెంట్లు, RFC 6962).

ముగింపు

క్రిప్టోగ్రాఫిక్ రసీదులు AI ఏజెంట్లకు ఆడిట్ ట్రైల్ ఇస్తాయి, వాటి లక్షణాలు:

అవి ఇన్‌పుట్ ధృవీకరణ, విధాన అమలు, లేదా గుర్తింపు మౌలికసౌకర్యానికి బదులు కాదు. అవి ఆ పొరల కోసం ఒక పునాదిగా ఉంటాయి. మీరు నియంత్రిత వర్క్‌లోడ్స్, బహుళ-సంస్థ వర్క్ఫ్లోలలో లేదా భవిష్యత్తు ఆడిటర్ మీ మీద నమ్మకం పెట్టుకోలేని పరిస్థితుల్లో ఏజెంట్లను desple చేయగా, రసీదులు ఆడిట్ ట్రైల్ నిజాయితీగా ఉండేలా చేస్తాయి.

అత్యంత ముఖ్యమైన విషయం: రసీదులు ఎవరు ఏది చెప్పారు, ఎప్పుడైనో నిరూపిస్తాయి. వారు చెప్పింది సత్యమో సరిగ్గా ఉందో నిరూపించవు. ఆ వ్యత్యాసాన్ని బాగా పట్టుకుని ఉంచండి. ఇది ఒక నిజాయితీ ప్రొవెనెన్స్ సిస్టమ్ మరియు ఒక తప్పుదారి చూపించే సిస్టమ్ మధ్య తేడా.

ఉత్పత్తి చెక్లిస్ట్

మీరు ఈ పాఠం ముగించి రసీదు-సంతకం చేసిన ఏజెంట్లను వాస్తవ వాతావరణంలో desple చేయడానికి సిద్ధమైనప్పుడు:

AI ఏజెంట్ల సెక్యూరిటీ గురించి మరింత ప్రశ్నలు ఉన్నాయా?

మరిన్ని నేర్చుకునేవారితో కలవాలంటే, ఆఫీస్ గంటల్లో హాజరు కావాలంటే, మరియు మీ AI ఏజెంట్ల ప్రశ్నలకు సమాధానం పొందాలంటే Microsoft Foundry Discord లో చేరండి.

ఈ పాఠాన్ని మించి

ఈ పాఠం ఒకే రసీదు సంతకం మరియు హాష్-చైన్డ్ శ్రేణుల గురించి కవర్ చేస్తుంది. అదే ప్రిమిటివ్స్ మీరు మీ పరిపాలనా స్థితి మెరుగుపడటంతో మీరు ఎదుర్కొనే మరిన్ని ఆధునిక నమూనాలలో ఉపయోగపడతాయి:

అదనపు వనరులు

మునుపటి పాఠం

స్థానిక AI ఏజెంట్లు సృష్టించడం

అస్వీకరణ: ఈ పత్రం AI అనువాద సేవ Co-op Translator ఉపయోగించి అనువదించబడింది. మేము ఖచ్చితత్వానికి ప్రయత్నిస్తున్నప్పటికీ, ఆటోమేటెడ్ అనువాదాలు తప్పులు లేదా అసమగ్రతలను కలిగి ఉండవచ్చు. దాని స్వదేశ భాషలో ఉన్న అసలు పత్రాన్ని అధికారం కలిగిన మూలంగా పరిగణించాలి. కీలకమైన సమాచారం కోసం, ప్రొఫెషనల్ మానవ అనువాదాన్ని సిఫారసు చేస్తాము. ఈ అనువాదం ఉపయోగం వల్ల కలిగే ఏవైనా అపార్థాలు లేదా తప్పుదారులు కోసం మేము బాధ్యత వహించము.

This site is open source. Improve this page.