ai-agents-for-beginners

പാഠ വീഡിയോ കാണുക: ക്രിപ്‌ടോഗ്രാഫിക് രസീറ്റുകളിലൂടെ AI ഏജന്റുകള്‍ സുരക്ഷിതമാക്കല്‍

(പാഠ വീഡിയോയും ചെറിയ ചിത്രം മൈക്രോസോഫ്‌റ്റ് ഉള്ളടക്ക സംഘത്തിനു് മേഞ്ഞ് ചേര്‍ക്കുന്നതിന്‌ പാഠം 14 / 15 മാതൃകക്കനുസരിച്ച്.)

ക്രിപ്‌ടോഗ്രാഫിക് രസീറ്റുകളിലൂടെ AI ഏജന്റുകള്‍ സുരക്ഷിതമാക്കൽ

പരിചയം

ഈ പാഠം ഇതു് ഉൾക്കൊള്ളുന്നു:

പഠന ലക്ഷ്യങ്ങള്‍

ഈ പാഠം പൂർത്തിയാക്കിയപ്പോള്‍ നിങ്ങൾ അറിയേണ്ടതൊക്കെ:

പ്രശ്നം: നിങ്ങളുടെ ഏജന്റിന്റെ ഓഡിറ്റ് ട്രെയിൽ

നിങ്ങൾ ഒരു AI ഏജന്റ് Contoso Travel-ന് വേണ്ടി വിന്യസിച്ചിരിക്കുന്നു എന്ന് കരുതി. ഈ ഏജന്റ് ഉപഭോക്താക്കളുടെ അഭ്യർത്ഥനകൾ വായിച്ച്, ഫ്ലൈറ്റുകൾ 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-ൽ ഒരു രസീറ്റ് ഉണ്ടാക്കല്‍

രസീറ്റ് ഉണ്ടാക്കാൻ പ്രത്യേക ലൈബ്രറി ആവശ്യമില്ല. ക്രിപ്‌ടോഗ്രാഫിക് പ്രിമിറ്റീവ് പ്രയോജനപ്രദമായി ലഭ്യമാണ്, ലജിക് പൈതണിലെ കുറച്ചു വരികളാണ്.

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

ഓരോ രസീറ്റ് മുമ്പത്തെ രസീറ്റിന്റെ ഹാഷ് രേഖപ്പെടുത്തുന്നു. 2-ആം രസീറ്റ് നിശബ്ദമായി ഒഴിവാക്കാൻ ഒരു ആക്രമകന്‌ ആവശ്യമുള്ളത്:

സ്വകാര്യ കീ ഹാർഡ്‌വെയർ കീ വാൾറ്റ്-ഇൽ ഉണ്ടെങ്കിൽ, നിങ്ങൾ每 രസീറ്റ് ആവശ്യുള്ള പബ്ലിക്ക് കീ പ്രസിദ്ധീകരിച്ചാൽ, ഈ ആക്രമണങ്ങളിൽ ഒന്നും കണ്ടെത്താതെ സാധ്യമല്ല.

നോട്ട്‌ബുക്ക് പൂർത്തിയാക്കുന്നത്:

  1. മൂന്നു രസീറ്റിന്റെ ശൃംഖല നിർമ്മിക്കുക.
  2. ഓരോ രസീറ്റിന്റെയും previous_receipt_hash മുൻ രസിറ്റിന്റെ ഹാഷിനോടു പൊരുത്തപ്പെടുന്നത് പരിശോധിക്കുക.
  3. ശരിയായ ഇടയിൽ ഒരോ രസീറ്റ് തിരുത്തി, ശൃംഖലം തകരുന്നതു കാണുക.

ഇങ്ങനെ, പുറത്തുള്ള ഒരു ഓഡിറ്റർ നിങ്ങളോട് വിശ്വാസമില്ലാതെ ഓഡിറ്റ് ട്രെയിൽ പരിശോധിക്കാൻ കഴിയും.

രസീറ്റുകൾ എന്ത് തെളിയിക്കുന്നു (എന്നാൽ എന്ത് തെളിയിക്കുന്നില്ല)

