Protocol Interoperability and the Minimal Agent Onboarding Experience

Full report

On this page

Executive Summary

The proliferation of autonomous artificial intelligence systems has precipitated a fundamental architectural shift from human-centered, interface-based applications to an interoperable, agentic web. In this emerging paradigm, the primary friction point is the "N×M integration problem," wherein independent agents must orchestrate external tools, discover counterparties, negotiate economic transactions, and delegate complex tasks across disparate, zero-trust domains without human intervention1. Historically, solving this required bespoke API integrations and static credential provisioning, resulting in fragmented ecosystems and severe platform lock-in. However, the convergence of specialized open standards—specifically the Model Context Protocol (MCP), the Agent-to-Agent (A2A) protocol, RFC 8693 token exchange, SPIFFE workload identity, and the x402 payment protocol—enables a unified, permissionless interaction layer. The objective of this comprehensive analysis is to define the absolute minimal onboarding experience that permits an independently operated agent to become discoverable, custody credentials securely, accept a delegated task, execute a computational payload, and submit verified evidence without adopting a proprietary cloud runtime. By deconstructing the overlapping, yet distinct, responsibilities of discovery, messaging, tool execution, identity governance, and economic contracting, this report proposes a standardized, agnostic integration surface. This surface prioritizes portability and security, ensuring that agents operating in constrained hosting environments, enduring intermittent network states, or utilizing common scripting wrappers can participate natively in the global multi-agent economy.

Architectural Paradigms: Contrasting Current Approaches

The ecosystem of agent communication currently features multiple standards, each optimized for distinct interaction shapes and computational lifecycles. A rigorous distinction must be made between tool-connection protocols, agent-to-agent delegation frameworks, and conventional API description formats. Assuming a single protocol supplies all requisite functionality leads to structural vulnerabilities and architectural misalignment.

Agent-to-Agent Integration: A2A vs. The Agent Protocol

When examining peer-to-peer agent delegation, two primary open-source specifications emerge with contrasting philosophies: the AI Engineer Foundation's Agent Protocol and Google's Agent-to-Agent (A2A) protocol. The AI Engineer Foundation's Agent Protocol is designed as a lightweight, framework-agnostic REST API specification3. It defines a predefined series of endpoints and response models that an agent should expose, effectively standardizing a traditional HTTP CRUD (Create, Read, Update, Delete) interface for interacting with an agent's task list3. While highly accessible for basic scripting environments, its reliance on strict REST semantics limits its capacity to handle complex, continuous, or bidirectional negotiations between autonomous entities. Conversely, Google's Agent-to-Agent (A2A) protocol is explicitly designed for multi-agent delegation, interoperability, and long-running collaborations6. Where traditional protocols force synchronous waiting, A2A standardizes asynchronous task assignment through a robust state machine encompassing states such as Submitted, Working, Input-required, Completed, and Failed9. A2A communication occurs over HTTP/HTTPS using JSON-RPC 2.0 as the data exchange format, with native support for Server-Sent Events (SSE) to facilitate real-time streaming updates for background responses9. The inclusion of the input-required state uniquely positions A2A to handle human-in-the-loop (HITL) scenarios and multi-step reasoning breakdowns, allowing an agent to pause execution and request clarification without dropping the session state12.

Tool Execution and Context: The Model Context Protocol (MCP)

While A2A dictates how agents delegate work to one another, the Model Context Protocol (MCP), advanced by Anthropic, standardizes the bilateral communication required for Large Language Models (LLMs) to access external data sources and execute deterministic tools13. Operating on a strictly client-server model over JSON-RPC 2.0, MCP separates the orchestration logic (the host application) from the capability provision (the server)15. As of the major specification update in July 2026 (version 2026-07-28), MCP evolved into a strictly stateless protocol, eliminating persistent sessions and the initial handshake requirements that complicated intermittent connectivity16. Every request must now carry its protocol version and negotiated capabilities within a per-request metadata field16. Furthermore, legacy features such as sampling were deprecated in favor of more streamlined execution primitives16. MCP excels in synchronous, deterministic context retrieval. The MCP server exposes specific resources, reusable prompts, and executable tools, while the host process acts as an orchestrator, aggregating this context to prevent data leakage between distinct client sessions15. However, MCP was not fundamentally designed for peer-to-peer agent delegation, decentralized discovery, or native task state machines; it leaves workflow orchestration entirely to the host application, making it a critical component for tool execution but insufficient for full agentic onboarding17.

