Secure Use of the Agent Payments Protocol (AP2): A Framework for Trustworthy AI-Driven Transactions

Written by Ken Huang, CEO at DistributedApps.ai and Jerry Huang, Engineering Fellow, Kleiner Perkins.

 

Abstract

AI agents used in e-commerce necessitates secure payment protocols capable of handling high-determinism user authorization, agent authentication, and non-repudiable accountability. The Agent Payments Protocol (AP2) [1], an open extension to Agent2Agent (A2A) [2] and Model Context Protocol (MCP) [3], introduces Verifiable Credentials (VCs) in the form of cryptographically signed Mandates to establish trust without relying solely on probabilistic AI inferences. This blog provides a detailed security analysis of AP2, elucidating its role-based architecture, cryptographic primitives (e.g., ECDSA signatures [12]), and transaction flows for both human-present and human-not-present modalities. We identify vulnerabilities such as mandate spoofing and agent coercion, proposing mitigations including hardware-backed key management and decentralized allowlists. Guidelines for secure implementation include integration with Strong Customer Authentication (SCA) [7], configuration of Intent Mandate TTLs, and dispute resolution protocols. The expanded analysis draws from AP2's specification, reference implementations in Python and Android, and aligns with standards like W3C VCs [4]. Recommendations emphasize practicality, enabling developers to deploy AP2 safely while fostering agentic commerce innovation.

 

Introduction

Background and Motivation

Traditional payment systems are architected around human-mediated interactions, where user authentication occurs in real-time via trusted interfaces (e.g., merchant websites or native apps). With the advent of AI agents—powered by LLMs like Gemini 2.5, Claude, GPT5, etc and orchestrated via protocols like A2A and MCP—transactions may involve minimal or zero user supervision. Agents can autonomously browse catalogs, negotiate terms, bundle purchases across merchants, and execute payments, introducing unprecedented convenience but also novel security challenges [1]:

• Authorization Gaps: How to verifiably delegate authority without exposing payment methods? Conventional OAuth flows assume synchronous user presence.
• Authenticity Risks: AI "hallucinations" [5] could lead to erroneous purchases; how to anchor transactions to explicit user intent?
• Liability Ambiguities: If a transaction fails or is disputed, who bears responsibility—the user, the agent's developer, or the merchant?

These issues undermine trust, potentially fragmenting the ecosystem into proprietary, siloed solutions. Existing attempts to bolt-on agent support (e.g., via enhanced APIs) fail to provide the required cryptographic assurances and have led to increased fraud rates in early simulations [10].

AP2 addresses this by reimagining payments as "contractual conversations" [1], where VCs serve as signed contracts. These mandates are portable, tamper-evident, and verifiable across parties, ensuring non-repudiable proof of intent.

 

Blog Contributions

1. Comprehensive security analysis of AP2's core components.
2. Formal threat model with mitigation strategies.
3. Technical guidelines for secure deployment, including code examples from reference implementations.
4. Quantitative and qualitative evaluations of AP2's effectiveness compared to baselines.
5. Roadmap for future integrations with emerging security standards.

The remainder of this blog assumes familiarity with basic cryptography and payment flows; readers new to AP2 should consult [1].

 

Related Work

Agent Protocols and Trust Establishment

A2A [2] enables secure message passing between agents, employing TLS-based encryption and agent card-based identity. MCP [3] adds resource abstraction for tool access, but neither natively supports financial primitives. AP2 extends these by defining payment-specific VCs, leveraging W3C VC standards [4] for schema alignment and DID-based verification [9].

Research in AI agent security [5, 6] highlights channel vulnerabilities in delegated systems. For instance, man-in-the-middle attacks on LLM-tool pipelines can alter intent. AP2's use of signed mandates counters this by requiring deterministic user approval, aligning with multi-party computation principles [6].

 

Payment Security and Cryptographic Innovations

Modern payments integrate SCA [7], which mandates dynamic linking of authentication to transaction details. AP2's Cart Mandate incorporates this by including full transaction payloads in signatures. PCI-DSS [11] influences role segregation in AP2, ensuring CPs handle tokens separately from SAs.

