Pith. sign in

REVIEW 2 major objections 4 minor 15 references

An LLM agent with valid HPC credentials can be hijacked by content it reads during ordinary work—logs, files, tool descriptions, or peer messages—and act outside its assigned task while every command remains permitted.

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 15:15 UTC pith:RODCD6L2

load-bearing objection A well-scoped position paper that names a real HPC-agent threat model and organizes the attack surface, but the title oversells 'benchmarking' and the central transferability claim is untested — worth a serious referee as a vision paper, not as a benchmark. the 2 major comments →

arxiv 2607.18485 v1 pith:RODCD6L2 submitted 2026-07-20 cs.CR cs.AI

Trusted Credentials, Untrusted Behavior: Benchmarking LLM-Agent Security in High-Performance Computing

Jie Li This is my paper
classification cs.CR cs.AI
keywords LLM agentsHPC securityprompt injectionhijacked authorized agenttask intentattack surfacesscheduler securityagent benchmark
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 LLM agents in high-performance computing create a failure mode that ordinary security controls do not cover. An agent that holds a user's valid credentials can be redirected by instructions buried in job logs, shared files, tool descriptions, or messages from another agent, so that every command it runs is permitted for the account while the sequence serves an attacker rather than the assigned task. The authors call this the 'hijacked authorized agent' problem. They show that HPC identity, access control, accounting, and isolation all verify what an account may do, not what a delegated task was meant to do, so none of them can detect the redirection. The paper's contribution is the threat model, a taxonomy of HPC-specific attack surfaces, and a planned benchmark, TaskBound, to measure how often agents complete tasks while withstanding injected instructions.

Core claim

The paper's central claim is that an authenticated LLM agent in an HPC environment can be 'hijacked' when content encountered during normal operation—such as a job log, a shared file, a tool description, or a peer-agent message—causes it to act outside its assigned task, even though the user's account and the agent's tool configuration permit each individual action. This is distinct from privilege escalation because the attacker never exceeds the account's legitimate permissions. The paper argues that HPC security controls operate at the boundary of account authority, not task intent, so authentication, file permissions, zone isolation, scheduler accounting, and auditing all fail to distingu

What carries the argument

The central object is the 'hijacked authorized agent'—an agent whose actions are individually permitted but jointly outside the user's assigned task. The argument is carried by the distinction between account authority and task intent: HPC security encodes what an account may do, not what a particular delegated task was meant to do. The paper also provides a taxonomy of five HPC attack surfaces—shared-filesystem poisoning, scheduler and log injection, tool/module/MCP poisoning, cross-project leakage, and coordinated multi-agent exfiltration—and a comparison table showing what existing controls can and cannot record. This framing lets the authors argue that no single conventional control can

Load-bearing premise

The argument depends on the claim that prompt-injection and tool-poisoning attacks, which have been demonstrated in web and office applications, retain their effectiveness when transmitted through HPC channels such as scheduler stdout/stderr, environment-module descriptions, and shared filesystem artifacts, and that current HPC monitoring and auditing do not already surface this behavior.

What would settle it

Run a controlled experiment on a small HPC cluster: give an agent a legitimate debugging task, place adversarial instructions in a job's stdout or stderr, and check whether the agent ever carries out a command outside the assigned task, such as reading another project's files or submitting an unrelated job. If no tested agent acts on the injected content—or if standard HPC audit logs already capture the divergence—the claimed blind spot would be far narrower than stated.

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

If this is right

  • If the threat model is correct, an HPC site cannot prove after an incident whether a permitted command originated with the user's task or with adversarial content, unless the agent runtime recorded task intent.
  • Deploying agents on shared parallel filesystems and schedulers without task-scoped authority creates a channel for persistent, asynchronous injection: a file poisoned now can redirect an agent reading it later.
  • The planned TaskBound benchmark would for the first time measure both task utility and attack success for HPC-specific resources such as Slurm actions, project-scoped filesystem policies, and silent changes to scientific parameters.
  • Defenses such as task-scoped credentials, context provenance, egress control for agent-to-model traffic, and cross-agent correlation would be needed, and they require cooperation from schedulers, storage systems, and network controls.
  • Multi-agent scientific workflows face a distinct risk: one compromised agent or artifact can steer another with different access, spreading a disclosure across several ordinary-looking actions that only make sense when correlated.

Where Pith is reading between the lines

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

  • The paper leaves implicit that the same task-intent boundary applies beyond HPC: any environment where a user grants an agent broad but scoped credentials—such as cloud development or research computing—has the same blind spot.
  • A natural testable extension would be to enforce task-scoped authority inside the scheduler, tagging job submissions with a task identifier and blocking commands that cross a project boundary; this could be prototyped without modifying the agent itself.
  • The planned 'silent parameter change' scenario points to a broader issue: even without data exfiltration, a hijacked agent can corrupt scientific results, a harm that conventional security metrics do not capture.
  • The paper's taxonomy suggests a prioritization for defenses: surfaces where malicious content persists across jobs—shared filesystems and module descriptions—are the highest leverage because a single poisoned artifact can affect many later agent reads.

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

