RESEARCH
AI agents face poisoned tools and misleading files, faults hit post-quantum crypto
OT and industrial securitySupply chain
This week three studies test AI agents: poisoned MCP tools that succeed in almost one case in four, signed tools that leak data and Office files the model reads differently from us. On hardware, a Trojan in sensors and two attacks on SLH-DSA and ML-KEM stand out. Compiler bugs in zkVMs and browser NativeMessaging round out the edition.
1. SenTrojan: Revealing Analog Hardware Trojan Attacks on Sensors
arXiv · Kun Wang, Ruochen Zhou, Wenjun Zhu, Shilin Xiao et al. · CPS & IoT Security
In short: SenTrojan shows that an analog Trojan implanted in sensors before deployment can be triggered by external physical signals, causing denial of service or spoofed readings.
The authors design hardware Trojans in the analog circuitry shared by many sensors, activated by crafted physical signals. Two variants cover different architectures. On 14 sensors across 6 transduction principles they report an average trigger rate above 95% and over 97% similarity to benign behaviour, with drift and noise deviations under 5%.
Why it matters. The work moves sensor security from unintended physical flaws to deliberate supply-chain compromise. A Trojan that deviates less than 5% from normal behaviour is hard to catch with routine testing.
For insurers. For insurers of industrial plants, vehicles or medical devices, component provenance becomes an underwriting question: a sensor compromised at the factory can cause failures or false readings across many insureds using the same model, creating accumulation potential.
2. Beyond Instruction Override: Benchmarking Indirect Prompt Injection with Task-Tampering Attacks
arXiv · Rongting Zhang, Martin Bertran, Sandeep Avula, Chia-Jung Lee et al. · AI & LLM Security
In short: A new benchmark shows that indirect prompt injection can tamper with a task's outcome without replacing the task, and that current defences cover only part of it.
The authors define the attack by authority: injection occurs when content tries to influence a decision its source is not authorised to make. In 90 cases across three environments, attacks on decision rules, actions and state succeed more often than objective attacks. A detection defence still lets 12.1% of state attacks through, a tool-policy defence 15.4%.
Why it matters. Many agent security tests only check whether the task is redirected, and so overestimate how well defences work. A realistic example: dispute evidence that cites a false refund policy to inflate the payout.
For insurers. For insurers of companies using agents for refunds, payments or case handling, the loss scenario is not only a hijacked agent but a skewed decision inside a legitimate task. Vendor claims about prompt injection defences should be read with this gap in mind.
Read the paper · PDF · Code
3. PIMROP: A Feasibility Study of Return-Oriented Programming on Commercial Processing-in-Memory Architectures
arXiv · William C. Tegge, Shouzhi Fang, Alex K. Jones · Hardware & Side Channels
In short: PIMROP demonstrates for the first time return-oriented programming attacks on a commercial processing-in-memory core, outside the defences that protect host programs.
Processing-in-memory cores run code next to DRAM banks. On the UPMEM DPU the authors find 517 gadgets in the runtime library every kernel links and demonstrate two attacks that leak a secret, succeeding in 10 of 10 runs. Stack canaries and _FORTIFY_SOURCE-style checks fail for platform-specific reasons; a bounds-checked DMA stops the attack.
Why it matters. Processing-in-memory architectures move computation and data outside the reach of defences such as canaries and control-flow checks. Adopters must verify that standard protections actually work on the new hardware.
For insurers. Processing-in-memory is not yet widely deployed, so the insurance impact is limited for now. The case still shows that a control reported as enabled, such as a stack canary, can be ineffective on new platforms.
Read the paper · PDF · Code
4. MCP Tool Poisoning in Agentic AI Frameworks: A Cross-Framework Measurement Study
arXiv · Farooq Shaikh, Biagio Montaruli · AI & LLM Security
In short: A measurement across 12 agentic frameworks and 18 models finds MCP tool poisoning succeeds in 22.9% of cases, and no framework implements intentional defenses.
Using the open-source tool mcpvenom, the authors run a 9,720-cell matrix: 12 frameworks, 18 models and 45 scenarios with real tool execution. Attacks succeed in 22.9% of cells, and 12.1% of those verifiably exfiltrate a secret. Resistance is model-level, from 0.4% to 49.7%. A regex scanner rejects 20 of 45 scenarios; all five vendor disclosures were rejected.
Why it matters. Teams wiring AI agents to third-party MCP servers cannot rely on the framework: tool descriptions and responses reach model context unvalidated. Metadata scanning is only a partial control.
For insurers. Underwriters should ask which models and MCP servers an insured uses, since resistance varies by two orders of magnitude across models. The lack of defenses in widely used frameworks also points to accumulation risk across users of the same tools.
5. Proving the Wrong Program: Miscompilations as a Threat to zkVM Guarantees
arXiv · Hui Xuan Tan, Stefanos Chaliasos, Alastair F. Donaldson · Systems & Software Security
In short: A compiler bug can make a correct zkVM produce a valid proof of a computation that differs from the source code, and an attacker can trigger it on purpose.
On SP1 and Jolt the authors reproduce 88 known rustc and LLVM miscompilations: 48 make the guest commit a wrong output on SP1 and 46 on Jolt. Real projects are rarely hit by accident, but for about $40 per project an LLM agent finds innocuous-looking patches that expose bugs in 12 of 366 pairs across 11 of 20 projects, including an Ethereum client that rejects a valid block.
Why it matters. Neither review nor formal verification of the zkVM or the source can catch such a patch, because both are correct. The authors advise treating the compiler as part of the trusted base and tracking its known bugs.
For insurers. For insurers of blockchain projects or services built on zero-knowledge proofs, a valid proof does not guarantee the expected program ran. Underwriting should look at how the insured manages its toolchain and external contributions.
6. Signed, Sealed, Leaked: Trust Beyond Signature for MCP Toolchains
arXiv · Yichiet Aun, Mohammed A. Alhartomi, Jing Jie Tan, Waqas Nadeem et al. · Software Supply Chain
In short: A signed MCP tool can still leak data to a policy-allowed destination; germline execution bounds what malicious code can disclose.
A signed MCP tool hides sensitive data in requests to a policy-allowed destination: Meta's MCPGuard-Dynamic misses it in every trial. The authors propose germline execution, where each invocation runs in ephemeral copies that receive only authorised data. Across 153 attack runs they detect no unauthorised disclosure, versus 5.9-74.5% under baseline defenses, at 10-49 ms per invocation.
Why it matters. A signature proves who published a tool, not what it does. Isolating data per invocation limits damage even when malicious code runs.
For insurers. When assessing controls, code signing and runtime policies do not rule out data leakage through third-party AI tools. The scenario resembles supply-chain compromise, with possible accumulation across users of the same tool.
7. Correlation Power Analysis on SHA-2-Based SLH-DSA
IACR Cryptology ePrint Archive · Jinwook Chang, Minjeong Lee, JIN YONG MIN, Dong-Guk Han · Post-Quantum Cryptography
In short: Correlation power analysis recovers portions of the secret seed of SHA-2-based SLH-DSA on a Cortex-M4 microcontroller.
The authors attack the address-based pseudorandom function for all six SHA-2 parameter sets, through both SHA-256 compression rounds and message-schedule expansion. On an STM32F303 with 5,000 traces per seed, compression-round stages reach 100% success. Rates are conditional per stage, with preceding values supplied, not end-to-end seed recovery.
Why it matters. SLH-DSA is a post-quantum signature standard. Embedded implementations must protect both the compression rounds and the message schedule against side channels, not just one of them.
For insurers. Direct insurance relevance is limited and long-term: it concerns device and chip makers adopting post-quantum signatures. The work is a reminder that moving to a standard algorithm does not remove implementation risk.
8. Keyber: Recovering the Signal by Amplifying the Noise in ML-KEM
IACR Cryptology ePrint Archive · Vipin Kumar, Prathamesh Ram, Suparna Kundu, Dhiman Saha · Post-Quantum Cryptography
In short: Keyber recovers the ML-KEM secret key from a single fault during key generation, compromising the key for its whole lifetime.
This is the first SIFA on ML-KEM key generation. The fault adds a known value to the error vector; the attacker then encapsulates locally, keeps only usable ciphertexts (0.2-27%) and turns each decapsulation failure into one inequality on the key. Up to 30,000 inequalities suffice. The authors run it end-to-end on ML-KEM-512 on a Cortex-M4 with an over-clock fault.
Why it matters. Fault attacks on ML-KEM had so far targeted decapsulation. This work shows that key generation, a one-time operation, also needs hardening.
For insurers. Direct insurance impact is limited, as physical access to the device is required. It matters for insurers of secure-hardware, smart-card or IoT makers adopting ML-KEM.
9. Breaking \mathsf{TraintoDefend} via Adaptive Neuron Clustering in Cryptanalytic Model Extraction
arXiv · Haojie Wu, Haolin Liu, Tianshuo Cong, Guoyan Zhang · AI & LLM Security
In short: SimBreak defeats TraintoDefend, the only defense believed effective against cryptanalytic model extraction, raising signature recovery from 0% to 100%.
TraintoDefend pushes neurons to learn similar weights so their contributions are hard to tell apart. The authors note that similar weights need not switch together and propose an adaptive clustering rule that estimates a shared relative scale to test weight direction and bias. On six protected MNIST networks, target-layer signature recovery rises from 0% to 100%.
Why it matters. Weight similarity is not enough to protect a model from parameter extraction. Defenses against cryptanalytic extraction need adaptive evaluation.
For insurers. Insurance relevance is limited, as results cover small MNIST networks. For those protecting AI model intellectual property, it shows a published defense can fall quickly.
10. The Native Menace: Host-to-Browser Cross-Boundary Attacks via Native Messaging
arXiv · Jyotirmay Chauhan, Rownak Islam, Jason Polakis · Web & Mobile Security
In short: A non-privileged native app can abuse browsers' NativeMessaging API to intercept sensitive data or sign documents on the user's behalf.
The authors run the first empirical security analysis of the NativeMessaging API, the channel between browser extensions and native apps. A non-privileged malicious app can intercept traffic or use other apps as confused deputies. Attacks hit 1Password, the EU eID system and Google Drive, extensions with over 532 million downloads, up to full vault leakage and arbitrary document signing.
Why it matters. The channel has no root of trust or client attestation. The authors propose encrypting messages with an out-of-band shared secret; the paper will appear at IEEE S&P 2027.
For insurers. Password managers and digital signatures are key controls in underwriting questionnaires. Here local malware bypasses them, and the reach of the affected extensions suggests accumulation potential, with document fraud and credential theft.
11. Shoot on (Core)Sight: Re-enabling Secure Debug on the RP2350 with Photon-Emission Microscopy and Laser Fault Injection
arXiv · Antoine Plin · Hardware & Side Channels
In short: Using photon-emission microscopy and laser fault injection, the author re-enables core 1 Secure debug on the RP2350 chip and extracts a 128-bit test secret.
The work shows that fault-resistant policy storage does not guarantee fault-resistant enforcement. Microscopy narrows the laser scan area, which finds two sites where a pulse sets the DEBUGEN bits. A sequence driven only by SWD feedback restores sustained access and, after rescue reset, recovers a 128-bit test secret.
Why it matters. The RP2350 is a widely used microcontroller sold with security features. The attack needs lab equipment and physical access, but it shows where debug-protection controls can fail.
For insurers. Insurance relevance is low: it requires possession of the chip and costly tools. It matters to insurers of device makers that store secrets or protected firmware on these chips, given cloning or IP-theft risk.
12. When File Ingestion Misleads Language Models: Measuring and Mitigating Divergences in Office Documents
arXiv · Penghui Li · AI & LLM Security
In short: Text extractors for Office files show the language model different content from what a person sees, and this gap can be exploited.
Combining static and dynamic analysis of widely used extractors, the author finds 19 OOXML channels where they read content a human cannot see and 12 where they drop visible content. Building on this, five attacks lead the model to read a document differently from a human reviewer, without injecting any instruction. Four popular chat assistants and four coding agents each fall for at least one.
Why it matters. Anyone uploading contracts, quotes or reports to language models cannot assume the model reads what the user sees. The proposed defense, Prism, rebuilds the human view from the OOXML specification.
For insurers. The risk affects workflows that use language models to review documents, such as claims, contracts or due diligence: a tampered file can drive a wrong assessment with no visible sign. Worth covering in controls on the insured's AI use.
How this digest is made
New papers are collected every day and selected every week from arXiv, the IACR ePrint archive and the main security conferences and journals (IEEE S&P, USENIX Security, ACM CCS, NDSS, CRYPTO, PoPETs, IEEE TIFS and others). A score based on source, topic and early signals picks the candidates; an AI model assesses them and writes the summaries. Summaries are based on the abstracts: the original paper is the reference for details.
New papers assessed for this edition: 262.