API Description: OpenAPI vs. AsyncAPI

Underpinning all messaging protocols are foundational API description formats that serve as structural contracts. OpenAPI Specification (OAS) 3.2 remains the standard for describing synchronous, HTTP-oriented interfaces19. For AI agents, an OpenAPI schema acts as a machine-readable interface contract, informing the agent of required fields, valid data types, endpoint constraints, and expected response shapes without human intervention20. This allows agents to reliably parse outputs and construct valid requests. However, traditional synchronous APIs struggle with the asynchronous, non-deterministic nature of long-running AI workloads. AsyncAPI 3.1 addresses this by modeling message-driven interfaces, providing a definitive schema authority for events, webhooks, and pub/sub architecture19. The optimal client-integration approach for independent agents often requires a hybrid model utilizing what is termed a "causal contract trace"19. In this model, OpenAPI commands are utilized to validate intent and return a durable task identifier (e.g., an HTTP 202 Accepted response), while AsyncAPI status messages carry that identity forward, delivering updates until the task reaches a terminal state19.

The Protocol-Responsibility Matrix

A resilient, provider-independent architecture requires assembling a stack of specialized standards, avoiding the monolithic assumption that one protocol supplies all requisite responsibilities. The following matrix delineates the strict division of responsibilities necessary for a production-grade multi-agent exchange.

Establishing Sovereign Identity and Multi-Hop Delegation

The transition from human-driven applications to agentic systems exposes critical vulnerabilities in conventional authentication frameworks. An independently operated agent requires a mechanism to establish its own runtime identity, cryptographically prove its authority to act on behalf of a human user across multiple trust domains, and ensure its actions are meticulously audited.

Workload Identity via SPIFFE and SPIRE

In a decentralized multi-agent ecosystem, reliance on static API keys, long-lived secrets, or pre-shared credentials introduces unacceptable risks of theft and unauthorized replay. The Secure Production Identity Framework for Everyone (SPIFFE) and its CNCF-graduated reference implementation, SPIRE, eliminate this reliance by providing verifiable, cryptographic workload identities bound directly to the executing process24. The process operates without secrets. When an agent process initiates, it contacts a local SPIFFE Workload API via a UNIX domain socket. The node agent performs attestation—verifying the process based on kernel-level attributes, executable hashes, namespaces, or platform-specific data like AWS Instance Identity Documents—and subsequently issues a SPIFFE Verifiable Identity Document (SVID), typically a short-lived X.509 certificate with a one-hour time-to-live25. This SVID enables mutual TLS (mTLS) between agents. Consequently, the agent never stores a secret; its identity is inextricably bound to its real-time runtime presence24. Furthermore, this architecture natively supports cross-organizational federation. By exchanging public trust bundles, an agent operating in an enterprise environment can securely verify the identity of a vendor's agent in a completely separate trust domain, an essential prerequisite for open-internet A2A communication25.

Overcoming Impersonation via RFC 8693 Token Exchange

