Pith. sign in

REVIEW 4 major objections 4 minor 31 references

A build-time pipeline for agentic apps claims to eliminate prompt-injection data leaks from basic attacks and cut stress-induced leaks by 91%, all without runtime policy enforcement.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

T0 review · deepseek-v4-flash

2026-08-01 14:07 UTC pith:RFLUO4JF

load-bearing objection A real pipeline with a plausible design, but the headline ASR reductions are undercut by a self-referential evaluation loop; AgentDojo supplies partial independent support. the 4 major comments →

arxiv 2607.18847 v1 pith:RFLUO4JF submitted 2026-07-21 cs.CR cs.AI

Data Leakage Prevention in Agentic Applications via Preemptive Hardening

Akansha Shukla , Emily Bellov , Parth Atulbhai Gandhi , Yuval Elovici , Asaf Shabtai This is my paper
classification cs.CR cs.AI
keywords data leakage preventionprompt injectionagentic applicationsbuild-time hardeningmulti-agent systemssource code analysisadversarial validation
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

This paper argues that data leakage in multi-agent LLM applications is largely a build-time engineering problem, not something that can be left to runtime monitoring. It presents a pre-deployment pipeline that scans source code (prompt templates, tool interfaces, tool invocations), identifies leakage-enabling patterns, applies minimally invasive patches at the highest-risk source-to-sink paths, and then validates the hardened app against adaptive adversarial and benign inputs. The central claim is that these source-level modifications eliminate leakage from basic jailbreak and instruction-override attacks (reported 100% reduction) and reduce stress-induced leakage by 91%, while preserving intended functionality. The paper positions this build-time hardening as complementary to runtime information-flow control, not a replacement.

Core claim

The paper's central discovery is that recurring, code-level weaknesses—unsafe input/output handling, missing allowlists, over-privileged tools, weak validation—account for most feasible leakage paths in agentic systems, and that these paths can be systematically enumerated and patched before deployment. The pipeline formalizes leakage as a source-to-sink path with sensitivity labels propagating through data-flow nodes, and uses an LLM-empowered analyzer to find paths structural analysis alone cannot see. Hardening transformations are targeted and local: prompts are rewritten to separate data from instructions, sensitive context is stripped at boundary crossings, roles are separated with type

What carries the argument

The load-bearing object is the leakage-path model: a sequence from a sensitive source through data-flow nodes to an output sink, where each node carries a sensitivity label that propagates structurally. The pipeline's three modules operate on this model: the Analyzer uses AST parsing plus LLM chain-of-thought reasoning to enumerate paths and rank them by severity, exposure, and sensitivity; the Modifier applies localized transformations at the highest-risk boundary crossings; the Validator executes the hardened app under adversarial and benign inputs, detecting leaks at monitored sinks and feeding results back for iterative hardening.

Load-bearing premise

The pipeline can only harden the leakage paths its analyzer actually finds, and the analyzer's 'complete enumeration' rests on an LLM's semantic reasoning as much as on static code analysis.

What would settle it

Run the pipeline on an agentic application that hides a sensitive-data exfiltration sink behind dynamic tool registration or a non-standard framework pattern, then mount a crafted prompt injection; if the hardened app still leaks data on a path the analyzer missed, the enumeration claim is falsified.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • Prompt-injection leakage in agentic systems can be reduced substantially before deployment, without continuous runtime policy enforcement.
  • Automated, minimally invasive patches can be generated and applied without disrupting the intended behavior of the application.
  • Validation that replays previously successful attacks and adapts new ones provides a regression-style security check for hardened agents.
  • The approach transfers to standardized tool-calling benchmarks, improving utility under attack while maintaining a net security gain.
  • Recurring leakage-enabling patterns can be identified across different agent frameworks, suggesting the value of shared hardening blueprints.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • If build-time hardening is as effective as reported, security review of agentic applications could shift left into CI/CD, catching data-flow flaws before deployment and reducing reliance on reactive runtime controls.
  • The residual stress-induced leakage suggests a division of labor: build-time hardening for known classes, runtime IFC or monitoring for the long tail. A combined defense might close the remaining gap.
  • Because the validator's attack generator is conditioned on the analyzer's audit report, validation strength is bounded by the generator's capability; deploying a stronger or more diverse red-team generator might expose additional paths the current pipeline misses.
  • The approach's completeness rests on the analyzer's LLM-based path enumeration, so systematic evaluation of enumeration coverage across a wider range of agent frameworks would be a natural next test.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 4 minor