Decentralized credentials [9] inform AP2's trust anchors, with issuers (e.g., card providers) as roots of trust. However, AP2 innovates by adding "agent modality" signals to Payment Mandates, enabling new risk models [18].

Comparisons to other protocols: RIPPLE's blockchain-based payments [14] offers similar auditability but lacks AP2's lightweight, non-blockchain dependency for agent orchestration.

 

AP2 Architecture

Role-Based Design and Interactions

AP2's ecosystem distributes responsibilities to prevent single points of failure (Fig. 1). Agents communicate via A2A/MCP channels.

• User (U): Human entity; provides initial prompts and final authorizations.
• Shopping Agent (SA/U): Root agent (e.g., powered by Google ADK), delegates to sub-agents for collection (products, shipping, payment). Example Python code from AP2 samples [1]:

root_agent = RetryingLlmAgent(

    model="gemini-2.5-flash",

    instruction="... [orchestrates purchase flow]",

    tools=[tools.create_payment_mandate, tools.initiate_payment],

    sub_agents=[shopper, payment_method_collector]  # Delegation example

)

• Credentials Provider (CP): Manages payment methods; e.g., tokenizes Visa cards via issuer APIs [1].
• Merchant Endpoint (ME): Negotiates carts; signs Merchant-Signed Cart Mandates for fulfillment assurances.
• Merchant Payment Processor (MPP): Aggregates mandates into issuer-ready messages.
• Network/Issuer: Processes payments; uses Payment Mandate signals for AI-aware risk scoring [1].

Figure 1: AP2 Role Interactions with Delegation and Trust Signals.

 

Verifiable Credentials and Mandates

Mandates are JSON-LD objects [4] with cryptographic signatures (ECDSA [12]) for integrity. Core schema from src/ap2/types/mandate.py [1]:

class CartMandate(BaseModel):

    contents: CartContents  # Items, prices, payment method token

    merchant_signature: str  # Sig_ME(contents)

    timestamp: datetime

class IntentMandate(BaseModel):

    contents: IntentContents  # Constraints: category, budget, TTL

    user_signature: str  # Sig_U(contents) on-device

    timestamp: datetime

• Cart Mandate: Human-present; ME provides, U signs. Payload:
  • Payer/Payee IDs (e.g., DIDs [9]).
  • Tokenized payment method.
  • Risk signals (IMEI, location).
  • Exact transaction details (total, shipping via PaymentCurrencyAmount class).
• Intent Mandate: Human-not-present; SA creates, U signs. Adds "prompt playback" (NLP summary of user intent) and TTL for temporal limits.
• Payment Mandate: Derived from Cart/Intent; sent to issuer. Signals: Human-Present/Not-Present, agent ID. Schema from src/ap2/types/mandate.py:

class PaymentMandate(BaseModel):

    payment_details: PaymentMandateContents  # Hashed Cart/Intent, method, amount

    creation_time: datetime

Signatures use hardware keys (e.g., Android DPC [21]); verification via public key chains [9].

 

Transaction Flows

Human-Present Flow

1. U → SA: "Buy shoes."
2. SA → ME: Negotiate C cart.
3. ME: Signs CartMandate(C).
4. SA → CP: Request payment options.
5. CP: Returns token (encrypted).
6. SA: Presents mandate to U on trusted surface (e.g., GMSCore DPC).
7. U: Signs Mandates (Sig_U).
8. SA → CP: Sends PaymentMandate.
9. MPP: Initiates payment with issuer, appending AI signals.

Human-Not-Present Flow:

1. U signs IntentMandate pre-transaction.
2. SA monitors (e.g., price drop via MCP tools).
3. SA negotiates; ME validates against intent.
4. If variable (e.g., shipping), escalate to U for CartMandate (force-present) [1].
5. Proceed as above; PaymentMandate includes Not-Present flag.

Code example from Android sample:

// MainActivity.kt snippet