ഈ പാഠത്തിലെ ഏറ്റവും പ്രധാന ഭാഗം. രസീറ്റുകൾ ശക്തിയാണ്, പക്ഷേ ആ ശക്തിക്ക് പരിധി ഉണ്ട്.

രസീറ്റുകൾ മൂന്നു കാര്യങ്ങൾ തെളിയിക്കുന്നു:

  1. അറ്റ്രിബ്യൂഷൻ: ഒരു പ്രത്യേക കീ ഒരു പേലോഡ് ഒപ്പിട്ടതാണ്.
  2. സമഗ്രത: ആവർത്തനത്തിനു ശേഷം പേലോഡ് മാറിയിട്ടില്ല.
  3. ഓർഡറിംഗ്: ഈ രസീറ്റ് ആ രസീറ്റിന് ശേഷം ശൃംഖലയിൽ വന്നതാണ്.

രസീറ്റുകൾ തെളിയിക്കുന്നില്ല:

  1. ശരക്കെടുത്ത്: ഏജന്റിന്റെ പ്രവർത്തനം ശരിയാണെന്ന്. ഒരു തെറ്റായ മറുപടിക്ക് പോലും രസീറ്റ് ഒപ്പിടാൻ സാധിക്കും.
  2. നയ പാലനത്തെ: policy_idയിൽ പരാമർശിച്ച നയം യഥാർത്ഥത്തിൽ പരിശോധിച്ചതോ അതു അനുവദിച്ചോ ആണെന്ന് തെളിയിക്കില്ല. രസീറ്റ് പറയുന്നത് അവകാശപ്പെട്ടതാണു്, നിർബന്ധപ്പട്ടത് 아닙니다.
  3. കീയുടെ പുറമെ തിരിച്ചറിയൽ: രസീറ്റ് പറയുന്നു “ഈ കീ ഈ ഉള്ളടക്കം ഒപ്പിട്ടു”. ഇത് പറയുന്നില്ല “ഈ മനുഷ്യൻ അനുമോദിച്ചു”. വ്യക്തിയെ സ്വതന്ത്ര തിരിച്ചറിയൽ സംവിധാനത്തിലൂടെ മാത്രമേ കീയ്ക്ക് ബന്ധിപ്പിക്കാനാവൂ.
  4. ഇൻപുട്ടുകളുടെ വിശ്വാസ്യത: ഏജന്റ് വ്യാജ പ്രോംപ്റ്റ് അവതരിപ്പിച്ച് കൈകാര്യം ചെയ്താലും, രസീറ്റ് പ്രവർത്തനം വിശ്വസനീയമായി രേഖപ്പെടുത്തും. രസീറ്റുകൾ ഇൻപുട്ട് പരിശോധനയ്ക്ക് പകരം അല്ല, അവ ഉപരിതലം മാത്രമാണ്.

ഈ പരിധി രണ്ട് കാരണങ്ങൾക്ക് പ്രധാനമാണ്:

സാധാരണ തെറ്റിദ്ധാരണ: “നമുക്ക് രസീറ്റുകൾ ഉണ്ടെന്നു് അര്‍ത്ഥം നമുക്ക് ഗവേർണൻസ് ഉണ്ട്”. അല്ല. രസീറ്റുകൾ അടിസ്ഥാനമാണ്. ഗവേർണൻസ് തലത്തിലുള്ളിരിക്കുന്ന സംവിധാനമാണ്.

നിർമ്മാണ റഫറൻസുകൾ

