{"id":"5337c473-97d7-4ebc-86ac-a4cbf0f1d717","arxiv_id":"2505.12490","paper_version":3,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"A set of protocol-level enhancements for A2A, including a USER_CONSENT_REQUIRED state and a DirectDataFlowController, is proposed to keep payment and identity data away from intermediary agents.","lead":"The paper proposes adding consent checkpoints, short-lived scoped tokens, and direct user-to-service data channels to Google's A2A agent protocol to protect sensitive data. It reports zero prompt-injection leakage when the agent never sees the secret, but the design is not yet tested as a full protocol implementation.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Agent B's zero leakage is not evidence for the protocol enhancements: the experiment removes the secret from prompt context rather than exercising the proposed A2A mechanisms, so the central empirical claim remains untested.","rationale":"The reader's weakest_assumption identifies the same load-bearing concern: Agent B is a proxy that omits the secret from the prompt rather than exercising the proposed A2A enhancements. The empirical zero-leakage result is therefore a data-minimization demonstration, not evidence that USER_CONSENT_REQUIRED, ephemeral scoped tokens, or the DirectDataFlowController's consent and endpoint checks work as claimed under attack. The theoretical analysis in Section VIII.C is circular in the same way, since it assumes the very property the protocol must enforce. I do not see a further independent flaw that would change the verdict. The design contributions are coherent, the threat model is reasonable, and the public code and pseudocode are concrete artifacts; the gap is in evidence and framing, not in internal inconsistency. The conditional verdict already captures the required revision: either reframe the contribution as a data-minimization pattern or implement and test the actual protocol-level changes. No adjustment to the reader's verdict is needed.","tokens_in":16854,"tokens_out":3124,"duration_ms":36395,"concrete_test":"Re-run the Section VIII.A experiment with Agent B configured exactly like Agent A (secret present in the prompt context), but add the DirectDataFlowController path so the secret is sent directly to a service endpoint that echoes it back into Agent B's next task context; then run the same nine adversarial prompts. If leakage exceeds zero, Eq. 3's p_s = 0 assumption fails under realistic protocol operation. If leakage remains zero while the secret is actually in context, the paper's 'direct transfer' explanation would also need revision, since the experiment would no longer isolate the mechanism claimed to provide protection.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim that the enhanced protocol reduces leakage to zero rests on Section VIII.A's comparison. Agent A retains sensitive data in conversational memory; Agent B 'avoids embedding secrets in prompts' and uses 'direct data transfer logic.' Agent B implements none of the proposed protocol artifacts from Sections V and VII: no USER_CONSENT_REQUIRED state, no scoped ephemeral token, no SCA, no endpoint registry check, and no secure tunnel. The nine prompts therefore test whether an LLM can leak a secret it never received, not whether the A2A-level mechanisms provide protection. That is a valid data-minimization demonstration, but it cannot validate the protocol-level machinery. The theoretical model in Eq. 3 makes the same move: it sets p_s = 0 by assuming 'sensitive data is never embedded in agent prompts,' which is exactly the conclusion needing evidence. DirectDataFlowController as pseudocoded only reroutes sensitive transfers; it does not prove the secret can never appear in an agent's context, for example if a service response echoes payment confirmation data or if a non-sensitive subtask carries a sensitive field. Thus zero leakage follows from the experimental setup, not from the proposed enhancements.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper identifies four weaknesses in Google's Agent-to-Agent (A2A) protocol—insufficient token lifetime control, lack of strong customer authentication, overbroad access scopes, and missing consent flows—and proposes protocol-level enhancements: a USER_CONSENT_REQUIRED task state, a DirectDataFlowController, ephemeral scoped tokens, and direct user-to-service data channels. It grounds the proposal in a semi-trusted threat model and illustrates the design with a vacation-booking scenario. The empirical section compares a baseline agent (Agent A) that retains sensitive data in conversational memory with a 'secured' agent (Agent B) that avoids embedding secrets in prompts and uses direct data transfer logic. Nine adversarial prompts were run five times per agent; Agent A leaked in 60–100% of attempts while Agent B leaked in 0%. A theoretical model in Section VIII.C (Eqs. 1–3) is used to argue that the enhanced configuration reduces cumulative leakage probability to zero. The paper concludes with a comparative analysis against original A2A and OAuth 2.0, and with recommendations for adoption.","tokens_in":17194,"tokens_out":4514,"duration_ms":44959,"significance":"The proposal is a useful systematization of A2A's weaknesses and a plausible design direction: minimizing exposure through direct data channels, consent states, and short-lived scoped credentials has clear security merit. The structured threat model, explicit security goals, and pseudocode for DirectDataFlowController make the design concrete and reusable. However, the claimed zero-leakage result is not evidence for the proposed mechanisms as implemented, because the experiment tests an agent that never receives the secret rather than an agent operating under the proposed protocol enhancements. The formal model in Eq. (3) reduces to the design assumption p_s=0. If the protocol-level mechanisms are implemented and tested directly, the paper could support a modest but real contribution; in its current form the central empirical validation is missing. The paper also promises code repositories in Sections V and VIII, which is a reproducibility strength if the artifacts are complete and runnable.","major_comments":[{"comment":"The empirical comparison does not test the proposed protocol enhancements. Agent B is described only as avoiding embedding secrets in prompts and using 'direct data transfer logic'; it is not stated to implement USER_CONSENT_REQUIRED, ephemeral scoped tokens, SCA, endpoint-registry checks, or the secure tunnel from Section VII. The nine-prompt experiment therefore shows that an LLM cannot leak a secret it never received, not that the proposed A2A-level mechanisms reduce leakage. The claim in Section VIII.B that 'our enhanced A2A protocol achieves zero leakage' is unsupported by the data as presented. Please rerun the evaluation with an agent configuration that actually exercises the proposed artifacts, and report the exact data flow for Agent B, including where the secret is stored and what content B receives.","section":"Section VIII.A"},{"comment":"The theoretical analysis is circular. The paper sets p_s=0 for the enhanced configuration because 'the DirectDataFlowController enforces that sensitive data is never embedded in agent prompts,' which is exactly the conclusion needing evidence. Eq. (3) then yields P_L=0 by substitution, not by derivation or measurement. Moreover, Fig. 7's pseudocode only reroutes sensitive transfers; it does not establish that a secret can never appear in an agent's context, for example if a service response echoes payment confirmation data or if a non-sensitive subtask carries a sensitive field. The model should either derive p_s from an explicit mechanism that provably prevents secret inclusion, or measure p_s in an implementation of the controller.","section":"Section VIII.C, Eq. (3)"},{"comment":"The performance comparison is not interpretable as a cost of the proposed protocol. Table I shows that Agent B sometimes has a larger mean and standard deviation than Agent A, such as 3.52 s vs 1.24 s for the regex-matching prompt, yet Section IX states that the latency increase ranges from 0.2 to 0.8 s. The discrepancy is not explained. More importantly, because Agent B's configuration is not the proposed protocol, none of the latency figures can be attributed to the protocol-level mechanisms such as consent orchestration or token issuance.","section":"Section IX and Table I"}],"minor_comments":[{"comment":"The agent labels are inconsistent: the text refers to Agent 1 and Agent 2, then later to Agent A, and Figure 6 mentions 'Agent A' while Section VI describes Agent 1. Please unify the naming throughout.","section":"Section VI"},{"comment":"The exact prompt templates used in the nine attacks are not included in the paper, which limits reproducibility. Please provide the full prompts in an appendix or as a supplementary artifact.","section":"Section VIII.A"},{"comment":"The row labeled 'Our Enhanced A2A' attributes zero leakage to DirectDataFlowController, but the experiment did not use that controller. Relabel the row to describe the actual configuration tested, for example 'Agent without secret in prompt context,' to avoid overclaiming.","section":"Section VIII.B, Table II"},{"comment":"The claimed latency increase of 0.2–0.8 seconds does not match Table I, where several Agent B rows are faster than Agent A and the regex row has mean 3.52 s. Please reconcile the reported range with the table.","section":"Section IX"},{"comment":"The sentence 'we present how to enforces these mechanisms at the protocol level' contains a grammatical error and should read 'how to enforce.'","section":"Section IV"},{"comment":"The phrase 'prior empirical studies report reported Attack Success Rate' contains a duplicated word ('report reported').","section":"Section VIII.B"},{"comment":"Reference [57] is attributed only to 'xzou' and lacks a full author name and publication details; please complete the citation.","section":"References"}],"recommendation":"major_revision","confidential_remarks":"The paper is positioned as a protocol improvement but currently functions as a design proposal plus a proxy experiment that does not exercise the proposed mechanisms. The authors should either implement the proposed mechanisms end-to-end or explicitly reframe the empirical claim as a data-minimization demonstration. The comparison against prior prompt-injection studies is also not apples-to-apples because those studies attack application-level LLM pipelines rather than the A2A protocol itself; this should be clarified in the revision. Given the venue, a true protocol-level evaluation would strengthen the fit considerably."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The paper proposes useful protocol-level additions to Google's A2A: a USER_CONSENT_REQUIRED task state, ephemeral scoped tokens, and a DirectDataFlowController that routes sensitive data directly from user to service. These are coherent, sensible ideas, and the threat model is structured more carefully than most work in this space. The literature survey is broad and does a decent job of grounding each proposed fix in prior art, including CVEs and recent academic papers. If you work on agent interoperability security, this is worth a skim for the design discussion alone.\n\nThe problem is the evidence. The headline claim—that the enhanced protocol reduces leakage to zero—is not supported by the experiment in Section VIII. Agent B differs from Agent A by not receiving the sensitive data in the first place. It implements none of the proposed A2A mechanisms: no USER_CONSENT_REQUIRED, no scoped ephemeral token, no SCA, no endpoint registry check, no secure tunnel. So the zero-leakage result simply shows that an LLM cannot leak a secret it never had. That is a valid data-minimization demonstration, but it does not test the protocol enhancements. The theoretical model does the same thing: Equation (3) sets p_s to zero by assuming sensitive data is never embedded in prompts, which is exactly the conclusion needing evidence. That is circular in a way the paper does not acknowledge.\n\nI would not call the paper fatally flawed, because the design itself is defensible and the authors are honest about the experiment's illustrative purpose in Section VI. But the framing overreaches. The comparative table with OAuth is somewhat hand-wavy, and the paper is overlong with occasional typos (e.g., \"we illustrate and implementation how\" in Section VI). These are minor compared to the central evidential gap.\n\nWho should read this: people thinking about standards for agent-to-agent communication, especially around payments and identity. It is a reasonable proposal document, not a validated security result. If it goes to peer review, the authors should be pushed to either reframe the experiment as a data-minimization demonstration or actually implement the A2A changes and test them. I would send it to a serious referee because the design contribution deserves discussion, but with the expectation of major revision.\n\nRecommendation: engage with it, but treat the empirical claims with skepticism until they test the actual protocol.","headline":"Reasonable design proposal for A2A security enhancements, but the empirical claim of zero leakage is untested because the experiment removes the secret from the second agent rather than exercising the proposed protocol mechanisms.","tokens_in":17606,"tokens_out":1448,"would_cite":false,"duration_ms":16458,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper claims that protocol-level enhancements to Google's Agent-to-Agent (A2A) protocol—ephemeral scoped tokens, strong customer authentication, explicit consent states, and a DirectDataFlowController that sends sensitive data…","keywords":["Agent-to-Agent protocol","multi-agent systems","prompt injection","sensitive data leakage","consent orchestration","direct data flow","short-lived tokens","zero trust"],"falsifier":"Run the same nine adversarial prompts against an agent that does hold the secret in its context but is wrapped in the full proposed protocol layer—ephemeral scoped tokens, USER_CONSENT_REQUIRED state, and DirectDataFlowController audit logging—without actually removing the secret from the prompt. Any nonzero leakage in that configuration would falsify the claim that the protocol-level enhancements themselves reduce $p_s$ to zero, rather than the context separation alone.","tokens_in":16611,"feed_emoji":"🔐","tokens_out":5919,"duration_ms":47345,"temperature":0.7,"pith_summary":"This paper argues that Google's Agent-to-Agent (A2A) protocol, as specified, cannot safely handle sensitive data such as payment credentials or identity documents in multi-agent workflows. It identifies four structural gaps: tokens that outlive their transaction, no strong customer authentication, coarse-grained scopes, and no user consent flow. The authors propose protocol-level fixes: ephemeral single-use tokens, strong authentication, granular scopes, a new USER_CONSENT_REQUIRED task state, and a DirectDataFlowController that routes sensitive data directly from the user to the service provider without passing through AI agents. Under adversarial prompt injection, they report zero leakage for the enhanced configuration versus 60–100% for the baseline, and they model this as reducing the per-attempt leakage probability to zero. A sympathetic reader would care because the proposal converts A2A from a framework that merely recommends security to one that enforces data minimization inside the protocol itself.","feed_headline":"A2A fix cuts prompt-injection leakage to zero","feed_subtitle":"Enhanced A2A routes payments and IDs directly from user to service, shrinking the multi-agent attack surface.","key_machinery":"The load-bearing object is the DirectDataFlowController, a protocol component that intercepts any task involving sensitive data, checks that the user has explicitly approved the transfer and that the recipient is a trusted registry endpoint, then issues a short-lived (about two minutes) single-use token and opens a secure tunnel between the user and the service provider, bypassing all intermediary agents. Its effect is context separation: the secret never enters an agent's prompt, so prompt injection has nothing to steal. A supporting mechanism is the new TaskState enumeration member USER_CONSENT_REQUIRED, which halts task execution at the orchestration layer until affirmative user consent is recorded, making consent a protocol state rather than an application convention.","core_discovery":"The paper's central claim is that the A2A protocol can be extended so that sensitive data is never exposed to intermediary agents, and that this extension eliminates prompt-injection leakage of that data. The core discovery is a two-part mechanism: a new protocol state, USER_CONSENT_REQUIRED, pauses task execution until the end user explicitly approves a sensitive action, and a DirectDataFlowController verifies consent and endpoint legitimacy before issuing a short-lived, single-use token and opening a secure tunnel straight from the user to the service provider. In the empirical evaluation, the baseline agent (holding the secret in conversational memory) leaked the simulated credit card and ID number in 60–100% of adversarial prompt attempts, while the secured agent—which never receives the secret—leaked nothing across 45 attempts. The paper models this as a leakage probability $P_L = 1-(1-p_s)^n$ with per-attempt success $p_s$ between 0.6 and 0.9 for the baseline, reduced to $P_L = 0$ when the controller keeps the secret out of the prompt context. The authors present this as a protocol-level, privacy-by-default redesign rather than an application-layer patch.","pith_inferences":["The zero-leakage result is most directly explained by the agent never possessing the secret; the same guarantee would likely hold for any architecture that keeps secrets out of agent context, so the token, consent, and channel mechanisms may be sufficient but not strictly necessary for this specific outcome.","A sharper falsification test would keep the secret in the agent's context while enabling the proposed token scoping, consent states, and direct-transfer audit logging; any leakage in that configuration would show that context separation, not the protocol mechanics, is what delivers the zero-leakage result.","The 'never give the secret to the agent' principle should transfer to other agent protocols, such as MCP, that embed sensitive data in tool-call contexts; the paper does not test this, but the mechanism is transport-agnostic.","The theoretical model assumes independent attack attempts; adaptive or correlated attacks—for example, using one partial disclosure to craft a more effective follow-up—could invalidate the $P_L = 0$ claim outside the tested threat model."],"forward_implications":["An A2A deployment that adopts the DirectDataFlowController can prevent prompt-injection exfiltration of payment credentials and identity documents whenever the orchestrating agent does not receive them.","The USER_CONSENT_REQUIRED state gives every sensitive action a protocol-level, auditable consent checkpoint, which the paper argues aligns A2A with GDPR and PSD2 expectations.","Ephemeral, single-operation tokens shrink the window for replay attacks from hours or days to minutes, directly addressing token-lifetime weaknesses.","Routing sensitive data over direct user-to-service channels removes intermediate agents from the data path, reducing the attack surface in semi-trusted multi-agent systems.","The leakage model implies that even a baseline with 80% per-attempt success becomes almost certain to leak ($P_L \\approx 0.99968$) within five attempts, whereas the enhanced protocol stays at zero for the tested attack class."],"supporting_citations":[{"why":"Supplies the baseline leak rate (86.1%) for LLM-integrated applications, used in the comparison table and as input to the theoretical p_s range.","marker":"[23]"},{"why":"Provides the 60–90% attack success rates for open-source LLMs that the enhanced A2A results are compared against.","marker":"[24]"},{"why":"Documents that tool-calling agents leak personal data under simple prompt injection, motivating the evaluation setup.","marker":"[25]"},{"why":"Argues that coarse-grained authorization increases data exposure, supporting the proposed granular scopes and direct transfer flow.","marker":"[13]"},{"why":"Documents agent-to-agent data propagation and prompt injection risks, grounding the need to minimize agent access to sensitive data.","marker":"[7]"},{"why":"Argues that decentralized agent environments require explicit consent, delegation, and auditability controls, grounding the consent orchestration enhancement.","marker":"[8]"},{"why":"Presents an authenticated delegation and authorized AI agents framework that the paper extends to support direct user-to-service transfer.","marker":"[43]"},{"why":"ActionID's time- and action-scoped tokens provide the precedent for the short-lived token enhancement.","marker":"[29]"}],"fun_headline_variants":["A2A upgrade routes secrets directly, stopping leaky prompts","Zero prompt-injection leaks with A2A consent + direct tunnels","A2A fix: direct user-to-service channel kills data leaks","A2A protocol upgrade eliminates prompt-injection data theft","Sensitive data never touches agents: A2A consent and direct flow"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The empirical evaluation assumes that an agent configuration which omits secrets from the prompt context and runs a 'direct transfer logic' is a faithful proxy for the enhanced A2A protocol; the paper's Agent B differs from Agent A only by not receiving the secret, not by using the proposed A2A token, scope, consent, or channel mechanisms.","fun_headline_variants_meta":{"raw":{"variants":["A2A upgrade routes secrets directly, stopping leaky prompts","Zero prompt-injection leaks with A2A consent + direct tunnels","A2A fix: direct user-to-service channel kills data leaks","A2A protocol upgrade eliminates prompt-injection data theft","Sensitive data never touches agents: A2A consent and direct flow"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00057,"raw_usage":{"total_tokens":2717,"prompt_tokens":989,"completion_tokens":1728,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":605,"completion_tokens_details":{"reasoning_tokens":1639}},"tokens_in":605,"tokens_out":1728,"duration_ms":12372,"temperature":1.0,"reasoning_tokens":1639,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T20:32:20.521362+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the same nine adversarial prompts against an agent that does hold the secret in its context but is wrapped in the full proposed protocol layer—ephemeral scoped tokens, USER_CONSENT_REQUIRED state, and DirectDataFlowController audit logging—without actually removing the secret from the prompt. Any nonzero leakage in that configuration would falsify the claim that the protocol-level enhancements themselves reduce $p_s$ to zero, rather than the context separation alone.","supporting_citations":[{"cited_title":"Applestorm: Investigating 13 privacy risks in apple intelligence and siri,","cited_arxiv_id":null,"evidence_quote":"Supplies the baseline leak rate (86.1%) for LLM-integrated applications, used in the comparison table and as input to the theoretical p_s range."},{"cited_title":"Multi-agent security tax: Trading off security and collaboration capabilities in multi-agent systems,","cited_arxiv_id":null,"evidence_quote":"Argues that coarse-grained authorization increases data exposure, supporting the proposed granular scopes and direct transfer flow."},{"cited_title":"Ai agents under threat: A survey of key security challenges and future pathways,","cited_arxiv_id":null,"evidence_quote":"Documents agent-to-agent data propagation and prompt injection risks, grounding the need to minimize agent access to sensitive data."},{"cited_title":"Agnet: A novel ai agent network architec- ture,","cited_arxiv_id":null,"evidence_quote":"ActionID's time- and action-scoped tokens provide the precedent for the short-lived token enhancement."}],"review_version":1}