Summary. The paper proposes a pre-deployment pipeline for agentic applications that (1) statically analyzes source code to identify leakage paths, (2) applies targeted source-level hardening (prompt rewriting, context minimization, role separation, capability boundaries, and outbound-request transformation), and (3) validates the hardened application through automatically generated benign and adversarial inputs. The central claim is that this build-time approach reduces leakage by 100% on four of five testbed applications and by 91% on the fifth, while preserving benign utility, and that it improves utility-under-attack on AgentDojo relative to the benchmark's default defense.

Significance. If the reported results are trustworthy, the paper would make a useful contribution: it addresses a real gap in build-time hardening for multi-agent LLM systems, and its pipeline is described in enough detail to be a starting point for practical tooling. The main strengths are the clear three-stage architecture (analyzer/modifier/validator), the explicit threat model, the inclusion of an ablation study (Table I), and the use of AgentDojo's official state-based checkers for the benchmark experiments. However, the headline 100%/91% leakage-reduction numbers rest on an in-house evaluation loop whose adversarial input generator is conditioned on the exact paths and sinks found by the analyzer and whose leakage detector is application-specific code written by the authors. The evaluator is therefore partially circular: low ASR can reflect agreement among components of the same pipeline rather than resistance to independent adversaries. The work is significant if the pipeline can be validated under more independent conditions, but the current evidence does not justify the strength of the claims.

major comments (4)
  1. [Section III-F, Fig. 2, Table II] The central evaluation loop is self-referential. The input generator is explicitly 'conditioned on the ranked audit report' and receives 'leakage instructions that define the leakage objective, namely the sensitive source s being targeted and the intended exfiltration sink σ†'. Thus the attacking LLM is told exactly which source-to-sink path to target—the same paths the analyzer reported and the modifier patched. The leakage detector is also 'application-specific logic' written by the authors, so the judgment of whether leakage occurred is not independently audited. Under this design, the reported 100% and 91% ASR reductions largely measure the consistency of the authors' pipeline, not how a real adversary would fare. The paper should re-run validation with an independent red-team generator that is not given the audit report, and with an independently specified leakage detector (e.g., a
  2. [Section III-D, 'Inspect Tool Sink'] The analyzer's claim to 'enumerate all leakage paths' is load-bearing but unsupported. Path enumeration is performed by 'an LLM prompted with CoT reasoning' over a structured code representation, and no completeness guarantee or recall measure is given. Because the validation module only attacks paths that appear in the audit report, any true leakage path missed by the analyzer is never generated as an attack, never patched, and never measured. A missed path therefore contributes silently to the reported '100% reduction.' The authors should establish a ground-truth path set via a deterministic taint-tracking baseline or a substantial manual audit, then report what fraction of ground-truth paths the analyzer discovered. Without such a recall measure, 'enumerate all' is not justified and the security claims should be weakened accordingly.
  3. [Section IV-A, 'Case-study applications', Table II] The external validity of the five-application testbed is limited. Three of the five applications were built by the authors, and the two ATAG applications share at least four authors with this paper. The attack scenarios for these applications are also drawn from the same research group's prior work. While the AgentDojo experiments partially mitigate this concern, the headline 100%/91% reductions are measured only on this author-controlled set. The paper should either evaluate on third-party, independently maintained agent applications, or clearly re-scope the claims as a controlled demonstration rather than 'real-world' validation. At minimum, the authors should disclose the exact overlap and provide an independent application as a sanity check.
  4. [Section V-B, Table III] The AgentDojo results do not support the strength of the generalization claim. The only independent benchmark shows a security regression on Slack (security 100.0% → 80.0%, Δ = −20.0 pp), and the overall security gain is modest (Δ = +7.4 pp). No confidence intervals, repeated-seed variance, or per-suite statistical tests are reported, and only one attack type (important_instructions) is considered. The paper should report repeated runs with variance, discuss the Slack regression explicitly, and avoid the phrase 'net security gain' without a defined acceptable trade-off between utility and security. As currently presented, the benchmark evidence is too thin to support the claim that the pipeline generalizes while preserving security.