ഈ പാഠത്തിലെ പൈതൺ കോഡ് ശ്രദ്ധാപൂർവ്വം കുറഞ്ഞതാണ്, ഓരോ വരിയും പൂർണ്ണമായി മനസ്സിലാക്കാൻ കഴിയുംവിധം. പ്രൊഡക്ഷനിൽ നിങ്ങൾക്ക് രണ്ട് തിരഞ്ഞെടുക്കലുണ്ട്:

  1. ക്രിപ്‌ടോഗ്രാഫിക് പ്രിമിറ്റീവുകളെ നേരിട്ട് ഉപയോഗിക്കുക. മുകളിൽ കാണുന്ന 50 വരികൾ പലവ്യവഹാരത്തിനും മതിയാകും. PyNaCl (Ed25519) ഉം jcs പാക്കേജ് (കാനോണിക്കൽ JSON) ഉം നന്നായി പരിപാലിക്കപ്പെടുന്ന ലൈബ്രറികളാണ്.

  2. ഉത്പാദന രസീറ്റ് ലൈബ്രറി ഉപയോഗിക്കുക. പല ഓപ്പൺ-സോഴ്‌സ് പ്രൊജക്ടുകളും സമാന രീതിയിൽ അധിക സവിശേഷതകളുമായി (കീ റോട്ടേഷൻ, ബാച്ച് പരിശോധന, JWK സെറ്റ് വിതരണം, നയ എഞ്ചിനുകളുമായി സംയോജനം):

    • ഈ പാഠത്തിൽ ഉപയോഗിക്കുന്ന രസീറ്റ് ഫോർമാറ്റ് ഒരു IETF ഇന്റർനെറ്റ്-ഡ്രാഫ്റ്റ് (draft-farley-acta-signed-receipts) ആണ്, നിലവിൽ സ്റ്റാൻഡേർഡുകൾ പ്രക്രിയയിൽ.
    • മൈക്രോസോഫ്റ്റ് ഏജന്റ് ഗവണൻസ് ടൂൾകിറ്റ് സി‍ഡർ ആധാരിത നയം തീരുമാനങ്ങളുമായി രസീറ്റ് വീക്ഷിക്കുന്നു; ആ റിപോസിറ്ററിയിലെ ടUTORIAL 33-ൽ മുഴുവൻ ഉദാഹരണമാണ്.
    • protect-mcp (npm) ഉം @veritasacta/verify (npm) പാക്കേജുകളും രസീറ്റ് ഒപ്പ് സൈൻ ചെയ്യലും ഓഫ്‌‌ലൈൻ പരിശോധനയും നടപ്പിലാക്കിയിട്ടുള്ളവയാണ്, മള്‍ട്ടി-ക്ലയന്റ് MCP സെർവറിനു തട്ടിപ്പ് തെളിവുള്ള ഓഡിറ്റ് ട്രെയിൽ നൽകാൻ ഉപയോഗിക്കപ്പെടുന്നു.

സ്വയം JWT ലൈബ്രറി എഴുതൽ Vs പരീക്ഷിക്കപ്പെട്ട ലൈബ്രറി ഉപയോഗിക്കൽ പോലുള്ള തീരുമാനം ഇത് തന്നെയാണ്: ഇരുവരും സാധുവാണ്; ലൈബ്രറി സമയം സംരക്ഷിക്കുന്നു, ഓഡിറ്റ് പാളി കുറയ്ക്കുന്നു; സ്വയം എഴുതുന്നത് ప్రతి പ്രിമിറ്റീവ് മനസ്സിലാക്കാൻ സഹായിക്കുന്നു. ഈ പാഠം സ്വയം എഴുതൽ വഴികാട്ടിയാണ്.

അറിവ് പരിശോധിക്കൽ

പ്രായോഗിക അഭ്യാസത്തിലേക്കു് പോകുന്നതിനു മുമ്പ് നിങ്ങളുടെ മനസ്സിലാക്കൽ പരീക്ഷിക്കുക.

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: മൈക്രോസോഫ്റ്റ് ഏജന്റ് ഫ്രെയിംവർക്കിൽ നിർമ്മിച്ച ഏജന്റിനു ഈ മാതൃക പ്രയോഗിക്കുക: ടൂൾ കോൾ റിലീസിനൊപ്പിട്ട്, പിന്നീട് രസീറ്റ് സ്വതന്ത്രമായി പരിശോധിക്കുക.

