Pith. sign in

REVIEW 3 major objections 7 minor 68 references

Improving Google A2A Protocol: Protecting Sensitive Data and Mitigating Unintended Harms in Multi-Agent Systems

T0 review · 3 major / 7 minor · reviewed 2026-08-15 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read 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…

desk verdict 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. read the letter →

arxiv 2505.12490 v3 pith:CI3KRNGT submitted 2025-05-18 cs.CR

Yedidel Louck , Ariel Stulman , Amit Dvir This is my paper · ORCID
classification cs.CR
keywords Agent-to-Agentprotocolmulti-agentsystemspromptinjectionsensitivedataleakageconsentorchestrationdirectflowshort-livedtokenszerotrust
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • 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.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 7 minor

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.

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 (3)
  1. [Section VIII.A] 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.
  2. [Section VIII.C, Eq. (3)] 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.
  3. [Section IX and Table I] 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.
minor comments (7)
  1. [Section VI] 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.
  2. [Section VIII.A] 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.
  3. [Section VIII.B, Table II] 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.
  4. [Section IX] 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.
  5. [Section IV] The sentence 'we present how to enforces these mechanisms at the protocol level' contains a grammatical error and should read 'how to enforce.'
  6. [Section VIII.B] The phrase 'prior empirical studies report reported Attack Success Rate' contains a duplicated word ('report reported').
  7. [References] Reference [57] is attributed only to 'xzou' and lacks a full author name and publication details; please complete the citation.

Circularity Check

3 steps flagged · score 8.0 of 10

The zero-leakage claim is circular: Eq. (3) substitutes ps=0 by assumption, and Agent B's 0/45 result is guaranteed by withholding the secret rather than exercising the proposed A2A mechanisms.

  1. self definitional [Section VIII.C, 'Theoretical Analysis of Leakage Probability', Eq. (3)]
    "In our enhanced A2A protocol, the DirectDataFlowController enforces that sensitive data is never embedded in agent prompts, reducing ps to zero under the tested threat model. Thus: P enhanced L = 1 − (1 − 0)n = 0, (3) which aligns with the empirical zero-leakage results that shown at Table I."

    Eq. (3) computes 1 - (1 - ps)^n with ps = 0, so it returns 0 identically; the only substantive input is the assertion that the controller keeps sensitive data out of prompts. That assertion is exactly the property whose effectiveness the paper claims to demonstrate. No measurement or protocol-level proof of 'never embedded' is supplied here, so the zero-leakage result is substituted in by definition rather than derived or measured.

  2. fitted input called prediction [Section VIII.A, 'Experimental Results for Our Enhanced A2A' (Table I, Figure 8)]
    "We conducted a comparative experiment between two agent configurations, both based on the Gemini 2.0 Flash model: a baseline agent (Agent A), which retains sensitive user data in conversational memory, and a secured agent (Agent B), which avoids embedding secrets in prompts and utilizes direct data transfer logic."

    Agent B's zero leakage is guaranteed by the experimental construction: an LLM cannot output a secret that was never placed in its input or memory. The only manipulated variable is the presence of the secret in prompt context; the Section V and VII protocol artifacts (USER_CONSENT_REQUIRED, registered endpoint, short-lived token, secure tunnel) are not exercised or isolated by these nine prompts. The 0/45 result is therefore a restatement of 'no secret in prompt context', not evidence for the DirectDataFlowController or other A2A enhancements.

1 more flagged steps
  1. fitted input called prediction [Section VIII.B, Table II, 'Comparison with Prior Empirical Studies']
    "Our Enhanced A2A Multi-agent with DirectDataFlowController 0 No sensitive data in prompt context"

    The reported 0% success rate is annotated by the input condition 'No sensitive data in prompt context', not by any operation of the proposed controller. Putting the causal condition in the notes column makes the 'result' identical to the setup: the table compares an experiment that withholds the secret with prior experiments that do not, so the comparison cannot attribute the difference to the protocol.

full rationale