minor comments (4)
  1. [Section III-F, 'Validation Criteria and Termination'] The choice of Kmax = 10, Natt = 4, and r repeats is described, but there is no sensitivity analysis. Since these parameters directly bound the measured ASR, the paper should at least discuss how the results would change if the attack budget were increased.
  2. [Section V-A, 'Network Monitoring'] The sentence describing the residual ASR ('aggregated over all four classes, the application’s leakage falls from 81.9% to 7.4%') sums the pre-hardening row of Table II. It is worth clarifying that the pre-hardening ASR is the sum of non-overlapping class rates; otherwise the number may be misread as a per-class maximum.
  3. [General] The paper would benefit from including a data/code availability statement. The pipeline is described in detail, but no repository or artifact link is provided, which makes reproducibility and independent evaluation difficult.
  4. [Section II, Related Work] The comparison with FIDES in Section V-C is described as 'not a challenge to FIDES’s contribution,' but the table is still presented as a competitive comparison. A brief sentence clarifying the different goals (build-time vs. runtime, and the fact that FIDES is modified in the comparison) should be added near the table.

Circularity Check

2 steps flagged

In-house validation is partially circular: attacks are generated from the analyzer's own audit report and scored by author-defined detectors, and the hardening loop iterates until those attacks fail; the headline 100%/91% ASR reductions are therefore not an independent test of the pipeline.

specific steps
  1. self definitional [Section III-D (Analyzer Module) & III-F (Input Generation / Leakage Detection)]
    "All leakage paths ⟨s, v1, . . . , vk, σ⟩ are enumerated by submitting the structured code representation ... to an LLM prompted with CoT reasoning; "It is also conditioned on the ranked audit report, so that generated attacks focus on the currently targeted leakage path ℓ (equivalently, its ranked finding and sink σ)"; "The leakage detector ... receives an observation o at a sink σ ... and returns whether o discloses the source s, equivalently whether λ(o)≠0 on the targeted sensitivity categories.""

    The validation's adversarial input generator is conditioned on the ranked audit report and leakage instructions, so it only attacks paths the analyzer already found; the leakage detector only recognizes the pre-specified source-sink pair. Thus the tested set and the leakage criterion are exactly the analyzer's own outputs. If the LLM-based enumeration misses a path (no completeness proof is given), that path is never attacked and never detected, so 'ASR' is a consistency check of the analyzer/validator pair, not an independent measurement of all leakage. The claimed elimination of leaks therefore reduces to 'all analyzer-enumerated paths were patched and attacks against those same paths failed.'

  2. fitted input called prediction [Section III-F (Validation Criteria and Termination) & V-A (Leakage Reduction)]
    "The outer hardening loop terminates when a cycle produces no successful attacks against any path and no benign regressions, or after a maximum of Kmax cycles; "After hardening, ASR falls to 0% across all four classes for every CrewAI application ... a 100% reduction in realized leakage.""

    The pipeline actively fits the hardened application to the validation corpus: the modifier receives feedback on successful attacks and patches until no attack succeeds (up to Kmax). The reported 0% ASR on jailbreak/instruction-override is therefore a fixed point of the same loop, not a held-out prediction. Attacks are also mutated using prior success/failure history, so the same attempts that select the patches are reused to report the final reduction. The remaining 7.4% stress ASR is simply the residual after the iteration budget was exhausted, confirming that the headline 100% number is a termination artifact as much as a security result.

full rationale

The central contribution is an engineering pipeline rather than a formal derivation, so most of the paper is not circular in a mathematical sense. However, the headline security numbers rest on a validation loop that is partially self-referential. Section III-D defines the leakage-path set L by LLM-based enumeration with no completeness guarantee; the validation module then generates attacks conditioned on that same audit report and scores leakage with an application-specific detector implementing the same source-sink objective from the leakage instructions. Consequently, an attack on a path not in L is never generated, and a disclosure not matching the pre-specified source is never counted; the final ASR is partly a measure of agreement between the analyzer and the validator. Additionally, the outer loop iteratively patches until 'no successful attacks against any path' (Kmax=10), so the 100% reduction on jailbreak/instruction-override classes is partly a termination condition rather than an out-of-sample result. The AgentDojo track uses external state-based checkers and a benchmark attack, which provides an independent anchor and prevents a higher score; the ATAG self-citation supplies testbed applications but is not load-bearing for the main claim. The paper also honestly admits residual stress-induced leakage and schema-preserving tampering. Overall: partial circularity in the in-house validation of the headline numbers, but not an entirely definitional derivation.