2 major / 4 minor

Summary. This position/vision paper defines a new threat model, the 'hijacked authorized agent,' for LLM agents operating in HPC environments. The central claim is that an agent acting under a user's valid credentials may be redirected by adversarial content encountered in logs, shared files, tool descriptions, or peer-agent messages, and that each resulting action remains permitted by account-level controls, thus evading conventional HPC security mechanisms. The paper distinguishes this from privilege escalation and generic indirect prompt injection, organizes HPC-specific attack surfaces into five categories (shared filesystem poisoning, scheduler/log injection, tool/module/MCP poisoning, cross-project leakage, multi-agent exfiltration), compares existing controls against the information needed to detect such hijacking, and proposes a research agenda and a benchmark design (TaskBound). The paper is explicitly scoped as a threat characterization and research agenda, not an empirical evaluation, and it acknowledges that measurement is still missing.

Significance. If the threat model is accepted, it identifies a genuine blind spot at the intersection of LLM-agent security and HPC security: account-level controls encode resource authority, not task intent. The paper is clearly written, honestly scoped, and builds on established literature in both fields. Its strengths include a clean conceptual definition (Section 4.1), a taxonomy that maps attacker footholds to HPC-specific surfaces (Section 5), and a concrete benchmark plan (Section 7.2) that follows the AgentDojo methodology. The paper does not claim empirical results, and its central claim is internally consistent rather than circular. However, the practical relevance of the threat model depends on the untested assumption that known prompt-injection and tool-poisoning techniques transfer to HPC channels; the paper acknowledges this limitation but does not yet provide evidence or a detailed argument for why HPC-specific mitigations are absent. The contribution is a well-framed research agenda rather than a completed benchmark, which is appropriate for a position paper but should be judged accordingly.

major comments (2)
  1. [Section 5] The attack-surface taxonomy assumes that indirect prompt injection and tool poisoning from refs [6,8,9] transfer unchanged to HPC channels such as scheduler stdout/stderr, environment-module descriptions, parallel-filesystem artifacts, and inter-agent messages. This is load-bearing for the claim in Section 1.1 that the problem is 'already relevant to deployed systems.' The paper does not address plausible HPC-specific counterarguments: logs are often truncated or machine-parsed; module descriptions may be subject to site review; agent frameworks may sanitize tool output; and users may already use task-scoped credentials or per-project accounts. Since no empirical evidence is provided, the taxonomy should be framed explicitly as hypotheses to be tested by TaskBound, with a discussion of what would falsify each surface. This is not a fatal flaw given the stated scope, but it needs to be ma
  2. [Section 4.1] The definition of 'hijacked' rests on the phrase 'outside its assigned task,' but the paper does not operationalize what constitutes the 'assigned task' or how a task boundary is to be determined. Without a formal task specification or policy, the definition is difficult to apply and risks circularity: an agent is hijacked if it acts outside its task, but the task may only be known after the fact. The paper acknowledges this challenge in Section 7.3 (first open question), but the definition section should state up front that the threat model assumes the user's delegated task can be expressed as a task policy (as TaskBound later uses), while acknowledging that exploratory scientific work makes such specification nontrivial. Adding this would strengthen the internal consistency of the model.
minor comments (4)
  1. [Abstract and Section 4.1] Formatting errors: 'thehijacked authorized agentproblem' (missing spaces) and 'an agenthijackedwhen' (missing spaces). These should be fixed.
  2. [Title] The title says 'Benchmarking LLM-Agent Security' but the paper presents no benchmark results; it only proposes a benchmark plan. Consider retitling to something like 'Toward Benchmarking' or 'A Threat Model and Research Agenda for ...' to avoid overstating the content.
  3. [Section 7.3] Spacing errors in the bulleted questions: 'Howcanamulti-agentworkflowpreserve...' and similar. Also, ensure consistent terminology for 'environment modules' vs. 'environment-module descriptions' throughout Section 5.3.
  4. [References] Some references (e.g., [1], [10], [11]) lack publication venues or DOIs/arXiv identifiers. Adding complete metadata would improve reproducibility and citation transparency.

Circularity Check

0 steps flagged

No significant circularity: the paper is a scoped threat characterization with no derivation, fitted constants, or self-citation chain.

full rationale