വിപുലീകരണ ചതുര്‍മുഖം 1: രസീറ്റ് സ്കീമയിൽ താങ്കളുടെ ഇഷ്ടാനുസൃതമായ ഒരു ഫീൽഡ് ചേർക്കുക (ഉദാഹരണത്തിന് ട്രേസിംഗിന് റിക്വസ്റ്റ് ഐഡി), അത് അടങ്ങിയിട്ടുള്ള കാനോണിക്കല്‍ ഒപ്പിടൽ ലജിക് നവീകരിച്ച്, രസീറ്റ് ഒപ്പം പരിശോധന നടത്തുമ്പോഴും നിലനിർത്തുന്നുവെന്ന് സ്ഥിരീകരിക്കുക. ഒപ്പിട്ടതിന് ശേഷം ഫീൽഡ് മാറ്റിയാൽ പരിശോധന പരാജയപ്പെടുന്നുവെന്നും കാണിക്കുക. ഇതിലൂടെ കാനോണിക്കൽ എൻകോഡിംഗിലെ ഓരോ ബൈറ്റും ഒപ്പിനായി എങ്ങനെ സംഭാവന ചെയ്യുന്നതെന്നു മനസ്സിലാകും. സ്റ്റ്രെച്ച് ചാലഞ്ച് 2: നിങ്ങളുടെ രണ്ട് റെസിപികളെ SHA-256 ഹാഷ് ചെയ്യുക (അവയുടെ കാനോണിക്കൽ ബൈറ്റുകൾ ഒരു നിർണ്ണായക ക്രമത്തിൽ കണക്കാക്കി ഒന്നിച്ച് ചേര്ക്കുക) പിന്നെ അതിന്റെ ഫലം മൂന്നത്തെ ഒരു റെസിപ്പിയിലെ പുതിയ ഫീൽഡായി ഉൾപ്പെടുത്തുക, അതിന് മുമ്പ് ഒപ്പുവെയ്ക്കുക. മൂന്ന് റെസിപ്പുകളും ഇപ്പോഴും റൗണ്ട്-ട്രീപ്പ് ചെയ്യുന്നതായിട്ടുള്ളതെന്ന് പരിശോധന നടത്തുക. നിങ്ങൾ ഇപ്പോൾ ഒരു ഒന്ന്-പടി ഉൾപ്പെടുത്തൽ തെളിവ് നിർമ്മിച്ചു: മൂന്നത്തെ റെസിപ്പി കൈയ്യിലുളള ആരും ഒപ്പുവെയ്ക്കപ്പെട്ട സമയത്ത് ആദ്യ രണ്ട് റെസിപികളുണ്ടായിരുന്നു എന്ന് അവയുടെ ഉള്ളടക്കം തുറന്നുവെക്കാതിരിക്കുക കൊണ്ട് തെളിയിക്കാം. ഇത് സെലക്ടീവ്-ഡിസ്‌ക്ലോഷർ റെസിപികൾ സ്കെയിൽ ചെയ്യുമ്പോൾ ഉപയോഗിക്കുന്ന മാതൃകയാണ് (Merkle commitments, RFC 6962).

സമാപനം

ക്രിപ്‌ٽو ഗ്രാഫിക് റെസിപികൾ എളുപ്പത്തിൽ അവിടെയുള്ളവയെ പരിശോധിക്കാനാകുന്ന ഒരു ഓഡിറ്റ് ട്രെയിൽ AI ഏജന്റുകൾക്ക് നൽകുന്നു:

വ്യവസ്ഥാപിത ഇൻപുട്ട് പരിശോധന, പോളിസി നടപ്പാക്കൽ അല്ലെങ്കിൽ ഐ덴റിറ്റി സാങ്കേതികതയ്ക്ക് പകരം ഇത് അല്ല; അവയുടെ അടിസ്ഥാന രൂപമാണ്. നിയന്ത്രിത ജോലി ഭാരങ്ങൾ, ബഹുരാഷ്ട്ര workflowകൾ, അല്ലെങ്കിൽ ഒരു ഭാവി ഓഡിറ്ററിന് നിങ്ങൾക്കു വിശ്വാസം ഇല്ലെന്ന് കരുതേണ്ടിടങ്ങളിൽ, റെസിപ്പികൾ ഓഡിറ്റ് ട്രെയിൽ ശരിയായിരിക്കാനുള്ള മാർഗമാണ്.