While SPIFFE provides robust transport-layer security by proving what software process is calling, it leaves significant operational gaps at the application layer. SPIFFE does not define access policy enforcement, continuous posture management, or user delegation context24. Allowing an agent to simply inherit and present a human user's standard OAuth access token results in an anti-pattern known as "impersonation." Under impersonation, the resource server cannot distinguish the autonomous agent's actions from the human's manual actions, effectively destroying the security audit trail and violating the principle of least privilege27. The standardized architectural solution to this problem is the implementation of RFC 8693, OAuth 2.0 Token Exchange39. Under this specification, an agent acting on behalf of a user executes a specific delegation exchange. The agent presents the user's original token (the subject\_token) alongside its own identity token (the actor\_token) to a Security Token Service (STS)28. The STS validates both tokens and issues a composite JWT. Crucially, this new token contains a sub claim identifying the original human user, and a nested act claim identifying the executing agent28. As agents delegate complex tasks to other sub-agents (e.g., an orchestrator agent passing a sub-task to a specialized database query agent), these act claims can be chronologically nested. This mechanism preserves a tamper-evident, multi-hop record of the entire delegation path28. This dual-identity approach ensures strict accountability, allowing downstream resource servers and policy engines to enforce permission intersections, effectively restricting the autonomous agent to only those scopes explicitly authorized for the exact parameters of the delegated task26.

Permissionless Economics and Cross-Layer Settlement

For an independently operated agent to complete a useful job in the open web, it must frequently consume paid resources—such as specialized LLM inference, proprietary datasets, or external execution compute. Traditional payment rails that require credit cards, human identity verification, and interactive checkout interfaces present insurmountable friction for autonomous, machine-to-machine commerce31.

The x402 Protocol (Version 2)

The x402 protocol resolves this friction by activating the long-dormant HTTP 402 "Payment Required" status code, transforming it into a machine-readable, internet-native payment rail30. Facilitated by an open foundation, the protocol operates deterministically within the HTTP layer, rendering it agnostic to the underlying communication payloads (such as A2A JSON-RPC or MCP tool calls)18. The x402 payment flow relies on a three-party architecture: the client (the agent), the resource server, and an optional off-chain facilitator that handles verification and on-chain blockchain settlement without taking custody of funds30. As standardized in the v2 specification (released in December 2025), the negotiation utilizes three specific Base64-encoded JSON HTTP headers to complete the transaction inline.

This design implies the agent never needs to hold native gas tokens or manage complex blockchain interactions. The agent signs a stablecoin-specific authorization against a domain; the facilitator pays the fractional network gas and settles the payment, allowing the agent to purchase capabilities dynamically at runtime without pre-provisioned API keys31.

Failure Modes, Racing Settlement, and Idempotency

While x402 enables seamless micro-transactions, it introduces a severe cross-layer attack surface because it attempts to combine synchronous HTTP authorization with asynchronous blockchain settlement45. A formal security analysis reveals a critical failure mode: the gap between "verification appears valid" and "on-chain settlement is finalized" can be exploited45. If a server grants the requested resource before the payment reaches a firm confirmation threshold, an attacker can extract the embedded authorization from the PAYMENT-SIGNATURE header and race the settlement on-chain from a different account. When the honest facilitator attempts to submit the settlement, the nonce is already consumed, causing the honest settlement to fail despite the resource having already been delivered via the HTTP layer45. Similarly, network volatility can cause a double-grant problem. If a client sends an x402 payment, the server settles it, but the client drops the HTTP response and retries the request with the identical payment header, a naive server might treat every arrival as a fresh authorization, granting the resource multiple times for a single payment45. To safely implement economic contracts, agents must utilize Idempotency Keys20. By deterministically mapping the unique payment signature to a UUID within the JSON-RPC payload, the server creates a deduplication record. If an identical payment authorization arrives due to a lost response, the server bypasses the blockchain settlement completely, intercepts the application logic, and returns the cached execution result, ensuring mathematically sound recovery from dropped connections20.

Execution Isolation at the Edge: The Wasm Continuum

Once an agent discovers a capability, negotiates access, and pays for the resource, it must frequently execute computational logic, parse foreign artifacts, or evaluate retrieved context. Executing AI-generated code, evaluating hallucinated tool calls, or processing untrusted third-party data introduces an enormous attack surface32. A poisoned MCP tool or a prompt injection could easily pivot from the agent process to execute arbitrary commands, leading to total infrastructure compromise32.