The paper is explicitly a position/vision paper (Section 1.3: 'This is a threat characterization and research agenda, not an empirical evaluation'). It makes no predictive or derivational claims, fits no parameters, and does not claim to derive results from its own prior work. The central concept, 'hijacked authorized agent' (Section 4.1), is a definition rather than a derived conclusion, and it is explicitly grounded in externally cited mechanisms (indirect prompt injection [6], tool poisoning [9], AgentDojo [8]). The only load-bearing assumption—that known attack mechanisms transfer to HPC channels—is plainly asserted as untested and openly acknowledged as missing evidence (Section 8: 'measurement is still missing'). This is an unvalidated-applicability risk, not circularity. No self-citations by the author appear in the reference list, and no cited 'uniqueness theorem' or prior author result is invoked to force the chosen framing. The paper's contribution is a taxonomy and a benchmark plan, not a derivation from inputs, so there is no equation or fitted value that reduces to its own definition.

Axiom & Free-Parameter Ledger

0 free parameters · 3 axioms · 0 invented entities

The paper introduces no free parameters, fitted values, or new physical/postulated entities. Its claims rest entirely on domain assumptions about HPC-agent deployment, the transferability of known prompt-injection attacks, and the limits of existing account-level controls.

axioms (3)
  • domain assumption LLM agents are being deployed in HPC workflows and routinely read untrusted content such as logs, tool output, shared files, and peer-agent messages.
    Sections 2.1 and 5 rely on citations [1–5] for deployment; the whole threat model only matters if this is true.
  • domain assumption Indirect prompt-injection and tool-poisoning mechanisms demonstrated in web/enterprise settings transfer to HPC scheduler logs, module descriptions, and multi-agent protocols without structural loss of effectiveness.
    Section 2.2 and Section 5 assume mechanisms from [6–9] apply directly to HPC surfaces; no HPC-specific experiments are provided.
  • domain assumption HPC account-level controls (authentication, POSIX permissions, scheduler accounting, isolation) cannot represent or verify task intent, and no deployed defense currently compensates for this.
    Sections 3 and 6 argue this through Table 2; it is the central premise of the 'hijacked authorized agent' concept and is asserted rather than measured.

pith-pipeline@v1.3.0-alltime-deepseek · 6117 in / 9880 out tokens · 98289 ms · 2026-08-01T15:15:12.400614+00:00 · methodology

0 comments
read the original abstract

Large language model (LLM) agents are starting to take on routine work in high-performance computing (HPC), including monitoring Slurm jobs, diagnosing failed builds, inspecting simulation output, and coordinating scientific workflows. To do this work, an agent commonly acts under its user's credentials and inherits the user's access to files and the scheduler. This arrangement creates a failure mode that ordinary account-level controls do not capture. Adversarial instructions in a log, tool description, shared file, or peer-agent message may redirect the agent beyond the task the user assigned, even though every resulting command is authenticated and permitted for that account. We refer to this as the hijacked authorized agent problem. Existing agent-security studies explain relevant mechanisms, such as indirect prompt injection and tool misuse, but generally evaluate them in web, enterprise, or personal-assistant settings. HPC security, by contrast, has mature controls for identity and isolation but does not ordinarily represent the intent of a particular task. This paper defines the threat model in the HPC setting, identifies attack surfaces created by schedulers, shared storage, multi-project accounts, and scientific workflows, and examines where current controls fall short. It concludes with a research agenda and a plan for an empirical benchmark, TaskBound.

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