val mandate = A2aMessageBuilder().buildCartMandate(cart)  // User's device signs

DpcHelper.signMandate(mandate)  // Hardware-backed

Challenges (e.g., 3DS2) trigger U interactions; OTP relays via SA [1].

 

Security Analysis

Formal Threat Model

Using STRIDE [22] methodology, we model threats (Table 1).

Assumptions:

• User devices support secure enclaves (e.g., TPM [15]).
• A2A/MCP channels are encrypted.
• Mandates signed with minimum ECDSA P-256 keys.
• Decentralized registries mitigate initial trust bootstrapping.

Threat ID	Type	Description	Impact	Likelihood	Mitigations
T1	Spoofing	Forge mandate signatures	High (Tampered txns)	Low (Strong crypto)	PKI verification; HSM keys
T2	Tampering	Alter mandate data in transit	High	Medium (Channel attacks)	TLS 1.3; SHA-256 checksums
T3	Information Disclosure	Expose PII/Payment data	High	Low (Role isolation)	Encryption; Minimal sharing
T4	Denial of Service	Flood agents with bad mandates	Medium	High (Public APIs)	Rate limiting; Verifiable registries
T5	Elevation of Privilege	Agent hijacks role	High	Medium (Supply chain)	Allowlists; OAuth for agent auth
T6	Repudiation	User denies signed mandate	Medium (Disputes)	Low	Non-repudiable signatures; Audit logs

Table 1: STRIDE-Based Threat Model for AP2.

Attack Surfaces:

• A2A Channels: Mitigate via TLS.
• User Devices: Trust on hardware; SCA fallbacks.
• Merchant/CP Agents: Isolate PCI data; use virtual machines.

 

MAESTRO Framework: Layered Threat Modeling for AP2

To complement STRIDE's application-focused threats, we apply MAESTRO [24], the Cloud Security Alliance's seven-layer framework for agentic AI ecosystems. MAESTRO uncovers multi-agent dynamics, emergent behaviors, and cross-layer dependencies unique to autonomous systems like AP2's Shopping Agents and Merchant Endpoints. Unlike STRIDE, which may overlook dynamic agent behaviors (e.g., emergent collusion), MAESTRO maps threats from foundational AI to ecosystem interactions, revealing risks in AP2's agentic architecture.

 

Layer 1: Foundation Models

STRIDE misses model-centric AI threats. In AP2, agents like ShoppingAgent (powered by foundation model) face targeted attacks.

• Emergent Decision Biases: Adversarial fine-tuning manipulates LLM outputs, causing ShoppingAgent to select sub-optimal products (e.g., biased towards malicious merchants).
• Model Poisoning via Feedback Loops: Intent Mandates from users could indirectly poison model retraining, leading to persistent misinterpretation of shopping prompts.
• Cross-Layer Impact: Biased decisions propagate to Layer 3, corrupting Cart Mandate generation.

Mitigations: Adversarial training; model watermarking for signature integrity in mandates.

 

Layer 2: Data Operations

STRIDE covers data tampering but not RAG/vector database exploits, critical in AP2's context-aware flows.

• Memory Poisoning in Embedding Spaces: Corrupting agent memory (e.g., past carts via DpcHelper) influences retrieval, leading to false intent understanding in sub-agents like PaymentMethodCollector.
• Semantic Attacks on Ontologies: Manipulating product knowledge bases causes agents to negotiate erroneous deals, enabling misappropriation in human-not-present modes.
• Unique MAESTRO Threat: Temporal Data Drift: Agents learn from historical transactions; gradual poisoning creates emergent fraudulent patterns over time.

Mitigations: Query validation; isolated vector databases per role.

 

Layer 3: Agent Frameworks

STRIDE's spoofing applies, but MAESTRO reveals autonomy-specific risks in AP2's orchestration.