The Deficiencies of Containers and MicroVMs

Historically, the default approach to sandboxing untrusted code was containerization (e.g., Docker). However, containers isolate the view, not the kernel; all containers share the identical Linux kernel on the host OS35. Numerous CVEs have demonstrated that container escapes to the host are a fundamental, unavoidable risk in multi-tenant or highly targeted environments32. Hardware-virtualized MicroVMs, such as Firecracker, provide excellent strict isolation by providing discrete kernels. However, they suffer from significant performance degradation. Standard MicroVMs introduce cold-start latencies of up to 150 milliseconds and require roughly 256MB of memory per instance32. While advanced engineering techniques like ZeroBoot utilize Copy-on-Write KVM memory snapshot forks to drastically reduce these start times, such approaches remain highly dependent on specific bare-metal Linux infrastructure and lack cross-platform portability35. For an independently operated agent running in a constrained environment or requiring rapid, real-time conversational responses, heavy virtualization is disqualifying.

WebAssembly (Wasm) and Capability-Based Security

The optimal execution sandbox for autonomous agent onboarding is WebAssembly (Wasm). Wasm runtimes execute compiled modules within a linear memory space—a contiguous block of bytes completely isolated from the host process32. This provides absolute mathematical memory safety; the Wasm module has no physical capacity to access host memory, and the call stack is managed entirely by the runtime, neutralizing traditional stack-smashing exploitation34. Furthermore, Wasm utilizes the Component Model and Wasm Interface Types (WIT) to enforce capability-based security. A compiled Wasm module is entirely inert by default, possessing zero intrinsic ability to access the filesystem, read environment variables, or establish network connections34. For an agent to execute a tool, the host environment must explicitly inject targeted capabilities (known as imports) during instantiation32. Because cold starts routinely execute in under 5 milliseconds with base memory footprints as low as 15MB, an agent can spin up a dedicated Wasm sandbox for a single atomic tool call, process the data securely, and immediately destroy the environment33. This deterministic teardown ensures no residual state or cross-contamination occurs between tasks.

Selecting the Execution Engine

Developers integrating Wasm sandboxing must select an execution engine appropriate to their specific deployment topology.

The Minimal Integration Surface

To achieve total provider independence, broad portability, and resistance to vendor lock-in, the integration surface must strictly avoid proprietary agent SDKs, cloud orchestration dependencies, and centralized discovery registries. The absolute minimal surface necessary for an independently operated agent to participate fully in the open ecosystem consists of exactly three standardized web primitives:

1. The Discovery Endpoint (Static): A standard web server hosting /.well-known/agent.json. This Agent Card declares the agent's human-readable metadata, the URLs to its OpenAPI and AsyncAPI schemas, its JSON-RPC endpoints, and its accepted authentication schemes (e.g., OAuth2 for RFC 8693\)7.

2. The Communication Interface (Dynamic): A unified HTTP/HTTPS endpoint capable of parsing both standard REST commands (for immediate synchronous polling) and A2A JSON-RPC 2.0 messages (for asynchronous, stateful task delegation and SSE streaming)9. This interface must be wrapped by the x402 middleware to automatically intercept billable task requests and issue 402 HTTP challenges30.

3. The Execution Host (Local): An open-source WebAssembly runtime (such as Wasmtime or WasmEdge) directly embedded within the agent's process logic. This guarantees that any retrieved tools, capability schemas, or generated code are executed locally in a strictly governed, memory-safe sandbox without requiring external cloud execution APIs32.

By adhering strictly to this minimal surface area, the agent acts as a fully sovereign node. It requires only standard internet routing, maintaining decoupling from closed-source marketplaces or proprietary execution networks.

The Onboarding Sequence: A Lifecycle Narrative

The operational journey of an independently operated agent—from initial instantiation to the successful completion and cleanup of its first verified job—must be resilient to numerous edge cases. This includes enduring intermittent network connectivity, managing constrained computing resources, and recovering gracefully from unverified network state changes. The end-to-end sequence proceeds as follows:

1. Capability Publication and Credential Custody

Upon initialization, the agent process boots and immediately initiates a local connection to the host node's SPIFFE Workload API. Through kernel-level attestation, the node issues the agent a short-lived X.509 SVID, establishing its zero-trust cryptographic identity without loading static secrets25. Simultaneously, the agent exposes its agent.json card to the internet. For agents operating on constrained devices (such as embedded edge gateways) or facing intermittent connectivity, the agent registers a dedicated webhook address or pub/sub topic via an AsyncAPI schema within its Agent Card. This allows external counterparties to push tasks into a queue, enabling the agent to retrieve them only when an active connection is established19.

2. Work Discovery and Negotiation

A client orchestrator agent discovers the newly onboarded worker utilizing standard A2A discovery strategies, fetching the agent.json via a well-known URI or an enterprise catalog7. The client analyzes the worker's schemas, recognizes a required capability (e.g., complex data normalization), and initiates a request via the A2A tasks/send JSON-RPC method, attaching a cryptographically secure UUID as an Idempotency Key8. Because the worker agent requires compensation for its compute, its x402 middleware intercepts the incoming request, halting processing and responding immediately with an HTTP 402 status containing the PAYMENT-REQUIRED Base64 JSON header detailing accepted stablecoins and pricing18.

3. Identity Exchange and Task Acceptance

Upon receiving the 402 challenge, the client agent's wallet generates a gasless EIP-3009 transfer authorization, creating the PAYMENT-SIGNATURE31. Concurrently, to satisfy strict enterprise authorization requirements, the client agent performs an RFC 8693 token exchange with a trusted Identity Provider. It combines the human user's subject\_token with its own actor\_token, producing a composite JWT that explicitly records the delegation path28. The client retries the tasks/send request, presenting both the payment signature and the composite JWT. The worker agent cryptographically verifies the JWT, confirming the delegation chain and evaluating the permission intersection29. It simultaneously allows the x402 facilitator to verify and settle the payment transaction on-chain31. Once both identity and economics are satisfied, the worker returns an A2A task state of Submitted alongside a PAYMENT-RESPONSE header9.

4. Execution and Evidence Submission

The worker agent transitions the internal task state to Working9. To process the data safely, the worker dynamically instantiates a local Wasm sandbox, utilizing WIT to grant strictly scoped, read-only access to a specific directory containing the target data32. The execution completes securely without exposing the host OS. The worker packages the normalized data outputs into structured A2A Artifacts, appends them to the JSON-RPC payload, updates the task state to Completed, and transmits the evidence back to the client9. If the processing requires significant time, the worker streams intermediate updates back to the client via SSE11.

5. Idempotent Recovery from a Lost Response

If the client agent suffers a transient network drop precisely after submitting the payment, a critical failure mode occurs: the server has accepted the work and charged the fee, but the client failed to parse the response45. To recover seamlessly, the client reconnects and resubmits the exact tasks/send payload, including the identical Idempotency Key and PAYMENT-SIGNATURE20. The worker agent's deduplication logic recognizes the key, intercepts the processing pipeline, and immediately returns the cached Completed state and evidence artifacts. Crucially, the x402 middleware bypasses the 402 challenge and ignores the duplicate payment signature, preventing the "double-grant" failure condition and ensuring the client is not double-billed20. If the client is a long-running background agent, it utilizes standard A2A polling (tasks/get) using the stored task ID to seamlessly reconnect to interrupted streams and recover the state8.

6. Teardown and Cleanup

Following the successful transmission and acknowledgment of the terminal task state, the worker agent executes a deterministic teardown. It destroys the Wasm instance; because Wasm utilizes isolated linear memory allocation, simply dropping the module instantly reclaims all memory without requiring complex garbage collection or risking artifact leakage34. The SPIFFE SVID naturally expires at the end of its short TTL, and the ephemeral token exchange JWT is discarded from memory, leaving the agent in a pristine, zero-trust resting state awaiting the next task25.