ഏറ്റവും പ്രധാനപ്പെട്ട takeway: റെസിപ്പികൾ ആരും നീന്തു ചെയ്തത്, എപ്പോഴെന്ന് തെളിയിക്കുന്നു. അവർ പറഞ്ഞതിന്റെ സത്യമോ ശരിയോ എന്ന് തെളിയിക്കുന്നത് അല്ല. ഈ വ്യത്യാസം കൃത്യമായി സൂക്ഷിക്കുക. ഇത് ഒരു ദൈവവിശ്വാസക്കുറഞ്ഞ provenance സംവിധാനത്തിനും തെറ്റിദ്ധരിക്കൽ സിസ്റ്റത്തിനും ഇടയിലുള്ള വ്യത്യാസമാണ്.

ഉത്പാദന ചെക്ക്ലിസ്റ്റ്

ഈ പാഠത്തിൽ നിന്ന് സാക്ഷാൽപാടുള്ള ഏജന്റുകൾ വരുന്ന യാഥാർത്ഥ്യവാതാവിൽ വിനിയോഗിക്കാൻ തയ്യാറായി:

AI ഏജന്റുകൾ സുരക്ഷിതമാക്കുന്നതിനെക്കുറിച്ച് കൂടുതൽ ചോദ്യങ്ങൾ ഉണ്ടോ?

Microsoft Foundry Discord ൽ ചേരുക, മറ്റ് പഠനക്കാരെ കണ്ടുമുട്ടുക, ഓഫിസ് മണിക്കൂറുകളിൽ പങ്കെടുക്കുക, നിങ്ങളുടെ AI ഏജന്റ് ചോദ്യങ്ങൾക്ക് ഉത്തരം നേടുക.

ഈ പാഠത്തിന് പുറത്ത്

ഈ പാഠം ഒറ്റ റെസിപ്പ് ഒപ്പുവെയ്ക്കലും ഹാഷ് ചെയിൻ ചെയ്ത ശ്രേണികളും ഉൾക്കൊള്ളുന്നു. അവ തന്നെ അവതരിപ്പിക്കുന്ന പ്രിമിറ്റീവുകൾ മറ്റും പുരോഗമന മാതൃകകളിലേക്ക് ചേർത്ത് നിങ്ങളുടെ ഗവർണൻസ് നില മെച്ചപ്പെടുത്തുമ്പോൾ കാണാവുന്നവയാണ്:

അധിക വിഭവങ്ങൾ

മുമ്പത്തെ പാഠം

കമ്പ്യൂട്ടർ യൂസ് ഏജന്റുകൾ നിർമ്മിക്കൽ (CUA)

അടുത്ത പാഠം

(പരിപാടി പരിപാലകർ നിർണ്ണയിക്കും)

അറിയിപ്പ്: ഈ രേഖ AI പരിഭാഷാ സേവനം Co-op Translator ഉപയോഗിച്ച് പരിഭാഷപ്പെടുത്തിയതാണ്. ഞങ്ങൾ കൃത്യതയ്ക്കായി ശ്രമിക്കുന്നുവെങ്കിലും, ഓട്ടോമേറ്റഡ് പരിഭാഷകളിൽ പിഴവുകൾ അല്ലെങ്കിൽ തെറ്റായ വിവരങ്ങൾ ഉണ്ടാകാൻ സാധ്യതയുണ്ട്. അതിന്റെ സ്വാഭാവിക ഭാഷയിലുള്ള അസൽ രേഖയാണ് പ്രാമാണികമായ ഉറവിടമായി പരിഗണിക്കേണ്ടത്. നിർണായകമായ വിവരങ്ങൾക്ക്, പ്രൊഫഷണൽ മനുഷ്യ പരിഭാഷ ശുപാർശ ചെയ്യുന്നു. ഈ പരിഭാഷ ഉപയോഗിച്ച് ഉണ്ടാകുന്ന തെറ്റിദ്ധാരണകൾ അല്ലെങ്കിൽ തെറ്റായ വ്യാഖ്യാനങ്ങൾക്കായി ഞങ്ങൾ ഉത്തരവാദികളല്ല.

This site is open source. Improve this page.