Axiom & Free-Parameter Ledger

4 free parameters · 4 axioms · 0 invented entities

The central security claim rests on the completeness of LLM-based path enumeration, the correctness of author-defined leakage detectors, and the representativeness of generated attacks. No new physical entities are introduced; the only free parameters are hand-chosen attack/iteration budgets.

free parameters (4)
  • Kmax (outer hardening iterations) = 10
    Hand-set budget for the outer hardening loop (Section IV-A.b); reported ASR could improve with more iterations and is not a fitted optimum.
  • Natt (adaptive attack attempts per category per path) = 4
    Attack budget per category per outer iteration (Section IV-A.b); larger budgets would likely find more successful attacks.
  • r (execution repeats per attack attempt) = not reported
    Each attack is run r times and success is recorded if leakage is detected in at least one run (Section III-F), but r is never specified, making the stochastic ASR hard to interpret.
  • Risk tiers high/medium/low = discrete categories
    Hand-chosen ranking granularity in the analyzer; determines which paths are patched and could change outcomes.
axioms (4)
  • domain assumption The LLM-based analyzer enumerates all leakage paths L and assigns true sensitivity labels λ(v) to each node.
    Section III-D 'Inspect Tool Sink' claims all paths are enumerated by an LLM with chain-of-thought; no completeness or correctness proof is given.
  • domain assumption The application-specific leakage detector's detect() correctly recognizes disclosure of the targeted sensitive source.
    Section III-F says the detector 'implements application-specific logic' written by the evaluators; for the testbeds there is no external ground-truth oracle.
  • domain assumption The LLM-based input generator produces adversarial inputs representative of real attackers.
    The generator is conditioned on the ranked audit report and leakage instructions (Section III-F), so it is not independent of the defense and may not cover real-world attack diversity.
  • domain assumption Static AST parsing recovers the complete agent topology (G,E), tool registries, and memory access patterns for CrewAI and LangGraph applications.
    Section III-D 'Agent Discovery' relies on framework-specific pattern matching; dynamic tool registration or obfuscated bindings could be missed.

pith-pipeline@v1.3.0-alltime-deepseek · 16403 in / 11100 out tokens · 92902 ms · 2026-08-01T14:07:36.525002+00:00 · methodology

0 comments
read the original abstract

Agentic systems integrate LLM driven planning with interfaces to external tools, making data leakage and tool misuse feasible via instruction/data boundary failures and prompt injection attacks. Enforcing required controls consistently is particularly challenging in workflows spanning many codebases and heterogeneous agents. To address this challenge in multi agentic systems, we present a pre-deployment pipeline for scanning, hardening, and validation of agentic applications. The pipeline analyzes prompt templates, tool interfaces, and tool-invocation code to identify leakage-enabling patterns and generate actionable patches. The hardened application is then validated through adversarial prompt injection attacks and benign input variations ensuring that mitigations do not disrupt intended behavior. In the hardening stage, high-risk tools are prioritized, and minimally invasive mitigations are applied, including schema tightening, boundary sanitization, allowlist-based tool gating, and least-privilege checks. In the validation stage, the pipeline automatically generates attack inputs that mimic jailbreaks, instruction overrides, and tool-targeted manipulation, along with benign task variants, to confirm that the functionality of the hardened application is preserved after remediation. We evaluated the pipeline on five real-world agentic applications, as well as on the AgentDojo benchmark. Across all applications, the proposed pipeline identified recurring leakage-enabling patterns and generated patches that can be integrated without disrupting the intended application behavior. The resulting modifications of application code were shown to eliminate leaks when targeted by basic jailbreak and instruction-override attacks, achieving a 100% reduction in leakage, and reduce leaks by 91% under conditions of stress-induced manipulation, without the need of continuous runtime policy enforcement.

Figures

Figures reproduced from arXiv: 2607.18847 by Akansha Shukla, Asaf Shabtai, Emily Bellov, Parth Atulbhai Gandhi, Yuval Elovici.