Non-Production Onboarding Sandbox Design

To ensure an independently operated agent adheres to these strict protocols prior to live internet deployment, developers require a comprehensive, local, non-production onboarding sandbox. This sandbox must simulate counterparty agents, identity providers, and payment facilitators without requiring live internet access, complex Kubernetes clusters, or real financial capital. Designed as a standalone, lightweight daemon (deployable via single binaries written in Go or Rust), the sandbox operates easily within common scripting environments and consists of four simulated sub-services:

1. Mock SPIRE Server: Bypasses complex node-level hardware attestation by automatically issuing locally trusted, dummy X.509 SVIDs to any process connecting to its simulated UNIX socket. This verifies the agent's ability to fetch and utilize mTLS certificates dynamically38.

2. Mock STS (Security Token Service): Simulates an RFC 8693 Identity Provider. It accepts dummy subject\_tokens, requires the agent to authenticate via its newly acquired SVID, and returns predictably signed composite JWTs with nested act claims. This validates the agent's logic for handling multi-hop delegation chains28.

3. Local x402 Facilitator: An HTTP middleware wrapper that intercepts requests, issues synthetic 402 responses, and validates EIP-3009 cryptographic signatures against test keypairs without attempting to broadcast transactions to a live blockchain31.

4. A2A Client Harness: A scripted orchestrator that fetches the agent's agent.json, negotiates capability interfaces, and submits randomized, malformed, and valid JSON-RPC tasks to rigorously test the agent's state machine transitions8.

During validation, the harness submits a malicious payload designed to escape the sandbox (e.g., attempting to read /etc/passwd). The sandbox monitors the host OS using system-call interceptors (ptrace). If the agent allows the payload to touch the host filesystem or network without explicit capability authorization, the sandbox instantly flags a critical isolation failure32.

Proposed Conformance Checklist and Performance Measures

To objectively verify that the onboarded agent meets the requirements for security, interoperability, and capability, operators must evaluate the agent against a strict conformance checklist. This checklist relies entirely on observable input/output behavior and protocol compliance, claiming no compatibility that requires unavailable source code inspection.

Defined Objective Measures

To quantify the efficiency and reliability of the onboarding experience, the following three objective measures are established:

• Time to First Verified Result (TTFVR): Measured from the exact millisecond the agent process starts (initiating SPIFFE attestation) to the millisecond the client receives a Completed A2A status containing valid output artifacts. For a minimal setup utilizing Wasm execution, TTFVR should reliably fall under 500 milliseconds.
• Manual Setup Steps: Defined strictly as the number of distinct human actions (e.g., generating API keys, writing configuration files, modifying DNS records) required before the agent can boot. A highly compliant minimal integration should achieve zero manual setup steps, relying entirely on programmatic attestation and automated URI discovery.
• Recovery from a Lost Response (RLR): Measured as the time taken for the client to retrieve the terminal state of an orphaned task utilizing idempotency keys or A2A polling continuations, starting from the exact moment network connectivity is reestablished. This duration should equate strictly to the network round-trip time (RTT), as the server must bypass all re-computation and simply serve the cached state.

Strategic Recommendations and Conclusion