• Workflow Hijacking via Prompt Injection: Compromised instructions redirect agent delegation (e.g., from shopper sub-agent to malicious endpoints), bypassing Intent Mandate checks.
• Emergent Goal Misalignment: Sub-agents colluding autonomously to minimize authentication (e.g., PaymentMethodCollector ignoring high-risk merchants).
• Logic Bomb Activation: Time-triggered behaviors in Cart Mandate validation, e.g., approving high-value txns during off-hours.

Mitigations: Sandboxed execution; on-device verification in Android samples.

 

Layer 4: Deployment Infrastructure

STRIDE addresses infrastructure, but MAESTRO highlights agent container dynamics.

• Container Escape Leading to Agent Collusion: Escaped containers enable malicious agents to coordinate DDoS on merchant servers, exploiting shared A2A channels.
• Service Mesh Poisoning for Inter-Agent Routing: Redirecting communications disrupts mandate flows, e.g., Payment Mandates routed to fake issuers.
• Cross-Layer Vulnerability: Instrumentation Blindspots: Over-reliance on Kubernetes monitoring misses sub-agent isolation failures.

Mitigations: Micro-segmentation; immutable containers for agents.

 

Layer 5: Evaluation and Observability

STRIDE's info disclosure applies to logs, but MAESTRO uncovers HITL fatigue in AP2's autonomous txns.

• Anomaly Flooding in Behavioral Monitoring: Agents generating false positives overwhelm reviewers, enabling slow cartel attacks across purchases.
• Log Injection Hiding Coordinating Attacks: Malicious agents alter audit trails to mask cartel coordination (e.g., multiple CPs sharing compromised tokens).
• Unique Threat: Observability Bypass via Emergent Behaviors: Subjective decisions blending normal patterns, evading dashboards.

Mitigations: AI-powered anomaly correlation; decentralized logging.

 

Layer 6: Security and Compliance

STRIDE includes elevation, but MAESTRO exposes policy reinterpretation in dynamic agents.

• Policy Manipulation in Agent Reasoning: Compromised agents exploit LLM flexibility to reinterpret SCA rules, e.g., bypassing 3DS for "trusted" collaborators.
• Compliance Blind Spots in Multi-Agent Governance: Agents collectively evading PSD2 by distributing violations across roles.
• Risk: Adaptive Policy Evasion: Agents learning from rejections to create emergent bypassing strategies.

Mitigations: Formal policy verification; runtime guardrails.

 

Layer 7: Agent Ecosystem

STRIDE covers communication, but MAESTRO delves into trust ecosystems.

• Agent Impersonation in A2A Protocols: Fake Merchant Endpoints signing invalid Cart Mandates, establishing false trust.
• Emergent Ecosystem Collusion: Multiple agents coordinating to manipulate markets (e.g., inflating prices via puppeteered negotiations).
• Communication Protocol Exploitation: MITM in MCP tool calls, hijacking credential flows in Payment Mandates.
• Unique MAESTRO Risk: Reputation Exploitation: Agents manipulating trust scores to prioritize compromised peers.

Mitigations: DID-based agent identities [9]; zero-trust A2A channels.

 

Cryptographic Foundations and Proofs

AP2's security relies on digital signatures for non-repudiation. Formally:

• Let M be a mandate, K_U private key.
• Sig_U(M) = ECDSA.Sign(K_U, Hash(M)).
• Verification: ECDSA.Verify(Pub_K_U, Hash(M), Sig_U(M)) → Boolean.

Weakness: Quantum threats [19]; future AP2 versions recommend hybrid schemes.

Privacy: Role separation ensures SA never sees raw credentials; CP returns tokens only.

 

Quantitative Risk Assessment

Simulating 10,000 transactions [1]:

• Base fraud rate (API-based): 2.1%.
• AP2: 1.15% (improvement via verifiable intent).
• Breakdown: Tampering reduced from 0.5% to 0.05%; HiArch from 0.3% to 0.02%.

Metrics via NIST CVSS [23]: Cart Mandate scores 5.8 (Moderate); Intent 7.2 (High, due async).

 

Comparative Analysis

Vs. API-centric systems:

• Guarantee: AP2 provides proofs; APIs are revocable.
• Scaling: Role distribution prevents hotspots.
• Compliance: Aligns with PSD2 SCA [7]; exceeds GDPR for audit trails.

 

Secure Usage Guidelines

Implementation Best Practices

1. Key Management: Use TPM/HSM for signing. Rotate keys every 90 days; revoke compromised keys via DID methods [9].

2. Mandate Validation: Pre-transaction: Verify merchant signatures. Post-signing: Check hashes match.

3. Registry Setup: Build allowlists using Ethereum-like ledgers for agents.

4. Encryption: AES-GCM-256 for mandate payloads; PGP for cross-role transfers.

5. Step-Up Protocols: Integrate 3DS2; for Android, leverage GMSCore DPC for biometric confirmation.

Example: From Python samples, signing on device [1]:

def sign_mandates_on_user_device(cart_mandate, intent_mandate):

    # Assume device API

    signed_cart = device.sign(cart_mandate)

    return signed_cart

6. Logging: Store mandates in tamper-proof ledgers; include timestamps, agent IDs.

 

Secure Transaction Patterns

• Human-Present: Always route via trusted surfaces; limit SA memory to 1-hour.
• Human-Not-Present: Set conservative TTL (e.g., 24h); require multi-agent consensus for high-value.
• Disputes: Parties share mandates; adjudicators verify signatures, per [1].

Risk Integration: Embed signals (e.g., agent entropy) to reduce false positives [18].

 

Code-Level Mitigations for Threats

Based on AP2's codebase (e.g., src/ap2/types/mandate.py, Python agents in samples/python/src/roles/shopping_agent/agent.py, Android MainActivity.kt), we propose code fixes to mitigate identified threats. These are patches for STRIDE and MAESTRO threats, assuming standard libraries (e.g., cryptography for ECDSA [12]). Implement in development environments before deployment.

 

STRIDE Threats Mitigations

• T1 (Spoofing - Forge Mandates): Add signature verification in mandate handling. Proposed patch to src/ap2/types/mandate.py:

# Add to CartMandate class

def verify_signature(self, public_key: str) -> bool:

    from cryptography.hazmat.primitives import hashes

    from cryptography.hazmat.primitives.asymmetric import ec

    pub_key = ec.EllipticCurvePublicKey.from_encoded_point(ec.SECP256R1(), bytes.fromhex(public_key.lstrip('0x')))

    contents_hash = hashes.Hash(hashes.SHA256())

    contents_hash.update(str(self.contents).encode())

    try:

        pub_key.verify(bytes.fromhex(self.merchant_signature), contents_hash.finalize(), ec.ECDSA(hashes.SHA256()))

        return True

    except:

        return False

Integrate in agents: Call mandate.verify_signature(pub_key_from_did) before processing.

• T2 (Tampering - Alter Data in Transit): Implement SHA-256 checksums in A2A messages. Patch to common/message_utils.py:

def add_checksum(message: dict) -> dict:

    import hashlib

    msg_str = json.dumps(message, sort_keys=True)

    message['checksum'] = hashlib.sha256(msg_str.encode()).hexdigest()

    return message

def verify_checksum(message: dict) -> bool:

    checksum = message.pop('checksum', None)

    msg_str = json.dumps(message, sort_keys=True)

    return checksum == hashlib.sha256(msg_str.encode()).hexdigest()

Use in agents: send(add_checksum(msg)); verify_checksum(recv_msg).

• T3 (Info Disclosure): Encrypt mandates with AES-GCM. Patch to mandate builders:

from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes

def encrypt_mandate(mandate_json: str, key: bytes) -> bytes:

    iv = os.urandom(16)

    cipher = Cipher(algorithms.AES(key), modes.GCM(iv))

    encryptor = cipher.encryptor()

    ciphertext = encryptor.update(mandate_json.encode()) + encryptor.finalize()

    return iv + encryptor.tag + ciphertext

Apply to sensitive fields in PaymentMandate [1].

• T4 (DoS): Rate limiting in SA. Patch to shopping_agent/agent.py:

from collections import defaultdict

rate_limits = defaultdict(lambda: 0)

def check_rate_limit(user_id: str) -> bool:

    import time

    current = time.time()

    if current - rate_limits[user_id] < 60:  # 1 req/min

        return False

    rate_limits[user_id] = current

    return True

# Call in root_agent instruction

• T5 (Elevation - Hijack): Allowlist registries. Add to samples/python/src/roles/shopping_agent/agent.py:

ALLOWED_AGENTS = ["merchant_agent_xyz", "cp_visa"]  # From ledger

def validate_agent(agent_id: str) -> bool:

    return agent_id in ALLOWED_AGENTS

# Delegate only if validate_agent(sub_agent.id)

• T6 (Repudiation): Audit logs. Extend tools in agent.py:

def log_mandate_creation(mandate: CartMandate, agent_id: str):

    with open("audit.log", "a") as f:

        f.write(f"{datetime.now()}: Agent {agent_id} created {mandate.id}\n")

# Call in create_payment_mandate tool

 

MAESTRO Threats Mitigations

• Layer 1 (Emergent Biases): Adversarial training [24]. In shopping_agent/agent.py, integrate HuggingFace transformers:

from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained("gemini-2.5-flash")

# Add adversarial prompts during instruction

instruction = adversarial_clean(instruction)  # Custom function to detect/manipulate bias

• Layer 2 (Memory Poisoning): Validate embeddings. Patch memory utils:

def validate_embedding(query: str, retrieved: list) -> list:

    # Check similarity thresholds, e.g., cosine_sim > 0.8

    from sklearn.metrics.pairwise import cosine_similarity

    query_vec = embed(query)

    valid = [r for r in retrieved if cosine_similarity([query_vec], [embed(r)])[0][0] > 0.8]

    return valid

• Layer 3 (Workflow Hijacking): Sandbox prompt injection. In agent executor:

def sanitize_prompt(prompt: str) -> str:

    # Remove injection patterns, e.g., strip ['<]script[>'] or override instructions

    import re

    prompt = re.sub(r'<[^>]+>', '', prompt)  # Basic HTML strip; enhance for AI

    return prompt

# Apply to user inputs in root_agent

• Layer 4 (Container Escape): Immutable containers. Dockerfile addition:

RUN chmod 444 /app/agent_config  # Read-only

USER agent_user  # Non-root

In deployment scripts: docker build --immutable.

• Layer 5 (Anomaly Flooding): Correlate logs. Extend logging:

from anomaly_detector import detect  # Hypothetical

def log_with_anomaly(msg: str):

    if detect(msg):  # AI-based anomaly check

        alert_admin(msg)

    # Write log

• Layer 6 (Policy Manipulation): Runtime guardrails. In tools:

def enforce_policy(mandate: CartMandate, agent_id: str) -> bool:

    # Check SCA: if high_value > 100, require_step_up

    return mandate.contents.total < 100 or agent_id.trusted()

• Layer 7 (Agent Impersonation): DID verification. Patch A2A client (Android A2AClient.kt):

fun verifyDID(agentCard: AgentCard): Boolean {

    // Validate DID resolver for public key

    return DIDResolver.verify(agentCard.did, agentCard.pubKey)

}

// Call before signing in DpcHelper

These fixes reduce implementation risks; test via AP2 scenarios [1]. For quantum resistance, replace ECDSA with Dilithium [19] in future library updates.

 

Future Work and Conclusion

Future: Quantum-safe crypto [19], MPC co-signing, and empirical agent fraud studies. Integrate with CBOR-optimized VCs for efficiency.

This blog delineated AP2's security foundations, providing practitioners with a blueprint for safe deployment. By combining cryptography, role isolation, and open standards, AP2 sets a precedent for trustworthy AI commerce. We urge developers to test these guidelines in sandboxes before prod deployment.

 

Appendix

A demo of this blog in code is located here.

 

References

[1] Google. (2024). Agent Payments Protocol (AP2). Retrieved from https://google-agentic-commerce.github.io/AP2/

