ਪਾਠ ਵੀਡੀਓ ਦੇਖੋ: ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਰਸੀਦਾਂ ਨਾਲ ਏਆਈ ਏਜੈਂਟਾਂ ਦੀ ਸੁਰੱਖਿਆ
(ਪਾਠ ਵੀਡੀਓ ਅਤੇ ਥੰਬਨੇਲ ਨੂੰ ਮਾਈਕ੍ਰੋਸੌਫਟ ਸਮੱਗਰੀ ਟੀਮ ਦੁਆਰਾ ਭੇਜਣ ਤੋਂ ਬਾਅਦ ਜੋੜਿਆ ਜਾਵੇਗਾ, ਜੋ ਪਾਠ 14 / 15 ਦੇ ਪੈਟਰਨ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ।)
ਇਹ ਪਾਠ ਕਵਰ ਕਰੇਗਾ:
ਇਸ ਪਾਠ ਨੂੰ ਪੂਰਾ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਜਾਣੋਗੇ ਕਿ:
ਕਲਪਨਾ ਕਰੋ ਕਿ ਤੁਸੀਂ Contoso Travel ਲਈ ਇੱਕ ਏਆਈ ਏਜੈਂਟ ਤੈਨਾਤ ਕੀਤਾ ਹੈ। ਇਹ ਏਜੈਂਟ ਗ੍ਰਾਹਕਾਂ ਦੀਆਂ ਬੇਨਤੀਆਂ ਪੜ੍ਹਦਾ ਹੈ, ਫਲਾਈਟਸ ਏਪੀਆਈ ਕਾਲ ਕਰਕੇ ਵਿਕਲਪ ਵੇਖਦਾ ਹੈ, ਅਤੇ ਗ੍ਰਾਹਕ ਵਲੋਂ ਸੀਟਾਂ ਬੁੱਕ ਕਰਦਾ ਹੈ। ਪਿਛਲੇ ਤਿਮਾਹੀ ਵਿੱਚ, ਏਜੈਂਟ ਨੇ 50,000 ਬੁੱਕਿੰਗ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀਆਂ।
ਅੱਜ ਇੱਕ ਆਡੀਟਰ ਆਇਆ। ਉਹ ਸਾਦਾ ਸਵਾਲ ਕਰਦਾ ਹੈ: “ਮੈਨੂੰ ਦਿਖਾਓ ਕਿ ਤੁਹਾਡੇ ਏਜੈਂਟ ਨੇ ਕੀ ਕੀਤਾ।”
ਤੁਸੀਂ ਆਪਣੇ ਲੌਗ ਫ਼ਾਈਲਜ਼ ਦੇ ਦਿੰਦੇ ਹੋ। ਆਡੀਟਰ ਉਹਨਾਂ ਨੂੰ ਵੇਖਦਾ ਹੈ ਅਤੇ ਮਸ਼ਕਲ ਸਵਾਲ ਕਰਦਾ ਹੈ: “ਮੈਨੂੰ ਕਿਵੇਂ ਪਤਾ ਕਿ ਇਹ ਲੌਗ ਸੋਧੇ ਨਹੀਂ ਗਏ?”
ਇਹ ਆਡਿਟ-ਟਰੇਲ ਸਮੱਸਿਆ ਹੈ। ਅੱਜਕੱਲ੍ਹ ਜ਼ਿਆਦਾਤਰ ਏਜੈਂਟ ਡਿਪਲੌਏਮੈਂਟਸ ਦੁਆਰਾ ਭਰੋਸਾ ਲਿਆ ਜਾਂਦਾ ਹੈ:
ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸਵਾਲ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦਾ ਬਿਨਾਂ ਕਿਸੇ ਵਿਅਕਤੀ (ਤੁਸੀਂ, ਤੁਹਾਡਾ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ, ਤੁਹਾਡਾ ਡੇਟਾਬੇਜ਼ ਵੇਂਡਰ) ਉੱਤੇ ਭਰੋਸਾ ਕੀਤੇ। ਅੰਦਰੂਨੀ ਉਪਯੋਗ ਲਈ, ਇਹ ਭਰੋਸਾ ਕਬੂਲਯੋਗ ਹੋ ਸਕਦਾ ਹੈ। ਪਰ ਨਿਯੰਤਰਿਤ ਕੰਮਾਂ ਲਈ (ਵਿੱਤ, ਸਿਹਤ ਸੰਭਾਲ, EU ਏਆਈ ਐਕਟ ਅਧੀਨ), ਇਹ ਸਹੀ ਨਹੀਂ।
ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਰਸੀਦਾਂ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਹੱਲ ਕਰਦੀਆਂ ਹਨ ਕਿ ਹਰ ਏਜੈਂਟ ਕਾਰਵਾਈ ਨੂੰ ਸੁਤੰਤਰ ਤੌਰ ‘ਤੇ ਵੈਰਿਫਾਈ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਆਡੀਟਰ ਨੂੰ ਤੁਹਾਡੇ ਉੱਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਉਹਨੂੰ ਸਿਰਫ ਤੁਹਾਡਾ ਪਬਲਿਕ ਕੀ ਅਤੇ ਰਸੀਦ ਦੀ ਲੋੜ ਹੈ।
ਰਸੀਦ ਇੱਕ 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 Canonicalization Scheme (JCS, RFC 8785) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੀਰੀਅਲਾਈਜ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਸ ਨਾਲ ਇਹ ਯਕੀਨੀ ਬਣਦਾ ਹੈ ਕਿ ਦੋ ਵੱਖ-ਵੱਖ ਇੰਪਲੀਮੇਂਟੇਸ਼ਨਾਂ ਦੁਆਰਾ ਉਹੀ ਲੌਜਿਕਲ ਰਸੀਦ ਇੱਕੋ ਜਿਹਾ ਬਾਈਟ ਨਿਕਾਸ ਤੇ ਤਿਆਰ ਹੁੰਦੀ ਹੈ। ਕੈਨੋਨਿਕਲਾਈਜ਼ੇਸ਼ਨ ਬਿਨਾਂ ਵੱਖ-ਵੱਖ ਜੇਐਸਓਐਨ ਸੀਰੀਅਲਾਈਜ਼ਰ ਵੱਖ-ਵੱਖ ਸਕਿਚਰ ਬਣਾਉਂਦੇ।
ਹੈਸ਼-ਚੇਨਿੰਗ। previous_receipt_hash ਖੇਤਰ ਹਰ ਰਸੀਦ ਨੂੰ ਉਸ ਨਾਲ ਪਿਛਲੀ ਰਸੀਦ ਨਾਲ ਜੋੜਦਾ ਹੈ। ਇੱਕ ਰਸੀਦ ਨੂੰ ਹਟਾਉਣ ਜਾਂ ਪੁਨਰ-ਕ੍ਰਮ ਕਰਨ ਨਾਲ ਉਸ ਤੋਂ ਬਾਅਦ ਵਾਲੀਆਂ ਸਬ ਰਸੀਦਾਂ ਟੁੱਟ ਜਾਂਦੀਆਂ ਹਨ। ਛੇੜਛਾੜ ਚੇਨ ਪੱਧਰ ‘ਤੇ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦੀ ਹੈ ਭਾਵੇਂ ਵੱਖ-ਵੱਖ ਦਸਤਖਤਾਂ ਨੂੰ ਬਾਈਪ ਕੀਤਾ ਜਾਵੇ।
ਇਹ ਤਿੰਨ ਗੁਣ ਮਿਲ ਕੇ ਤਿੰਨ ਗਾਰੰਟੀਜ਼ ਦਿੰਦੇ ਹਨ:
ਰਸੀਦ ਤਿਆਰ ਕਰਨ ਲਈ ਤੁਹਾਨੂੰ ਕੋਈ ਵਿਸ਼ੇਸ਼ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਲੋੜ ਨਹੀਂ। ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਪ੍ਰਿਮਿਟਿਵਜ਼ ਵਿਆਪਕ ਤੌਰ ‘ਤੇ ਉਪਲਬਧ ਹਨ ਅਤੇ ਲਾਜਿਕ ਕੁਝ ਦਹਾਈਆਂ ਕਤਾਰਾਂ ਦਾ ਪਾਇਥਨ ਹੈ।
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। ਕੋਈ ਨੈੱਟਵਰਕ ਕਾਲ, ਕੋਈ ਸੇਵਾ ਨਿਰਭਰਤਾ ਨਹੀਂ, ਕੋਈ ਤੀਜੇ ਪੱਖ ਉੱਤੇ ਭਰੋਸਾ ਨਹੀਂ।
ਛੇੜਛਾੜ ਪਤਾ ਲਗਾਉਣ ਲਈ ਨੋਟਬੁੱਕ ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ ਹੈ:
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 ਵਿੱਚ ਦਿੱਤੀ ਨੀਤੀ ਵਾਸਤਵ ਵਿੱਚ ਜਾਂਚੀ ਗਈ ਸੀ ਜਾਂ ਨਹੀਂ, ਜਾਂ ਇਹ ਕਾਰਵਾਈ ਉਸ ਨੀਤੀ ਅਧੀਨ ਪ੍ਰਭਵੀ ਸੀ ਜਾਂ ਨਹੀਂ। ਰਸੀਦ ਦਰਜ ਕਰਦੀ ਹੈ ਕਿ ਕੀ ਦਾਅਵਾ ਕੀਤਾ ਗਿਆ, ਨਾ ਕਿ ਕੀ ਲਾਗੂ ਕੀਤਾ ਗਿਆ।ਇਹ ਸੀਮਾ ਦੋ ਕਾਰਨਾਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ:
ਇੱਕ ਆਮ ਗਲਤੀ ਇਹ ਸੋਚਣਾ ਹੈ ਕਿ “ਸਾਡੇ ਕੋਲ ਰਸੀਦਾਂ ਹਨ” ਮਤਲਬ “ਸਾਡੇ ਕੋਲ ਪਰਬੰਧਨ ਹੈ”। ਇਹ ਗਲਤ ਹੈ। ਰਸੀਦ ਇੱਕ ਬੁਨਿਆਦ ਹਨ। ਪਰਬੰਧਨ ਉਹ ਪ੍ਰਣਾਲੀ ਹੈ ਜੋ ਤੁਸੀਂ ਇਸ ਦੇ ਉੱਪਰ ਬਣਾਉਂਦੇ ਹੋ।
ਇਸ ਪਾਠ ਦੀ ਪਾਇਥਨ ਕੋਡ ਸੰਕੁਚਿਤ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਹਰ ਕਤਾਰ ਨੂੰ ਪੜ੍ਹ ਸਕੋ ਅਤੇ ਬਹੁਤ ਖਾਸ ਤੌਰ ‘ਤੇ ਸਮਝ ਸਕੋ। ਉਤਪਾਦਨ ਵਿੱਚ ਤੁਸੀਂ ਦੋ ਵਿਕਲਪ ਰੱਖਦੇ ਹੋ:
ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਪ੍ਰਿਮਿਟਿਵਜ਼ ‘ਤੇ ਸਿਧਾ ਬਣਾਓ। ਉੱਪਰ ਦਿੱਤੇ 50 ਕਤਾਰਾਂ ਬਹੁਤ ਕਾਰਗਰ ਹਨ। PyNaCl (Ed25519) ਅਤੇ jcs ਪੈਕੇਜ (ਕੈਨੋਨਿਕਲ JSON) ਚੰਗੇ ਸੰਭਾਲੇ ਜਾਂਦੇ ਅਤੇ ਆਡੀਟ ਕੀਤੇ ਗਏ লাইਬ੍ਰੇਰੀਆਂ ਹਨ।
ਉਤਪਾਦਨ ਰਸੀਦ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਕੁਝ ਖੁੱਲੇ ਸ੍ਰੋਤ ਪ੍ਰੋਜੈਕਟ ਇਨ੍ਹਾਂ ਨਾਲ ਹੋਰ ਫੀਚਰਾਂ (ਕੀ ਰੋਟੇਸ਼ਨ, ਬੈਚ ਵੈਰਿਫਿਕੇਸ਼ਨ, JWK ਸੈੱਟ ਵੰਡ, ਨੀਤੀ ਇੰਜਨ ਨਾਲ ਇੰਟਿਗ੍ਰੇਸ਼ਨ) ਦੇਣਗੇ:
draft-farley-acta-signed-receipts) ‘ਚ ਹੈ ਜੋ ਮਿਆਰੀਕਰਨ ਵਿੱਚ ਹੈ।protect-mcp (npm) ਅਤੇ @veritasacta/verify (npm) ਪੈਕੇਜ ਇਕ ਨੋਡ-ਅਧਾਰਿਤ ਰਸੀਦ ਸਾਈਨਿੰਗ ਅਤੇ ਆਫਲਾਈਨ ਵੈਰਿਫਿਕੇਸ਼ਨ ਲਈ ਹਨ ਜੋ ਕਿਸੇ ਵੀ MCP ਸਰਵਰ ਨੂੰ ਛੇੜਛਾੜ-ਪ੍ਰਤੀਰੋਧੀ ਆਡਿਟ ਟਰੇਲ ਨਾਲ ਢੱਕ ਸਕਦੇ ਹਨ।ਆਪਣੇ ਆਪ JWT ਲਾਇਬ੍ਰੇਰੀ ਲਿਖਣ ਅਤੇ ਇਕ ਜਾਂਚੀ ਹੋਈ ਵਰਤੋਂ ਵਿੱਚ ਚੋਣ ਕਰਨ ਦੀ ਤਰ੍ਹਾਂ, ਇਹਨਾਂ ਵਿੱਚ ਭਿੰਨਤਾ ਹੈ: ਦੋਹਾਂ ਵਾਜਬ ਹਨ; ਲਾਇਬ੍ਰੇਰੀ ਸਮਾਂ ਬਚਾਉਂਦੀ ਹੈ ਅਤੇ ਆਡਿਟ ਸਤਹ ਘਟਾਉਂਦੀ ਹੈ; ਆਪਣੇ ਆਪ ਤੋਂ ਲਿਖਣਾ ਤੁਹਾਨੂੰ ਹਰ ਪ੍ਰਿਮਿਟਿਵ ਨੂੰ ਵੀਵਿਧਤ ਕਰਦਾ ਹੈ। ਇਹ ਪਾਠ ਆਪਣੇ ਆਪ ਤੋਂ ਲਿਖਣ ਦੀ ਰਾਹ ਦਿਖਾਉਂਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਦੋਹਾਂ ਲਈ ਬੁਨਿਆਦ ਹੋਵੇ।
ਅਭਿਆਸ ਅਭਿਆਸ ‘ਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੀ ਸਮਝ ਦੀ ਪੜਚੋਲ ਕਰੋ।
1. ਇੱਕ ਰਸੀਦ ਏਜੈਂਟ ਦੀ ਪ੍ਰਾਈਵੇਟ Ed25519 ਕੀ ਨਾਲ ਸਾਈਨ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਆਡੀਟਰ ਕੋਲ ਸਿਰਫ ਪਬਲਿਕ ਕੀ ਹੈ। ਕੀ ਆਡੀਟਰ ਰਸੀਦ ਨੂੰ ਬਿਨਾਂ ਨੈੱਟਵਰਕ ਕਾਲ ਦੇ ਵੈਰਿਫਾਈ ਕਰ ਸਕਦਾ ਹੈ?
2. ਇੱਕ ਹਮਲਾਵਰ ਨੇ ਰਸੀਦ ਦੇ policy_id ਖੇਤਰ ਵਿੱਚ ਸੋਧ ਕਰਕੇ ਇਕ ਹੋਰ ਆਗਿਆਪ੍ਰਦ ਨੀਤੀ ਵਾਲਾ ਦਾਅਵਾ ਕੀਤਾ। ਦਸਤਖਤ ਮੂਲ ਪੇਲੋਡ ਉੱਤੇ ਸੀ। ਵੈਰਿਫਿਕੇਸ਼ਨ ਦੌਰਾਨ ਕੀ ਹੁੰਦਾ ਹੈ?
3. ਰਸੀਦ ਵਿੱਚ ਕੱਚੇ ਤੱਤਾਂ (args) ਅਤੇ ਨਤੀਜੇ ਦੇ ਮੁਕਾਬਲੇ tool_args_hash ਅਤੇ result_hash ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਹਨ ਕਿਉਂ?
4. previous_receipt_hash ਖੇਤਰ ਹਰ ਰਸੀਦ ਨੂੰ ਉਸ ਨਾਲ ਪਿਛਲੀ ਰਸੀਦ ਨਾਲ ਜੋੜਦਾ ਹੈ। ਜੇ ਇੱਕ ਹਮਲਾਵਰ ਚੇਨ ਦੇ ਮੱਧੋਂ ਚੁਪਚਾਪ ਇੱਕ ਰਸੀਦ ਹਟਾ ਦੇਵੇ, ਤਾਂ ਕੀ ਗਲਤ ਹੋ ਜਾਵੇਗਾ?
5. ਇੱਕ ਰਸੀਦ ਸਫਲਤਾਪੂਰਕ ਵੈਰਿਫਾਈ ਹੋ ਗਈ। ਕੀ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਏਜੈਂਟ ਦੀ ਕਾਰਵਾਈ ਸਹੀ ਸੀ, ਧਾਰਮਿਕ ਸੀ, ਜਾਂ ਨੀਤੀ ਦੀ ਪਾਲਣਾ ਕੀਤੀ?
code_samples/18-signed-receipts.ipynb ਖੋਲ੍ਹੋ ਅਤੇ ਸਾਰੇ ਚਾਰ ਭਾਗ ਪੂਰੇ ਕਰੋ:
ਵੱਡਾ ਚੈਲੇਂਜ 1: ਆਪਣੀ ਪਸੰਦ ਦਾ ਹੋਰ ਖੇਤਰ ਜੋੜ ਕੇ ਰਸੀਦ ਸਕੀਮਾ ਨੂੰ ਵਧਾਓ (ਜਿਵੇਂ ਟ੍ਰੇਸਿੰਗ ਲਈ ਰਿਕਵੈਸਟ ID), ਕੈਨੋਨਿਕਲ ਸਾਈਨਿੰਗ ਲਾਜਿਕ ਨੂੰ ਅਪਡੇਟ ਕਰੋ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਰਸੀਦ ਫਿਰ ਵੀ ਵੈਰਿਫਿਕੇਸ਼ਨ ਵਿੱਚ ਬਿਨਾ ਸਮੱਸਿਆ ਸਮਝੋ ਜਾਂਦੀ ਹੈ। ਫਿਰ ਖੇਤਰ ਨੂੰ ਸਾਈਨਿੰਗ ਤੋਂ ਬਾਅਦ ਸੋਧੋ ਅਤੇ ਵੇਖੋ ਕਿ ਵੈਰਿਫਿਕੇਸ਼ਨ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਸਿੱਖਾਉਂਦਾ ਹੈ ਕਿ ਕੈਨੋਨਿਕਲ ਐਨਕੋਡਿੰਗ ਦੇ ਹਰ ਬਾਈਟ ਦਾ ਸਾਈਨਿੰਗ ‘ਚ ਕਿਵੇਂ ਯੋਗਦਾਨ ਹੁੰਦਾ ਹੈ। ਸਟਰੈਚ ਚੈਲੇਂਜ 2: ਆਪਣੀਆਂ ਦੋ ਰਸੀਦਾਂ ਨੂੰ SHA-256 ਹੈਸ਼ ਨਾਲ ਨਾਲ ਜੋੜੋ (ਉਨ੍ਹਾਂ ਦੇ ਪ੍ਰਮਾਣਿਕ ਬਾਈਟਾਂ ਨੂੰ ਇੱਕ ਨਿਰਣਾ ਕਰੋ ਵਾਲੇ ਕ੍ਰਮ ਵਿੱਚ ਜੋੜੋ) ਅਤੇ ਤੀਜੀ ਰਸੀਦ ਉੱਤੇ ਨਵੇਂ ਫੀਲਡ ਵਜੋਂ ਪ੍ਰਾਪਤ ਡਾਈਜੇਸਟ ਨੂੰ ਸੰਘਾਪਿਤ ਕਰੋ, ਫਿਰ ਇਸ ਨੂੰ ਸਾਈਨ ਕਰੋ। ਪੱਕਾ ਕਰੋ ਕਿ ਤਿੰਨੋ ਰਸੀਦਾਂ ਅਜੇ ਵੀ ਦੁਬਾਰਾ ਜਾਂਚ ਯੋਗ ਹਨ। ਤੁਸੀਂ ਸਿਰਫ ਇੱਕ ਕਦਮ ਵਾਲਾ ਸ਼ਾਮਲ ਕਰਨ ਦਾ ਸਾਬਤ ਤਿਆਰ ਕੀਤਾ ਹੈ: ਜੋ ਵੀ ਤੀਜੀ ਰਸੀਦ ਰੱਖਦਾ ਹੈ ਉਹ ਸਾਬਤ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਪਹਿਲੀਆਂ ਦੋ ਮੌਜੂਦ ਸਨ ਜਦ ਉਹ ਦਸਤਖਤ ਕੀਤੀ ਗਈ, ਬਿਨਾਂ ਉਨ੍ਹਾਂ ਦੀ ਸਮੱਗਰੀ ਖੁਲਾਸਾ ਕੀਤੇ। ਇਹ ਉਹ ਨਮੂਨਾ ਹੈ ਜੋ selective-disclosure ਰਸੀਦਾਂ ਵੱਡੇ ਪੱਧਰ ‘ਤੇ ਵਰਤਦੀਆਂ ਹਨ (Merkle commitments, RFC 6962)।
ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਰਸੀਦਾਂ ਏਆਈ ਏਜੰਟਾਂ ਨੂੰ ਇੱਕ ਅਡਿਟ ਟਰੇਲ ਦਿੰਦੀਆਂ ਹਨ ਜੋ:
ਇਹ ਇਨਪੁਟ ਸੱਚਾਈ ਜਾਂ ਨੀਤੀ ਲਾਗੂ ਕਰਨ ਜਾਂ ਪਛਾਣ ਢਾਂਚੇ ਲਈ ਬਦਲ ਨਹੀਂ ਹਨ। ਇਹ ਉਹਨਾਂ ਪਰਤਾਂ ਲਈ ਇੱਕ ਭੂਮਿਕਾ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਨਿਯਮਤ ਵੋਟਰਕੋਡ ਵਿੱਚ ਏਜੰਟ ਤਾਇਨਾਤ ਕਰ ਰਹੇ ਹੋ, ਬਹੁ-ਸੰਗਠਨ ਕਾਰਜ ਪ੍ਰਵਾਹਾਂ ਵਿੱਚ ਜਾਂ ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਵਿੱਚ ਜਿੱਥੇ ਭਵਿੱਖ ਦਾ ਅਡਿਟਰ ਤੁਹਾਡੇ ਉੱਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਰਸੀਦਾਂ ਅਡਿਟ ਟਰੇਲ ਨੂੰ ਇਮਾਨਦਾਰ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਸਭ ਤੋਂ ਜਰੂਰੀ ਗੱਲ: ਰਸੀਦ ਸਾਬਤ ਕਰਦੀਆਂ ਹਨ ਕਿ ਕਿਸ ਨੇ ਕੀ ਕਿਹਾ, ਕਦੋਂ। ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀਆਂ ਕਿ ਜੋ ਕਿਹਾ ਉਹ ਸਚ ਜਾਂ ਸਹੀ ਸੀ। ਇਸ ਫਰਕ ਨੂੰ ਧਿਆਨ ਨਾਲ ਰੱਖੋ। ਇਹ ਇਮਾਨਦਾਰ ਪ੍ਰੋਵੈਨੈਂਸ ਪ੍ਰਣਾਲੀ ਅਤੇ ਗਲਤ ਫਹਿਮੀ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਅੰਤਰ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਇਸ ਪਾਠ ਤੋਂ ਅੱਗੇ ਵੱਧਣ ਲਈ ਤਿਆਰ ਹੋ ਅਤੇ ਰਸੀਦ-ਦਸਤਖਤ ਵਾਲੇ ਏਜੰਟਾਂ ਨੂੰ ਅਸਲੀ ਮਾਹੌਲ ਵਿੱਚ ਤਾਇਨਾਤ ਕਰਨ ਜਾ ਰਹੇ ਹੋ:
https://your-org.example.com/.well-known/agent-keys.json।ਦੂਜੇ ਸਿੱਖਣ ਵਾਲਿਆਂ ਨਾਲ ਮਿਲਣ, ਆਫਿਸ আওਰਜ਼ ਵਿੱਚ ਰਹਿਣ ਅਤੇ ਆਪਣੇ ਏਆਈ ਏਜੰਟ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਲਈ Microsoft Foundry Discord ਵਿੱਚ ਸ਼ਾਮਿਲ ਹੋਵੋ।
ਇਹ ਪਾਠ ਸਿਰਫ ਇੱਕ-ਰਸੀਦ ਸਾਈਨਿੰਗ ਅਤੇ ਹੈਸ਼-ਚੇਨ ਸਿੱਖਰਾਂ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ। ਇਕੋ ਜਿਹੇ ਪ੍ਰਮਿਤਿਵਸ ਹੋਰ ਵਧੇਰੇ ਸੁਧਰੇ ਹਲਾਤਾਂ ਵਿੱਚ ਜੁੜਦੇ ਹਨ ਜਿਹੜੇ ਤੁਹਾਡੇ ਸਰਕਾਰਪਤੀ ਨਜ਼ਰੀਏ ਦੇ ਵਿਕਾਸ ਨਾਲ ਤੁਹਾਨੂੰ ਮਿਲ ਸਕਦੇ ਹਨ:
authorization_*) ਅਤੇ ਪਿਛਲੇ-ਕਾਰਜ (result_*) ਅੱਧੇ ਹਿੱਸੇ ਵਿੱਚ ਵੰਡਦੇ ਹਨ, ਜਿਨ੍ਹਾਂ ਦੀਆਂ ਅਲੱਗ ਅਲੱਗ ਦਸਤਖਤਾਂ ਹੁੰਦੀਆਂ ਹਨ, ਜੋ ਉਸ ਵੇਲੇ ਲਾਭਦਾਇਕ ਹੈ ਜਦੋਂ ਅਧਿਕਾਰ ਨਿਰਣਯ ਅਤੇ ਦੇਖੇ ਗਏ ਨਤੀਜੇ ਵੱਖ ਵੱਖ ਅਦਾਕਾਰਾਂ ਵੱਲੋਂ ਜਾਂ ਵੱਖ ਵੱਖ ਸਮਿਆਂ ‘ਤੇ ਪੈਦਾ ਹੁੰਦੇ ਹਨ। ਇਹ ਪਾਠ ਵਿੱਚ ਸਿੱਖाए ਰਸੀਦ ਫਾਰਮੈਟ ਉੱਤੇ ਵਿਚਾਰ ਦੀ ਕੋਈ ਬਾਧਾ ਨਹੀਂ ਹੈ।result_hash ਵਿੱਚ ਪਾਓ। ਅਸਲ ਵਿੱਚ ਵਾਲੇ ਪੇਲੋਡ ਅਕਸਰ ਇਕ ਸਿੰਗਲ ਟੂਲ ਕਾਲ ਦੇ ਨਤੀਜੇ ਤੋਂ ਜ਼ਿਆਦਾ ਧਨੀ ਹੁੰਦੇ ਹਨ: ਪਹਿਲਾਂ ਦਾ ਨਿਰਣਯ ਤਰਕ (ਮਾਡਲ ਭਵਿੱਖਬਾਣੀ, ਵਿਚਾਰੇ ਗਏ ਵਿਕਲਪ, ਸਬੂਤ ਅਤੇ ਉਸ ਦੀ ਪੂਰਨਤਾ, ਜੋਖਮ ਸਥਿਤੀ, ਜਵਾਬਦੇਹੀ ਚੇਨ, ਗੇਟ ਨਤੀਜਾ) ਸਾਰੇ ਇਸ ਪੇਲੋਡ ਵਿੱਚ ਰਹਿ ਸਕਦੇ ਹਨ, ਜੋ ਇੱਕੋ ਰਸੀਦ ਨਾਲ ਸીલ ਹੁੰਦੇ ਹਨ। ਇਹ ਰਸੀਦ ਫਾਰਮੈਟ ਨੂੰ ਘੱਟ ਰੱਖਦਾ ਹੈ ਜਦਕਿ ਪੇਲੋਡ ਸਕੀਮਾ ਨੂੰ ਖੇਤਰ-ਦਰ-ਖੇਤਰ ਵਿਕਾਸ ਕਰਨ ਦਿੰਦਾ ਹੈ।signature.alg ਫੀਲਡ ਵਿੱਚ ਜਦੋ ਤਬਦੀਲੀ ਕਰਨੀ ਹੋਵੇ, ML-DSA-65 (NIST ਪੋਸਟ-ਕਵਾਂਟਮ ਸਾਇਨਿੰਗ ਮਿਆਰੀ) ਰੱਖ ਸਕਦਾ ਹੈ। ਇਕਾਂਤਾਰੀ ਸਮੇਂ ਲਈ ਯੋਜਨਾ ਬਣਾ ਲਵੋ ਜਦੋਂ ਰਸੀਦਾਂ ਦੋਹਾਂ ਤਰ੍ਹਾਂ ਦੀ ਦਸਤਖਤ ਵਾਲੀਆਂ ਹੋਣ।(ਕਰੀਕੁਲਮ ਸੰਭਾਲਣ ਵਾਲਿਆਂ ਵੱਲੋਂ ਨਿਰਧਾਰਿਤ ਕੀਤਾ ਜਾਵੇਗਾ)
ਅਸਵੀਕਾਰੋਪਣ: ਇਸ ਦਸਤਾਵੇਜ਼ ਦਾ ਅਨੁਵਾਦ ਏਆਈ ਅਨੁਵਾਦ ਸੇਵਾ Co-op Translator ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੀਤਾ ਗਿਆ ਹੈ। ਜਦੋਂ ਕਿ ਅਸੀਂ ਸਹੀਤਾਵਾਂ ਲਈ ਯਤਨਸ਼ੀਲ ਹਾਂ, ਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਰੱਖੋ ਕਿ ਸਵੈਚਾਲਿਤ ਅਨੁਵਾਦਾਂ ਵਿੱਚ ਗਲਤੀਆਂ ਜਾਂ ਅਸਮੱਤਿਆਵਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਮੂਲ ਦਸਤਾਵੇਜ਼ ਆਪਣੀ ਮੂਲ ਭਾਸ਼ਾ ਵਿੱਚ ਅਧਿਕਾਰਕ ਸਰੋਤ ਮੰਨਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਜਰੂਰੀ ਜਾਣਕਾਰੀ ਲਈ, ਪੇਸ਼ੇਵਰ ਮਨੁੱਖੀ ਅਨੁਵਾਦ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਅਸੀਂ ਇਸ ਅਨੁਵਾਦ ਦੇ ਉਪਯੋਗ ਤੋਂ ਪੈਦਾ ਹੋਣ ਵਾਲੀਆਂ ਕਿਸੇ ਵੀ ਗਲਤਫਹਿਮੀਆਂ ਜਾਂ ਗਲਤ ਵਿਆਖਿਆਵਾਂ ਲਈ ਜਵਾਬਦੇਹ ਨਹੀਂ ਹਾਂ।