The mandate to engineer the smallest, most resilient onboarding experience for an independently operated agent fundamentally rejects the premise of centralized orchestration. Relying on proprietary cloud runtimes, shared-kernel containers, or vendor-locked SDKs creates unacceptable single points of failure and artificially restricts the evolution of the agentic web to a handful of large technology providers. This analysis indicates that the optimal path forward requires integrating orthogonal, highly specialized open standards into a singular, cohesive technology stack. The definitive recommendation for the minimal integration surface is as follows: Implement the Agent-to-Agent (A2A) protocol's agent.json and JSON-RPC state machine to standardize task negotiation without presuming continuous connectivity. Adopt the stateless primitives of the July 2026 Model Context Protocol (MCP) to provide a strict grammar for localized tool execution. Merge SPIFFE workload identity with RFC 8693 token exchange to guarantee transport security via mTLS while preserving the vital cryptographic audit trail of user delegation, thereby eliminating the catastrophic practice of agent impersonation. Utilize the x402 HTTP payment protocol to shift economics directly to the transport headers, enabling agents to dynamically buy and sell capabilities permissionlessly. Finally, embed WebAssembly (Wasm) runtimes utilizing the Component Model to ensure microsecond cold-starts and mathematically proven memory safety. By aligning to these specific protocols, operators ensure their autonomous agents can discover work, execute untrusted logic securely, manage complex human-in-the-loop workflows, and transact economic value—all while maintaining absolute independence from proprietary infrastructure. The resulting architecture is lightweight enough to run in constrained edge environments, yet robust enough to participate securely and autonomously in the global multi-agent economy.

Works cited

1. What is the Model Context Protocol (MCP)? \- Databricks, https://www.databricks.com/blog/what-is-model-context-protocol

2. Agent Network Protocol White Paper \- GitHub Pages, https://w3c-cg.github.io/ai-agent-protocol/

3. A Survey of AI Agent Protocols \- arXiv, https://arxiv.org/html/2504.16736v3

4. AgentProtocol.ai — AI agent protocols explained, https://agentprotocol.ai/

5. agi-inc/agent-protocol: Common interface for interacting ... \- GitHub, https://github.com/agi-inc/agent-protocol

6. Agent2Agent Protocol: The Standard for AI Agent Interoperability, https://www.salesforce.com/agentforce/ai-agents/agent2agent-protocol/

7. How to Implement A2A Protocol on Your Blog: A Complete Guide, https://colinmcnamara.com/blog/how-to-implement-a2a-protocol-on-your-blog

8. Build Cross-Language Multi-Agent Team with Google's Agent, https://developers.googleblog.com/build-cross-language-multi-agent-team-with-google-agent-development-kit-and-a2a/

9. What is Agent-to-Agent Protocol? \- Microblink, https://microblink.com/resources/glossary/agent-to-agent-protocol/

10. What is Model Context Protocol (MCP)? A guide | Google Cloud, https://cloud.google.com/discover/what-is-model-context-protocol

11. A2A agent service | Microsoft Learn, https://learn.microsoft.com/en-us/agent-framework/integrations/by-component/agent-services/a2a

12. An In-Depth Look at Google's A2A Protocol \- Euler AI, https://www.eulerai.au/blog/a2a

13. Specification \- What is the Model Context Protocol (MCP)?, https://modelcontextprotocol.io/specification/2026-07-28

14. Introducing the Model Context Protocol \- Anthropic, https://www.anthropic.com/news/model-context-protocol

15. Model Context Protocol (MCP) explained: A practical ... \- CodiLime, https://codilime.com/blog/model-context-protocol-explained/

16. Architecture overview \- What is the Model Context Protocol (MCP)?, https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture

17. Architecture \- What is the Model Context Protocol (MCP)?, https://modelcontextprotocol.io/specification/draft/architecture

18. 402 Payment Required: What Enterprise MCP Servers Owe Agents, https://aaif.io/blog/402-payment-required-what-enterprise-mcp-servers-owe-the-agents-that-pay-them

19. OpenAPI vs AsyncAPI for Agent Integrations \- JP Casabianca, https://jpcasabianca.com/journal/openapi-vs-asyncapi-agent-integrations/

20. Fundamentals of Agent Accessibility | Jeff Bailey, https://jeffbailey.us/blog/2026/04/11/fundamentals-of-agent-accessibility/

21. AsyncAPI Initiative for event-driven APIs | AsyncAPI Initiative for, https://www.asyncapi.com/

22. Align Production Reality and Event Documentation with ... \- AsyncAPI, https://www.asyncapi.com/blog/asyncapi-discovery-intro