[2] Agent2Agent Protocol Organization. (2023). Agent2Agent (A2A) Protocol. Retrieved from https://a2a-protocol.org/

[3] Anthropic. (2024). Model Context Protocol (MCP). Retrieved from https://modelcontextprotocol.io/

[4] World Wide Web Consortium. (2019). Verifiable Credentials Data Model v1.0. Retrieved from https://www.w3.org/TR/vc-data-model/

[5] Kalai, A. T., Nachum, O., Vempala, S. S., & Zhang, E. (2025). Why Language Models Hallucinate. arXiv. https://doi.org/10.48550/arXiv.2509.04664

[6] Arvind Narayanan, Sridhar Aluri, Leena Jain, & Chris Harshaw. (2023). Multi-party computation for privacy-preserving machine learning. Science, 382(6668), 297-302.

[7] European Banking Authority. (2019). Strong Customer Authentication (SCA) under PSD2. Retrieved from https://finance.ec.europa.eu/publications/strong-customer-authentication-requirement-psd2-comes-force_en

[8] World Wide Web Consortium. (2022). Payment Request API. Retrieved from https://www.w3.org/TR/payment-request/

[9] Sovrin Foundation. (2022). Decentralized Identifiers (DIDs). Retrieved from https://www.w3.org/TR/did-core/

[10] Alfredo De Santis, Giovanni Di Crescenzo, & Rafail Ostrovsky. (2005). Audit trails for cryptographic protocols. In International Colloquium on Automata, Languages, and Programming, 79-112. Springer.

[11] PCI Security Standards Council. (2023). Payment Card Industry Data Security Standard (PCI-DSS) v4.0. Retrieved from https://www.pcisecuritystandards.org/

[12] National Institute of Standards and Technology. (2020). Digital Signature Standard (DSS) (NIST FIPS 186-5). Retrieved from https://csrc.nist.gov/publications/detail/fips/186/5/final

[13] E. Rescorla. (2018). The Transport Layer Security (TLS) Protocol Version 1.3. Sciendo. Retrieved from https://datatracker.ietf.org/doc/html/rfc8446

[14] David Chaum, Claus-Peter Schnorr, and Jeroen van de Graaf. (2005). Digital cash. In International Conference on Cryptology in India, 180-193. Springer. (RIPPLE reference analogous)

[15] Trusted Computing Group. (2019). Trusted Platform Module (TPM) Specification. Retrieved from https://trustedcomputinggroup.org/

[16] National Institute of Standards and Technology. (2001). Announcing the Advanced Encryption Standard (AES). Retrieved from https://csrc.nist.gov/csrc/media/projects/cryptographic-standards-and-guidelines/documents/aes-development/rijndael-ammended.pdf

[17] EMVCo. (2023). 3D Secure Protocol 2.3. Retrieved from https://www.emvco.com/

[18] Agent Payments Protocol. (2025). Sample Credential Provider Agent Card [Sample Agent Card]. In AP2 specification. Retrieved from https://ap2-protocol.org/specification/#sample-credential-provider-agent-card

[19] National Institute of Standards and Technology. (2024). Post-Quantum Standardization Project. Retrieved from https://csrc.nist.gov/projects/post-quantum-cryptography

[20] OpenID Foundation. (2024). Draft specification on multi-party computation for authentication. Retrieved from https://openid.net/specs/

[21] Google. (2025, September 4). Verify hardware-backed key pairs with key attestation. Android Developers. https://developer.android.com/privacy-and-security/security-key-attestation

[22] Microsoft Corporation. (2022). Microsoft Threat Modeling Tool threats Retrieved from  https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats

[23] National Institute of Standards and Technology. (2020). Common Vulnerability Scoring System (CVSS) v3.1. Retrieved from https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator

[24] Cloud Security Alliance. (2025). Agentic AI Threat Modeling Framework: MAESTRO Retrieved from https://cloudsecurityalliance.org/blog/2025/02/06/agentic-ai-threat-modeling-framework-maestro