Figure 1
Figure 1. Figure 1: Overview of the preemptive hardening pipeline for data leakage prevention in AI-agent applications. The analyzer module (left) discovers agents, maps [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Validation module overview. a validation cycle, the orchestrator first retries the successful attack attempts from previous cycles. This regression-style check verifies that the latest hardened application blocks attacks that were already known to realize a path. The orchestrator then invokes the input generator to produce new attacks against the currently targeted path ℓ. For each attack category, the orc… view at source ↗
Figure 3
Figure 3. Figure 3: Overview of the O-RAN monitoring assistant application. [PITH_FULL_IMAGE:figures/full_fig_p009_3.png] view at source ↗
Figure 5
Figure 5. Figure 5: Overview of the automated trip planner application. [PITH_FULL_IMAGE:figures/full_fig_p009_5.png] view at source ↗
Figure 4
Figure 4. Figure 4: Overview of the HR assistant application. [PITH_FULL_IMAGE:figures/full_fig_p009_4.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

31 extracted references · 19 linked inside Pith

  1. [1]

    Langchain: Build ai apps with llms through composability,

    LangChain, “Langchain: Build ai apps with llms through composability,” 2024, accessed: 2025-05-14. [Online]. Available: https://github.com/langchain-ai/langchain

    2024

  2. [2]

    Langgraph: Building language agents as graphs,

    “Langgraph: Building language agents as graphs,” 2024, accessed: 2025- 05-14. [Online]. Available: https://github.com/langchain-ai/langgraph

    2024

  3. [3]

    Autogen: Enabling next-gen llm applications via multi-agent conversation,

    Q. Wu, G. Bansal, J. Zhang, Y . Wu, B. Li, E. Zhu, L. Jiang, X. Zhang, S. Zhang, J. Liu, A. H. Awadallah, R. W. White, D. Burger, and C. Wang, “Autogen: Enabling next-gen llm applications via multi-agent conversation,” 2023. [Online]. Available: https://arxiv.org/abs/2308.08155

    Pith/arXiv arXiv 2023

  4. [4]

    crewai: Cutting-edge framework for orchestrating role-playing, autonomous ai agents,

    crewAI, “crewai: Cutting-edge framework for orchestrating role-playing, autonomous ai agents,” 2024, accessed: 2025-05-14. [Online]. Available: https://github.com/crewAIInc/crewAI

    2024

  5. [5]

    Not what you’ve signed up for: Compromising real-world llm-integrated applications with indirect prompt injection,

    K. Greshake, S. Abdelnabi, S. Mishra, C. Endres, T. Holz, and M. Fritz, “Not what you’ve signed up for: Compromising real-world llm-integrated applications with indirect prompt injection,” 2023. [Online]. Available: https://arxiv.org/abs/2302.12173

    Pith/arXiv arXiv 2023

  6. [6]

    Identifying the risks of lm agents with an lm-emulated sandbox,

    Y . Ruan, H. Dong, A. Wang, S. Pitis, Y . Zhou, J. Ba, Y . Dubois, C. J. Maddison, and T. Hashimoto, “Identifying the risks of lm agents with an lm-emulated sandbox,” 2024. [Online]. Available: https://arxiv.org/abs/2309.15817

    Pith/arXiv arXiv 2024

  7. [7]

    A survey on the safety and security threats of computer-using agents: Jarvis or ultron?

    A. Chen, Y . Wu, J. Zhang, J. Xiao, S. Yang, J. tse Huang, K. Wang, W. Wang, and S. Wang, “A survey on the safety and security threats of computer-using agents: Jarvis or ultron?” 2025. [Online]. Available: https://arxiv.org/abs/2505.10924

    Pith/arXiv arXiv 2025

  8. [8]

    Malicious agent skills in the wild: A large-scale security empirical study,

    Y . Liu, Z. Chen, Y . Zhang, G. Deng, Y . Li, J. Ning, and L. Y . Zhang, “Malicious agent skills in the wild: A large-scale security empirical study,” 2026. [Online]. Available: https://arxiv.org/abs/2602.06547

    Pith/arXiv arXiv 2026

  9. [9]

    Fault-tolerant sandboxing for ai coding agents: A transactional approach to safe autonomous execution,

    B. Yan, “Fault-tolerant sandboxing for ai coding agents: A transactional approach to safe autonomous execution,” 2025. [Online]. Available: https://arxiv.org/abs/2512.12806

    arXiv 2025

  10. [10]

    Proactive defense against llm jailbreak,

    W. Zhao, J. Peng, D. Ben-Levi, Z. Yu, and J. Yang, “Proactive defense against llm jailbreak,” 2025. [Online]. Available: https://arxiv.org/abs/2510.05052

    arXiv 2025

  11. [11]

    Defending against prompt injection with a few defensivetokens,

    S. Chen, Y . Wang, N. Carlini, C. Sitawarin, and D. Wagner, “Defending against prompt injection with a few defensivetokens,” 2025. [Online]. Available: https://arxiv.org/abs/2507.07974

    Pith/arXiv arXiv 2025

  12. [12]

    Defense against prompt injection attack by leveraging attack techniques,

    Y . Chen, H. Li, Z. Zheng, Y . Song, D. Wu, and B. Hooi, “Defense against prompt injection attack by leveraging attack techniques,” 2025. [Online]. Available: https://arxiv.org/abs/2411.00459

    Pith/arXiv arXiv 2025

  13. [13]

    Struq: Defending against prompt injection with structured queries,

    S. Chen, J. Piet, C. Sitawarin, and D. Wagner, “Struq: Defending against prompt injection with structured queries,” 2024. [Online]. Available: https://arxiv.org/abs/2402.06363

    Pith/arXiv arXiv 2024

  14. [14]

    Promptshield: Deployable detection for prompt injection attacks,

    D. Jacob, H. Alzahrani, Z. Hu, B. Alomair, and D. Wagner, “Promptshield: Deployable detection for prompt injection attacks,” 2025. [Online]. Available: https://arxiv.org/abs/2501.15145

    Pith/arXiv arXiv 2025

  15. [15]

    Fine-tuned deberta-v3 for prompt injection detection,

    ProtectAI.com, “Fine-tuned deberta-v3 for prompt injection detection,”

  16. [16]

    Llamafirewall: An open source guardrail system for building secure ai agents,

    S. Chennabasappa, C. Nikolaidis, D. Song, D. Molnar, S. Ding, S. Wan, S. Whitman, L. Deason, N. Doucette, A. Montilla, A. Gampa, B. de Paola, D. Gabi, J. Crnkovich, J.-C. Testud, K. He, R. Chaturvedi, W. Zhou, and J. Saxe, “Llamafirewall: An open source guardrail system for building secure ai agents,” 2025. [Online]. Available: https://arxiv.org/abs/2505.03574

    Pith/arXiv arXiv 2025

  17. [17]

    Securing ai agents with information-flow control,

    M. Costa, B. Köpf, A. Kolluri, A. Paverd, M. Russinovich, A. Salem, S. Tople, L. Wutschitz, and S. Zanella-Béguelin, “Securing ai agents with information-flow control,” 2025. [Online]. Available: https://arxiv.org/abs/2505.23643

    Pith/arXiv arXiv 2025

  18. [18]

    Prompt flow integrity to prevent privilege escalation in llm agents,

    J. Kim, W. Choi, and B. Lee, “Prompt flow integrity to prevent privilege escalation in llm agents,” 2025. [Online]. Available: https://arxiv.org/abs/2503.15547

    Pith/arXiv arXiv 2025

  19. [19]

    Permissive information-flow analysis for large language models,

    S. A. Siddiqui, R. Gaonkar, B. Köpf, D. Krueger, A. Paverd, A. Salem, S. Tople, L. Wutschitz, M. Xia, and S. Zanella-Béguelin, “Permissive information-flow analysis for large language models,” 2025. [Online]. Available: https://arxiv.org/abs/2410.03055

    arXiv 2025

  20. [20]

    Rtbas: Defending llm agents against prompt injection and privacy leakage,

    P. Y . Zhong, S. Chen, R. Wang, M. McCall, B. L. Titzer, H. Miller, and P. B. Gibbons, “Rtbas: Defending llm agents against prompt injection and privacy leakage,” 2025. [Online]. Available: https://arxiv.org/abs/2502.08966

    Pith/arXiv arXiv 2025

  21. [21]

    Agrail: A lifelong agent guardrail with effective and adaptive safety detection,

    W. Luo, S. Dai, X. Liu, S. Banerjee, H. Sun, M. Chen, and C. Xiao, “Agrail: A lifelong agent guardrail with effective and adaptive safety detection,” 2025. [Online]. Available: https://arxiv.org/abs/2502.11448

    Pith/arXiv arXiv 2025

  22. [22]

    Progent: Programmable privilege control for llm agents,

    T. Shi, J. He, Z. Wang, H. Li, L. Wu, W. Guo, and D. Song, “Progent: Programmable privilege control for llm agents,” 2025. [Online]. Available: https://arxiv.org/abs/2504.11703

    Pith/arXiv arXiv 2025

  23. [23]

    Defeating prompt injections by design,

    E. Debenedetti, I. Shumailov, T. Fan, J. Hayes, N. Carlini, D. Fabian, C. Kern, C. Shi, A. Terzis, and F. Tramèr, “Defeating prompt injections by design,” 2025. [Online]. Available: https://arxiv.org/abs/2503.18813

    Pith/arXiv arXiv 2025

  24. [24]

    Isolategpt: An execution isolation architecture for llm-based agentic systems,

    Y . Wu, F. Roesner, T. Kohno, N. Zhang, and U. Iqbal, “Isolategpt: An execution isolation architecture for llm-based agentic systems,” 2025. [Online]. Available: https://arxiv.org/abs/2403.04960

    Pith/arXiv arXiv 2025

  25. [25]

    The sum leaks more than its parts: Compositional privacy risks and mitigations in multi-agent collaboration,

    V . Patil, E. Stengel-Eskin, and M. Bansal, “The sum leaks more than its parts: Compositional privacy risks and mitigations in multi-agent collaboration,” 2025. [Online]. Available: https://arxiv.org/abs/2509.14284

    arXiv 2025

  26. [26]

    The trust paradox in llm-based multi-agent systems: When collaboration becomes a security vulnerabili ty,

    Z. Xu, M. Qi, S. Wu, L. Zhang, Q. Wei, H. He, and N. Li, “The trust paradox in llm-based multi-agent systems: When collaboration becomes a security vulnerabili ty,” 2025. [Online]. Available: https://arxiv.org/abs/2510.18563

    arXiv 2025

  27. [27]

    Breaking and fixing defenses against control-flow hijacking in multi-agent systems,

    R. Jha, H. Triedman, J. Wagle, and V . Shmatikov, “Breaking and fixing defenses against control-flow hijacking in multi-agent systems,” 2025. [Online]. Available: https://arxiv.org/abs/2510.17276

    arXiv 2025

  28. [28]

    Safeflow: A principled protocol for trustworthy and transactional autonomous agent systems,

    P. Li, X. Zou, Z. Wu, R. Li, S. Xing, H. Zheng, Z. Hu, Y . Wang, H. Li, Q. Yuan, Y . Zhang, and Z. Tu, “Safeflow: A principled protocol for trustworthy and transactional autonomous agent systems,” 2025. [Online]. Available: https://arxiv.org/abs/2506.07564

    Pith/arXiv arXiv 2025

  29. [29]

    Atag: Ai-agent application threat assessment with attack graphs,

    P. A. Gandhi, A. Shukla, D. Tayouri, B. Ifland, Y . Elovici, R. Puzis, and A. Shabtai, “Atag: Ai-agent application threat assessment with attack graphs,” 2025. [Online]. Available: https://arxiv.org/abs/2506.02859

    Pith/arXiv arXiv 2025

  30. [30]

    Under- standing o-ran: Architecture, interfaces, algorithms, security, and research challenges,

    M. Polese, L. Bonati, S. D’Oro, S. Basagni, and T. Melodia, “Under- standing o-ran: Architecture, interfaces, algorithms, security, and research challenges,”IEEE Communications Surveys & Tutorials, vol. 25, no. 2, pp. 1376–1411, 2023

    2023

  31. [2023]

    Available: https://huggingface.co/ProtectAI/deberta-v3- base-prompt-injection

    [Online]. Available: https://huggingface.co/ProtectAI/deberta-v3- base-prompt-injection