The paper's design recommendations (ephemeral tokens, SCA, scoped credentials, consent states, direct user-to-service channels) are mostly supported by citations to independent prior work and are not themselves circular. However, the paper's central empirical and theoretical validation of zero leakage is circular in two linked places. In Section VIII.C, the model computes PL=1-(1-ps)^n with ps set to 0 because 'the DirectDataFlowController enforces that sensitive data is never embedded in agent prompts'; that is the conclusion restated as an assumption, so Eq. (3) is an identity. In Section VIII.A, the Agent B configuration differs from Agent A only by not giving the secret to the agent; no Section V/VII machinery is exercised, so 0/45 leakage is guaranteed by construction, since an LLM cannot reveal a secret it never possessed. Table II's 0% row is literally annotated 'No sensitive data in prompt context'. This does not show falsity of the design goal, because keeping secrets out of agent context does prevent context-based leakage, but it means the paper has not empirically validated the proposed protocol mechanisms, and the zero-leakage 'prediction' reduces to its input. Because this is the central empirical claim, the score is 8; no self-citation chain is involved.

Assumptions & free parameters 1 free parameters · 4 assumptions · 2 invented entities

The central empirical claim rests on several unverified assumptions: the independence model in Equation (1), the correctness of a trusted endpoint registry, the availability of a user to approve actions, and the equivalence between Agent B's data-minimizing configuration and the proposed A2A protocol. The only fitted or hand-chosen value in the model is p_s for the enhanced configuration, which is set to zero by design.

free parameters (1)
  • p_s (per-attempt success probability) for the enhanced configuration = 0 (assumed by design)
    The leakage model sets p_s to zero for the enhanced protocol because sensitive data is never embedded in prompts. This is a design assumption, not a measured value from an implemented A2A protocol.
assumptions (4)
  • standard math Attack attempts are statistically independent in the cumulative leakage formula.
    Equation (1), P_L = 1 - (1 - p_s)^n, assumes independence across n attempts; correlated or adaptive attacks could invalidate the model.
  • domain assumption A trusted endpoint registry is correctly maintained and distributed.
    DirectDataFlowController relies on Registry.is_trusted(endpoint); if the registry is compromised, the direct channel can be redirected to a malicious recipient.
  • domain assumption End users can approve or deny sensitive actions when prompted.
    Consent orchestration pauses on USER_CONSENT_REQUIRED and assumes a reachable, capable user; fully automated or delegated workflows may not provide this.
  • ad hoc to paper An agent configuration that omits the secret from context is a faithful proxy for the enhanced A2A protocol.
    The experiment's Agent B uses data minimization rather than the proposed A2A token, scope, consent, or channel mechanisms; this equivalence is asserted, not demonstrated.
invented entities (2)
  • USER_CONSENT_REQUIRED TaskState value
    purpose: Pause task execution until the end-user grants affirmative consent before sensitive data is processed.
    Proposed as a new enum member for A2A's TaskState; no deployed implementation or formal specification validation is provided.
  • DirectDataFlowController
    purpose: Verify consent and trusted endpoint, issue a short-lived single-use token, and open a direct user-to-service tunnel to bypass intermediary agents.
    Presented only as pseudocode with a hardcoded TTL of 120 seconds; no implementation, tests, or interoperability evaluation is provided.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Improving Google A2A Protocol: Protecting Sensitive Data and Mitigating Unintended Harms in Multi-Agent Systems." pith.science (2026). https://pith.science/paper/CI3KRNGT

@misc{pith2026250512490,
  author       = {Pith},
  title        = {Pith review of: Improving Google A2A Protocol: Protecting Sensitive Data and Mitigating Unintended Harms in Multi-Agent Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CI3KRNGT}},
  note         = {Machine review of arXiv:2505.12490}
}
read the original abstract

Googles A2A protocol provides a secure communication framework for AI agents but demonstrates critical limitations when handling highly sensitive information such as payment credentials and identity documents. These gaps increase the risk of unintended harms, including unauthorized disclosure, privilege escalation, and misuse of private data in generative multi-agent environments. In this paper, we identify key weaknesses of A2A: insufficient token lifetime control, lack of strong customer authentication, overbroad access scopes, and missing consent flows. We propose protocol-level enhancements grounded in a structured threat model for semi-trusted multi-agent systems. Our refinements introduce explicit consent orchestration, ephemeral scoped tokens, and direct user-to-service data channels to minimize exposure across time, context, and topology. Empirical evaluation using adversarial prompt injection tests shows that the enhanced protocol substantially reduces sensitive data leakage while maintaining low communication latency. Comparative analysis highlights the advantages of our approach over both the original A2A specification and related academic proposals. These contributions establish a practical path for evolving A2A into a privacy-preserving framework that mitigates unintended harms in multi-agent generative AI systems.