23. agent.json | agent.json, https://agent-json.com/

24. SPIFFE Is What AI Agents Need for Identity, The Question ... \- Riptides, https://riptides.io/blog/how-to-deliver-spiffe-identity-to-ai-agents/

25. SPIFFE for AI Agent Identity \- Medium, https://medium.com/@dipakkrdas/spiffe-for-ai-agent-identity-91102112f4ec?sharedUserId=dipakkrdas

26. Wiring zero trust identity for AI agents: SPIFFE, token exchange, and, https://next.redhat.com/2026/06/10/wiring-zero-trust-identity-for-ai-agents-spiffe-token-exchange-and-kagenti/

27. How AI Agents Get Impersonated (and How to Stop It) \- ZITADEL, https://zitadel.com/blog/ai-agent-impersonation

28. Token Exchange for Agents: Delegation Without Impersonation, https://www.agenticfabriq.com/blog/token-exchange-rfc-8693-for-agents

29. Agent Identity and Delegation \- TrueFoundry Docs, https://www.truefoundry.com/docs/ai-gateway/agents/agent-identity-obo

30. x402 Protocol Explained: How AI Agents Pay Onchain | Support \- Eco, https://eco.com/support/en/articles/12328618-x402-protocol-explained-how-ai-agents-pay-onchain

31. What is x402? \- Circle Docs, https://developers.circle.com/x402-facilitators/x402

32. AI Sandbox: The Complete Guide to Sandboxing AI Agents in 2026, https://cosmonic.com/blog/ai-sandbox-guide/

33. Orchestrating WASM-based MCP Tool Runtimes for AI Agents, https://leeky.me/publications/mcp-wasm-continuum.pdf

34. GitHub \- restyler/awesome-sandbox, https://github.com/restyler/awesome-sandbox

35. AI Agent Code Execution Sandboxes: Isolation from Containers to, https://addozhang.medium.com/ai-agent-code-execution-sandboxes-isolation-from-containers-to-microvms-e80848effea5

36. Configuring workload identity federation for SPIFFE | OpenAI API, https://developers.openai.com/api/docs/guides/workload-identity-federation/spiffe

37. \[FEATURE\] Workload identity for AI agents via SPIFFE/SPIRE \#122, https://github.com/inference-gateway/operator/issues/122

38. SPIRE Concepts | SPIFFE, https://spiffe.io/docs/latest/spire-about/spire-concepts/

39. AI agents and the multi-hop delegation problem \- WorkOS, https://workos.com/blog/oauth-multi-hop-delegation-ai-agents

40. Impersonation vs. Delegation: Getting On-Behalf-Of Tokens Right, https://aembit.io/blog/impersonation-vs-delegation-getting-on-behalf-of-tokens-right/

41. Examples for Agentic AI use cases · Issue \#50690 \- GitHub, https://github.com/keycloak/keycloak/issues/50690

42. How to Authorize AI Agents Using Token Exchange Open Standards, https://keycard.ai/blog/how-to-authorize-ai-agents-using-token-exchange-open-standards/

43. x402: The HTTP Payment Protocol That Lets AI Agents Spend, https://www.spark.money/research/x402-protocol-ai-agent-payments

44. What is x402? HTTP 402 payments for AI agents \- MetaMask, https://metamask.io/news/what-is-x402

45. Five Attacks on x402 Agentic Payment Protocol \- arXiv, https://arxiv.org/html/2605.11781v1

46. Code locally, deploy globally. With absolute safety \- Fastly, https://www.fastly.com/products/deploy

47. Wasmtime vs Wasmer vs WasmEdge: WASM Runtime Comparison, https://reintech.io/blog/wasmtime-vs-wasmer-vs-wasmedge-wasm-runtime-comparison-2026

48. .well-known/agent.json (Agent Card) – AI Discovery Guide & JSON, https://sge-score.com/en/sge-geo-knowledge/schema-ai-native/well-knownagentjson-agent-card