15 extracted references · 5 linked inside Pith

  1. [1]

    Connecting large language model agent to high performance computing resource, 2025

    Heng Ma, Alexander Brace, Carlo Siebenschuh, Greg Pauloski, Ian Foster, and Arvind Ra- manathan. Connecting large language model agent to high performance computing resource, 2025

    2025

  2. [2]

    AI agents for enabling autonomous experiments at ORNL’s HPC and manufacturing user facilities

    Daniel Rosendo, Stephen DeWitt, Renan Souza, Phillipe Austria, Tirthankar Ghosal, Marshall McDonnell, Ross Miller, Tyler Skluzacek, James Haley, Bruno Turcksin, Jesse McGaha, Ben- jamin Mintz, Feiyi Wang, Mallikarjun Shankar, Sarp Oral, and Rafael Ferreira da Silva. AI agents for enabling autonomous experiments at ORNL’s HPC and manufacturing user facilit...

    2025

  3. [3]

    LARA: Validation-driven agentic supercomputer workflows for atomistic modeling, 2026

    William Dawson, Louis Beal, Yoann Curé, Giuseppe Fisicaro, Dorian Rolland, and Luigi Gen- ovese. LARA: Validation-driven agentic supercomputer workflows for atomistic modeling, 2026

    2026

  4. [4]

    Automating HPC soft- ware compilation, deployment, and error resolution through an LLM-based multi-agent system

    Sean Mondesire, Emmanuel Nsiye, Bulent Soykan, and Glenn Martin. Automating HPC soft- ware compilation, deployment, and error resolution through an LLM-based multi-agent system. InPractice and Experience in Advanced Research Computing (PEARC ’25), 2025. Best Paper, Systems and System Software track

    2025

  5. [5]

    AI agents on HPC.https://scicomp.aalto.fi/triton/usage/ ai-agents/, 2026

    Aalto Scientific Computing. AI agents on HPC.https://scicomp.aalto.fi/triton/usage/ ai-agents/, 2026. Aalto Triton user documentation; accessed 2026

    2026

  6. [6]

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

    Kai Greshake, Sahar Abdelnabi, Shailesh Mishra, Christoph Endres, Thorsten Holz, and Mario Fritz. Not what you’ve signed up for: Compromising real-world LLM-integrated applications with indirect prompt injection. InProceedings of the 16th ACM Workshop on Artificial Intel- ligence and Security (AISec ’23), 2023. arXiv:2302.12173

    Pith/arXiv arXiv 2023

  7. [7]

    Maddison, and Tatsunori Hashimoto

    Yangjun Ruan, Honghua Dong, Andrew Wang, Silviu Pitis, Yongchao Zhou, Jimmy Ba, Yann Dubois, Chris J. Maddison, and Tatsunori Hashimoto. Identifying the risks of LM agents with an LM-emulated sandbox. InInternational Conference on Learning Representations (ICLR),

  8. [8]

    AgentDojo: A dynamic environment to evaluate prompt injection attacks and defenses for LLM agents

    Edoardo Debenedetti, Jie Zhang, Mislav Balunović, Luca Beurer-Kellner, Marc Fischer, and Florian Tramèr. AgentDojo: A dynamic environment to evaluate prompt injection attacks and defenses for LLM agents. InAdvances in Neural Information Processing Systems (NeurIPS),

  9. [9]

    Prompt injection attack to tool selection in LLM agents

    Jiawen Shi, Zenghui Yuan, Guiyao Tie, Pan Zhou, Neil Zhenqiang Gong, and Lichao Sun. Prompt injection attack to tool selection in LLM agents. InNetwork and Distributed System Security Symposium (NDSS), 2026. arXiv:2504.19793

    Pith/arXiv arXiv 2026

  10. [10]

    From prompt injections to protocol exploits: Threats in LLM-powered AI agents workflows, 2025

    Mohamed Amine Ferrag, Merouane Debbah, Leandros Maglaras, et al. From prompt injections to protocol exploits: Threats in LLM-powered AI agents workflows, 2025

    2025

  11. [11]

    The landscape of prompt injection threats in LLM agents: From taxonomy to analysis, 2026

    Peiran Wang, Xinfeng Li, Chong Xiang, Jinghuai Zhang, Ying Li, Lixia Zhang, Xiaofeng Wang, and Yuan Tian. The landscape of prompt injection threats in LLM agents: From taxonomy to analysis, 2026

    2026

  12. [12]

    Specialpublication800-223: High-performance computing (HPC) security: Architecture, threat analysis, and security posture

    NationalInstituteofStandardsandTechnology. Specialpublication800-223: High-performance computing (HPC) security: Architecture, threat analysis, and security posture. Technical re- port, NIST, 2024. 9

    2024

  13. [13]

    HPC with enhanced user separation

    Andrew Prout, Albert Reuther, Michael Houle, Michael Jones, Peter Michaleas, LaToya Ander- son, William Arcand, Bill Bergeron, David Bestor, Alex Bonn, Daniel Burrill, Chansup Byun, Vijay Gadepally, Matthew Hubbell, Hayden Jananthan, Piotr Luszczek, Lauren Milechin, Guillermo Morales, Julie Mullen, Antonio Rosa, Charles Yee, and Jeremy Kepner. HPC with en...

    Pith/arXiv arXiv 2024

  14. [14]

    Alam, Christopher Woods, Matt Williams, Dave Moore, Isaac Prior, Ethan Williams, Anna Price, James Womack, Simon McIntosh-Smith, Fan Yang-Turner, Matt Pryor, and Ilja Livenson

    Sadaf R. Alam, Christopher Woods, Matt Williams, Dave Moore, Isaac Prior, Ethan Williams, Anna Price, James Womack, Simon McIntosh-Smith, Fan Yang-Turner, Matt Pryor, and Ilja Livenson. Federated single sign-on and zero trust co-design for AI and HPC digital research infrastructures. InProceedings of the SC’24 Workshops (SCW ’24), 2024. arXiv:2410.18411. 10

    Pith/arXiv arXiv 2024

  15. [2024]

    Spotlight; arXiv:2309.15817

    Pith/arXiv arXiv