Figures

Figures reproduced from arXiv: 2505.12490 by the authors.

Figure 2
Figure 2. Threat model for the A2A protocol in a semi-trusted multi-agent [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. Example booking workflow in A2A illustrating overprivilege, long [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figure 4
Figure 4. Booking process flow that pauses at sensitive actions until explicit user approval is obtained using USER [PITH_FULL_IMAGE:figures/full_fig_p008_4.png] view at source ↗
Figures from the paper (3 more)
Figure 6
Figure 6. Figure 6: Operation of Agent 2 sending crafted prompts to Agent A to elicit [PITH_FULL_IMAGE:figures/full_fig_p008_6.png]
Figure 7
Figure 7. Figure 7: Pseudocode showing direct transfer of sensitive data between the user and the service without intermediary agents. [PITH_FULL_IMAGE:figures/full_fig_p010_7.png]
Figure 8
Figure 8. Figure 8: Data leakage rates for all attack types showing Agent B maintained [PITH_FULL_IMAGE:figures/full_fig_p011_8.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

68 extracted references · 52 canonical work pages

  1. [1]

    Agentic ai: Autonomous intelligence for complex goals–a comprehensive survey,

    D. B. Acharya, K. Kuppan, and B. Divya, “Agentic ai: Autonomous intelligence for complex goals–a comprehensive survey,” IEEE Access, 2025

    2025

  2. [2]

    Announcing the agent2agent protocol (a2a),

    R. Surapaneni, “Announcing the agent2agent protocol (a2a),” Apr

    work page

  3. [3]

    Introducing the model context protocol,

    Anthropic, “Introducing the model context protocol,” May 2025. [Online]. Available: https://www.anthropic.com/news/model-context- protocol

    work page 2025

  4. [4]

    Building a secure agentic ai application leveraging a2a protocol,

    I. Habler, K. Huang, V . S. Narajala, and P. Kulkarni, “Building a secure agentic ai application leveraging a2a protocol,” arXiv preprint arXiv:2504.16902, 2025

    arXiv 2025

  5. [5]

    Model context protocol (mcp): Landscape, security threats, and future research directions,

    X. Hou, Y . Zhao, S. Wang, and H. Wang, “Model context protocol (mcp): Landscape, security threats, and future research directions,” arXiv preprint arXiv:2503.23278, 2025

    arXiv 2025

  6. [6]

    Deep dive: Mcp and a2a attack vectors for ai agents,

    C. Posta, “Deep dive: Mcp and a2a attack vectors for ai agents,” https://www.solo.io/blog/deep-dive-mcp-and-a2a-attack-vectors-for-ai- agents, 2025, accessed: 2025-05-12

    work page 2025

  7. [7]

    Ai agents under threat: A survey of key security challenges and future pathways,

    Z. Deng, Y . Guo, C. Han, W. Ma, J. Xiong, S. Wen, and Y . Xiang, “Ai agents under threat: A survey of key security challenges and future pathways,” ACM Computing Surveys , vol. 57, no. 7, pp. 1–36, 2025

    work page 2025

  8. [8]

    Ai agents meet blockchain: A survey on secure and scalable collaboration for multi-agents,

    M. M. Karim, D. H. Van, S. Khan, Q. Qu, and Y . Kholodov, “Ai agents meet blockchain: A survey on secure and scalable collaboration for multi-agents,” Future Internet, vol. 17, no. 2, p. 57, 2025

    2025

Show all 68 references
  1. [9]

    A survey on model context protocol: Architecture, state-of- the-art, challenges and future directions,

    P. P. Ray, “A survey on model context protocol: Architecture, state-of- the-art, challenges and future directions,” Authorea Preprints, 2025

    2025

  2. [10]

    Enterprise-grade security for the model context protocol (mcp): Frameworks and mitigation strategies,

    V . S. Narajala and I. Habler, “Enterprise-grade security for the model context protocol (mcp): Frameworks and mitigation strategies,” 2025

    2025

  3. [11]

    The OAuth 2.0 Authorization Framework,

    D. Hardt, “The OAuth 2.0 Authorization Framework,” RFC 6749, Oct

  4. [12]

    JSON Web Token (JWT),

    M. B. Jones, J. Bradley, and N. Sakimura, “JSON Web Token (JWT),” RFC 7519, May 2015. [Online]. Available: https://www.rfc- editor.org/info/rfc7519

    2015

  5. [13]

    Multi-agent security tax: Trading off security and collaboration capabilities in multi-agent systems,

    P. Peign ´e, M. Kniejski, F. Sondej, M. David, J. Hoelscher-Obermaier, C. S. de Witt, and E. Kran, “Multi-agent security tax: Trading off security and collaboration capabilities in multi-agent systems,” in Pro- ceedings of the AAAI Conference on Artificial Intelligence , vol. ...

    2025

  6. [14]

    Systematic analysis of mcp security,

    Y . Guo, P. Liu, W. Ma, Z. Deng, X. Zhu, P. Di, X. Xiao, and S. Wen, “Systematic analysis of mcp security,” arXiv preprint arXiv:2508.12538, 2025

    2025 arXiv

  7. [15]

    A survey of llm-driven ai agent communication: Protocols, security risks, and defense countermeasures,

    D. Kong, S. Lin, Z. Xu, Z. Wang, M. Li, Y . Li, Y . Zhang, H. Peng, Z. Sha, Y . Li et al. , “A survey of llm-driven ai agent communication: Protocols, security risks, and defense countermeasures,” arXiv preprint arXiv:2506.19676, 2025

    2025

  8. [16]

    From prompt injections to protocol exploits: Threats in llm-powered ai agents workflows,

    M. A. Ferrag, N. Tihanyi, D. Hamouda, L. Maglaras, and M. Debbah, “From prompt injections to protocol exploits: Threats in llm-powered ai agents workflows,” arXiv preprint arXiv:2506.23260 , 2025

    2025

  9. [17]

    Agentic misalignment: How llms could be insider threats,

    “Agentic misalignment: How llms could be insider threats,” Jun

  10. [18]

    Ai coding tool wipes production database, fabricates 4,000 users, and lies to cover its tracks,

    P. Okunyt ˙e, “Ai coding tool wipes production database, fabricates 4,000 users, and lies to cover its tracks,” Jul 2025. [Online]. Available: https://cybernews.com/ai-news/replit-ai-vive-code-rogue/

    2025

  11. [19]

    When llms autonomously attack,

    M. Cunningham, “When llms autonomously attack,” 2025. [Online]. Available: https://engineering.cmu.edu/news-events/news/2025/07/24- when-llms-autonomously-attack.html

    2025

  12. [20]

    Available: https://www.anthropic.com/research/agentic- misalignment

    [Online]. Available: https://www.anthropic.com/research/agentic- misalignment

  13. [21]

    Scamlexity: When agentic ai browsers clicked, paid, and failed,

    Nati Tal, Guardio Labs, “Scamlexity: When agentic ai browsers clicked, paid, and failed,” https://guard.io/labs/scamlexity-we-put-agentic-ai- browsers-to-the-test-they-clicked-they-paid-they-failed, Aug 2025, ac- cessed: 2025-08-25

    2025

  14. [22]

    Incident analysis for ai agents,

    C. Ezell, X. Roberts-Gaal, and A. Chan, “Incident analysis for ai agents,” arXiv preprint arXiv:2508.14231 , 2025

    2025 arXiv

  15. [23]

    Applestorm: Investigating 13 privacy risks in apple intelligence and siri,

    Yoav Magid, Lumia Security Research Team, “Applestorm: Investigating 13 privacy risks in apple intelligence and siri,” https://lumia.security/blog/ applestorm, Aug 2025, accessed: 2025-08-25

    2025

  16. [24]

    Is your prompt safe? investigating prompt injection attacks against open-source llms,

    J. Wang, P. Gupta, I. Habernal, and E. H ¨ullermeier, “Is your prompt safe? investigating prompt injection attacks against open-source llms,” arXiv preprint arXiv:2505.14368 , 2025

    2025

  17. [25]

    Simple prompt injection attacks can leak personal data observed by llm agents during task execution,

    M. Alizadeh, Z. Samei, D. Stetsenko, and F. Gilardi, “Simple prompt injection attacks can leak personal data observed by llm agents during task execution,” arXiv preprint arXiv:2506.01055 , 2025

    2025 arXiv

  18. [26]

    Prompt injection attack against llm-integrated applications,

    Y . Liu, G. Deng, Y . Li, K. Wang, Z. Wang, X. Wang, T. Zhang, Y . Liu, H. Wang, Y . Zhenget al., “Prompt injection attack against llm-integrated applications,” arXiv preprint arXiv:2306.05499 , 2023

    2023 arXiv

  19. [27]

    Cve-2025-1198: Gitlab personal access token revocation bypass via ac- tioncable,

    “Cve-2025-1198: Gitlab personal access token revocation bypass via ac- tioncable,” https://www.cve.org/CVERecord?id=CVE-2025-1198, 2025, accessed: 2025-05-06

    2025

  20. [28]

    Cve-2025-1801: Jwt exposure via race condition in ansible gateway,

    “Cve-2025-1801: Jwt exposure via race condition in ansible gateway,” https://www.cve.org/CVERecord?id=CVE-2025-1801, 2025, accessed: 2025-05-06

    2025

  21. [29]

    Agnet: A novel ai agent network architec- ture,

    M. Gupta and V . Acharya, “Agnet: A novel ai agent network architec- ture,” Available at SSRN 5108385 , 2024

    2024

  22. [30]

    Hybrid privacy-preserving access control mechanism using blockchain and attribute-based access control for smart home,

    O. B. Ohwo, W. Ajayi, A. Udosen, A. Amusa, M. Y . Agyei, and O. Bamidele, “Hybrid privacy-preserving access control mechanism using blockchain and attribute-based access control for smart home,” in 2024 IEEE SmartBlock4Africa . IEEE, 2024, pp. 1–8

    2024

  23. [31]

    Securing genai multi-agent systems against tool squatting: A zero trust registry-based approach,

    V . S. Narajala, K. Huang, and I. Habler, “Securing genai multi-agent systems against tool squatting: A zero trust registry-based approach,” arXiv preprint arXiv:2504.19951 , 2025

    2025 arXiv

  24. [32]

    Actions speak louder than passwords: Dynamic identity for machine-to-machine communication,

    W. L. Teng and K. Rasmussen, “Actions speak louder than passwords: Dynamic identity for machine-to-machine communication,” in Proceed- ings of the 18th International Conference on Availability, Reliability and Security, 2023, pp. 1–11

    2023

  25. [33]

    Identity theft: a small step towards big financial crimes,

    C. M. Gupta and D. Kumar, “Identity theft: a small step towards big financial crimes,” Journal of Financial Crime , vol. 27, no. 3, pp. 897– 910, 2020

    2020

  26. [34]

    Multifactor authentication could have prevented 9.7 million record medibank data breach,

    HIPAA Journal, “Multifactor authentication could have prevented 9.7 million record medibank data breach,” https://www.hipaajournal.com/multifactor-authentication-could-have- prevented-9-7-million-record-medibank-data-breach/, 2022, accessed: 2025-05-06

    2022

  27. [35]

    From hardware fingerprint to access token: Enhancing the authentication on iot devices,

    Y . Xiao, Y . He, X. Zhang, Q. Wang, R. Xie, K. Sun, K. Xu, and Q. Li, “From hardware fingerprint to access token: Enhancing the authentication on iot devices,” arXiv preprint arXiv:2403.15271 , 2024

    2024 arXiv

  28. [36]

    A trustworthy and untraceable centralised payment protocol for mobile payment,

    J. Neera, X. Chen, N. Aslam, and B. Issac, “A trustworthy and untraceable centralised payment protocol for mobile payment,” ACM Transactions on Privacy and Security , vol. 28, no. 2, pp. 1–29, 2025

    2025

  29. [37]

    Bauth-zkp—a blockchain-based multi-factor authentication mechanism for securing smart cities,

    M. O. Ahmad, G. Tripathi, F. Siddiqui, M. A. Alam, M. A. Ahad, M. M. Akhtar, and G. Casalino, “Bauth-zkp—a blockchain-based multi-factor authentication mechanism for securing smart cities,” Sensors, vol. 23, no. 5, p. 2757, 2023

    2023

  30. [38]

    Cwe-306: Missing authentication for critical function,

    “Cwe-306: Missing authentication for critical function,” https://cwe. mitre.org/data/definitions/306.html, 2024, accessed: 2025-05-06

    2024

  31. [39]

    A systematic study of the consistency of two-factor authentication user journeys on top-ranked websites,

    S. Ghorbani Lyastani, S. Bugiel, and M. Backes, “A systematic study of the consistency of two-factor authentication user journeys on top-ranked websites,” 2023

    2023

  32. [40]

    Cve-2023-4456: Lokistack token cache scope vulnerability,

    “Cve-2023-4456: Lokistack token cache scope vulnerability,” https: //www.cve.org/CVERecord?id=CVE-2023-4456, 2023, accessed: 2025- 05-06

    2023

  33. [41]

    Robust biometric scheme against replay attacks using one-time biometric templates,

    T. Gernot and C. Rosenberger, “Robust biometric scheme against replay attacks using one-time biometric templates,” Computers & Security, vol. 137, p. 103586, 2024

    2024

  34. [42]

    Stateful least privilege authorization for the cloud,

    L. Cao, L. Meng, D. Stefan, and E. Fernandes, “Stateful least privilege authorization for the cloud,” in 33rd USENIX Security Symposium (USENIX Security 24) , 2024, pp. 3477–3494

    2024

  35. [43]

    Authenticated delegation and autho- rized ai agents,

    T. South, S. Marro, T. Hardjono, R. Mahari, C. D. Whitney, D. Green- wood, A. Chan, and A. Pentland, “Authenticated delegation and autho- rized ai agents,” arXiv preprint arXiv:2501.09674 , 2025

    2025 arXiv

  36. [44]

    Cwe-1220: Insufficient granularity of access control,

    “Cwe-1220: Insufficient granularity of access control,” https://cwe.mitre. org/data/definitions/1220.html, 2024, accessed: 2025-05-06

    2024

  37. [45]

    A zero trust single sign-on framework with attribute-based access control,

    D. Kaltenb ¨ock, I. Murturi, and S. Dustdar, “A zero trust single sign-on framework with attribute-based access control,” in 2024 26th Interna- tional Conference on Business Informatics (CBI) . IEEE, 2024, pp. 149–157

    2024

  38. [46]

    Cve-2024-44131: Tcc bypass vulnerability in macos/ios fileprovider,

    “Cve-2024-44131: Tcc bypass vulnerability in macos/ios fileprovider,” https://www.cve.org/CVERecord?id=CVE-2024-44131, 2024, accessed: 2025-05-06

    2024

  39. [47]

    Everybody’s looking for ssomething: A large-scale evaluation on the privacy of oauth authenti- cation on the web,

    Y . Dimova, T. Van Goethem, and W. Joosen, “Everybody’s looking for ssomething: A large-scale evaluation on the privacy of oauth authenti- cation on the web,” Proceedings on Privacy Enhancing Technologies , 2023

    2023

  40. [48]

    A smart contract- based dynamic consent management system for personal data usage under gdpr,

    M. M. Merlec, Y . K. Lee, S.-P. Hong, and H. P. In, “A smart contract- based dynamic consent management system for personal data usage under gdpr,” Sensors, vol. 21, no. 23, p. 7994, 2021

    2021

  41. [49]

    M. I. Khalid, M. Ahmed, and J. Kim, “Enhancing data protection in dynamic consent management systems: formalizing privacy and security definitions with differential privacy, decentralization, and zero- knowledge proofs,” Sensors, vol. 23, no. 17, p. 7604, 2023

    2023

  42. [50]

    Cwe-200: Exposure of sensitive information to an unauthorized actor,

    “Cwe-200: Exposure of sensitive information to an unauthorized actor,” https://cwe.mitre.org/data/definitions/200.html, 2024, accessed: 2025- 05-06

    2024

  43. [51]

    Privacy for iot: informed consent management in smart buildings,

    C. Pathmabandu, J. Grundy, M. B. Chhetri, and Z. Baig, “Privacy for iot: informed consent management in smart buildings,” Future Generation Computer Systems, vol. 145, pp. 367–383, 2023

    2023

  44. [52]

    Cve-2023-41745: Excessive system data collection in acronis agent,

    “Cve-2023-41745: Excessive system data collection in acronis agent,” https://www.cve.org/CVERecord?id=CVE-2023-41745, 2023, accessed: 2025-05-06

    2023

  45. [53]

    Safeguard privacy for mini- mal data collection with trustworthy autonomous agents,

    M. Xu, L. A. Dennis, and M. A. Mustafa, “Safeguard privacy for mini- mal data collection with trustworthy autonomous agents,” in AAMAS’24: Proceedings of the 23rd International Conference on Autonomous Agents and Multiagent Systems . International Foundation for Autonomous Age...

    2024

  46. [54]

    Open challenges in multi-agent security: Towards secure systems of interacting ai agents,

    C. S. de Witt, “Open challenges in multi-agent security: Towards secure systems of interacting ai agents,” arXiv preprint arXiv:2505.02077 , 2025

    2025 arXiv

  47. [55]

    Cve-2024-7042: Langchain prompt injection in graphcypherqachain,

    “Cve-2024-7042: Langchain prompt injection in graphcypherqachain,” https://www.cve.org/CVERecord?id=CVE-2024-7042, 2024, accessed: 2025-05-06

    2024

  48. [56]

    Cve-2022-45449: Over-privileged access control in acronis cyber pro- tect,

    “Cve-2022-45449: Over-privileged access control in acronis cyber pro- tect,” https://www.cve.org/CVERecord?id=CVE-2022-45449, 2022, ac- cessed: 2025-05-06

    2022

  49. [57]

    Mcp security exposed: What you need to know now,

    xzou, “Mcp security exposed: What you need to know now,” Apr 2025. [Online]. Available: https://live.paloaltonetworks.com/t5/community-blogs/mcp- security-exposed-what-you-need-to-know-now/ba-p/1227143

    2025

  50. [58]

    Role of authentication factors in fin-tech mobile transaction security,

    H. U. Khan, M. Sohail, S. Nazir, T. Hussain, B. Shah, and F. Ali, “Role of authentication factors in fin-tech mobile transaction security,” Journal of Big Data , vol. 10, no. 1, p. 138, 2023

    2023

  51. [59]

    Cve-2024-45989: Prompt injection exposing chat data in monica ai,

    “Cve-2024-45989: Prompt injection exposing chat data in monica ai,” https://www.cve.org/CVERecord?id=CVE-2024-45989, 2024, accessed: 2025-05-06

    2024

  52. [60]

    Secure internet financial transactions: A framework integrating multi-factor authentication and machine learning,

    A. M. Aburbeian and M. Fern ´andez-Veiga, “Secure internet financial transactions: A framework integrating multi-factor authentication and machine learning,” AI, vol. 5, no. 1, pp. 177–194, 2024

    2024

  53. [61]

    A secure and efficient multi- factor authentication algorithm for mobile money applications,

    G. Ali, M. A. Dida, and A. Elikana Sam, “A secure and efficient multi- factor authentication algorithm for mobile money applications,” Future Internet, vol. 13, no. 12, p. 299, 2021

    2021

  54. [62]

    A systematic review of multi-factor authentication in digital payment systems: Nist standards alignment and industry implementation analysis,

    P. T. Tran-Truong, M. Q. Pham, H. X. Son, D. L. Nguyen, M. B. Nguyen, K. L. Tran, L. C. Van, K. T. Le, K. H. V o, N. N. Kimet al., “A systematic review of multi-factor authentication in digital payment systems: Nist standards alignment and industry implementation analysis,” Jo...

    2025

  55. [63]

    Compliance of ai systems,

    J. Sch ¨oning and N. Kruse, “Compliance of ai systems,” arXiv preprint arXiv:2503.05571, 2025

    2025 arXiv

  56. [64]

    Ignore previous prompt: Attack techniques for language models,

    F. Perez and I. Ribeiro, “Ignore previous prompt: Attack techniques for language models,” arXiv preprint arXiv:2211.09527 , 2022

    2022 arXiv

  57. [65]

    Leveraging artificial intelligence for enhancing reg- ulatory compliance in the financial sector,

    A. Balakrishnan, “Leveraging artificial intelligence for enhancing reg- ulatory compliance in the financial sector,” International Journal of Computer Trends and Technology, 2024

    2024

  58. [68]

    What is a prompt injection attack? [examples & preven- tion],

    “What is a prompt injection attack? [examples & preven- tion],” https://www.paloaltonetworks.com/cyberpedia/what-is-a-prompt- injection-attack. [Online]. Available: https://www.paloaltonetworks.com/ cyberpedia/what-is-a-prompt-injection-attack

  59. [2012]

    Available: https://www.rfc-editor.org/info/rfc6749

    [Online]. Available: https://www.rfc-editor.org/info/rfc6749

  60. [2025]

    Available: https://developers.googleblog.com/en/a2a-a- new-era-of-agent-interoperability/

    [Online]. Available: https://developers.googleblog.com/en/a2a-a- new-era-of-agent-interoperability/

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.