AI Agent Arxiv Digest — 2026-10-31

Today's Overview

Today's three papers ask the same question from three different angles: what should an agent actually trust? CoSA shows that agent skills which each pass individual safety review can be composed to bypass review altogether. The Trust Region Effect paper systematically demonstrates that agents place wildly different levels of trust on different file locations — the same injected instruction gets obeyed 2.6x more often when it's sitting in a README than when it's sitting in code. And PCM goes after the root problem of agent-to-agent trust directly, proposing a cryptographic protocol so an agent can no longer talk another agent into believing a bare claim. Put together, the message is clear: agent systems are full of implicit trust boundaries, and right now almost none of them are guarded.

Terms Worth Knowing Before Reading

Paper 1 | CoSA: Individually-Safe Skills Composed Together Are Not Safe

CoSA: The Conflict of Skills Attack in Real-World LLM Agent Ecosystems Yujia Zheng, Tianhao Li, Shangzhi Xu et al. (9 authors, one affiliated with the Institute of Computing Technology) · arxiv: 2610.35082

Links: arxiv · alphaxiv · GitHub

TL;DR

Agent skills that individually pass safety checks can, when composed, push the policy-violation rate from 35.02% to 58.45% — with the added skills capped at just 5% of the existing pool.

Editorial Judgment

Field Context

Agent Skills let developers extend agent capability without rewriting everything, but today's review process is almost entirely "check each skill in isolation" — every skill is security-scanned before it's listed. The problem: that review assumes skills don't affect each other, but in practice, output from one skill can be reused by another skill in a way that drops the restrictions the original output carried.

Intermediate Walkthrough

• The problem: Imagine a "read customer data" skill that passes review because it only returns data to the agent itself, and a "send email" skill that passes review because it only sends when the user explicitly asks. If the agent repackages data it read from the first skill as "the user already approved this" for the second skill, the two individually-safe skills combine into unauthorized data exfiltration.
• The method: CoSA analyzes an existing skill pool and identifies two composition mechanisms — "capability supplementation" (supplying a missing operation) and "relationship reshaping" (altering how artifacts, decisions, or action targets get passed along) — then uses these to select seemingly benign skills to add, within a budget of just 5% of the pool.
• Why it matters: "Every skill is safe" does not imply "the skill pool is safe." Skill marketplace review needs to move from per-skill auditing to composition-risk auditing.

Deep-Dive Points

• CoSA-Bench: 288 tasks across recruiting, finance, IT, and business domains, covering data leakage, unauthorized state modification, and unsafe execution
• Across 5 LLMs and 3 agent harnesses, adding at most 5% new skills to the pool raises the policy-violation rate from 35.02% to 58.45% (+23.43 points)
• Defense: a harness-level guard that checks information flow and authorization drops violations on OpenClaw recruiting tasks from 65.28% to 6.67%, with a reported tradeoff against benign-task completion
• Deployment bar: requires inserting information-flow tracking at the harness layer (not the single-skill layer) — an architectural change for existing live marketplaces, not a simple scanning rule
• Framework relevance: applies to any agent framework supporting external skill/plugin loading (e.g. systems built on OpenClaw or MCP-style tool ecosystems)
• Limitation: evaluation is bounded to CoSA-Bench's constructed scenarios; real marketplace composition space is far larger than 288 tasks

Reviewer's One-Liner

The attack mechanism is clearly defined and the benchmark is solid, with the defense backed by concrete effect sizes — a rare case of an agent-security paper delivering attack, benchmark, and defense together; but the evaluation is still on a self-built benchmark, and the complexity and adversarial dynamics of real skill marketplaces still need external validation.

Takeaways for You

• If you run an agent skill/plugin marketplace: don't rely on single-skill scanning alone — add cross-skill information-flow and authorization tracking at the harness layer; CoSA's defense design is a direct reference
• If you're assessing your own agent's security: add composition testing to your red-team process — testing each skill individually says nothing about safety when they're combined

Paper 2 | The Trust Region Effect: Agents Trust Different Files Very Differently

Where You Inject Matters: The Trust Region Effect in LLM Agents Chengquan Guo, Xiaodong Liu, Weiwei Yang et al. (University of Chicago, Microsoft Research, University of Rochester, Simon Fraser University, UC Davis, UIUC; 10 authors) · arxiv: 2610.38867

Links: arxiv · alphaxiv

TL;DR

Holding the injected content fixed and varying only its location, GPT-5.4 is 2.6x more likely on average to obey a malicious instruction placed in a README/TODO file than the identical instruction in a code or data file.

Editorial Judgment

Field Context

Indirect prompt injection — where an attacker hides malicious instructions in content the agent will read, rather than talking to the agent directly — has topped the OWASP LLM Application Top 10 for two consecutive years. Prior research mostly optimized what to inject, or compared placement only within a single interface (e.g. one webpage); nobody had systematically compared which kind of file the injection sits in as a variable in its own right.

Intermediate Walkthrough

• The problem: Imagine a coding agent working through a task, reading a README, a TODO file, source files, and data files in sequence. The exact same malicious instruction, placed in the README, may get followed; placed in a data file, it gets completely ignored. Same content, wildly different outcome — this is what the paper calls the "trust region effect": agents implicitly assign different trust levels to different regions of their environment.
• The method: The team built 3 long-horizon testbeds (coding, tool-use, daily workflow), held the malicious instruction's content fixed, and varied only the file type and in-file position (start/middle/end), using deterministic scripts (not an AI judge) to determine attack success, repeated across 8 frontier models.
• Why it matters: If current agent-safety defenses only check "does this content look dangerous," they'll miss an equally important risk factor: "where is this content located." Defense design needs extra scrutiny on high-trust regions like documentation files.

Deep-Dive Points

• Three testbeds built on Terminal-Bench-2 (coding), AgentDojo (tool-use), and DecodingTrust-Agent (daily workflow), covering 36 environmental surfaces
• GPT-5.4 follows an unsafe instruction in README/TODO 2.6x more often on average than in code/data files; in the workflow domain, GitHub and Slack are more exploitable than Confluence and Jira
• Failed injections are overwhelmingly ignored rather than explicitly refused — GPT-4o ignores 81.3% vs. explicitly refusing only 0.7%
• Using GPT-5.4 itself as an attacker to pick the best injection placement does not reliably beat a simple frequency-based prior
• A two-stage GRPO-trained "placement-aware attacker," optimizing content and placement jointly, outperforms content-only optimization and transfers to a more robust model
• Limitation: measures conditional attack-success-rate after successful delivery; whether an injection even reaches the agent in a real deployment is a separate question

Reviewer's One-Liner

Using deterministic verifiers instead of an AI judge to score attack success is methodologically more rigorous than much comparable work, and the consistency across 8 models and 3 independent testbeds makes the "trust region effect" finding solid; but this is still a "problem discovery" paper — it offers no corresponding defense mechanism, leaving readers with a clear direction rather than a ready-made fix.

Takeaways for You

• If you build coding agents or agents that read external documents: don't assume README, TODO, or comment-style content is inherently trustworthy — add an extra check for instruction-like language in these file types
• If you're designing agent safety guardrails: rules shouldn't only judge "does this content look like an attack" — they should also weight risk by "which surface does this content appear on," since the same instruction carries different risk depending on placement

Paper 3 | PCM: Making It Impossible for One Agent to Lie to Another

PCM: A Proof-Carrying Message Protocol for Verifiable Multi-Agent Communication Bravish Ghosh (Cygnux Labs) · arxiv: 2610.39109

Links: arxiv · alphaxiv · GitHub

TL;DR

On a benchmark of 926 real messages, 712 of them lies, PCM accepts only 10 (1.4%), while six existing deployed protocols — including the ecosystem around A2A and MCP — accept between 504 and 712.

Editorial Judgment

Field Context

Protocols like A2A (from Google) and MCP (from Anthropic) solved how agents transmit messages and authenticate channels, but not whether the receiving agent should believe the message's content. An agent compromised by prompt injection — or one that's simply hallucinating — can sign and send a completely well-formed lie, and existing protocols have no way to tell.

Intermediate Walkthrough

• The problem: Imagine Agent A tells Agent B "the tests passed, please refund $120." B has only A's word. If A was prompt-injected, or simply reported a failed test as a pass, B has no way to tell — existing protocols only verify "this really was signed by A," not "what A claims actually happened."
• The method: PCM borrows from proof-carrying code — the producer of untrusted code ships a proof, and the consumer checks it with a small checker instead of trusting the producer. PCM routes every agent tool call through an "attesting signer" service the agent cannot write to, which records each call's outcome in a tamper-evident log. When an agent sends a message, it ships the log evidence alongside; the receiver checks the signature and evidence offline and returns one of three verdicts — proven, unproven, or failed. A claim resting solely on the agent's own word can never be "proven." Authority works the same way: a grant chain rooted in a human's approval that can only narrow at each step.
• Why it matters: This turns inter-agent trust from "I choose to believe you" into "I can independently verify you." For any multi-agent system touching money or delegated authority, this is a concrete move from optimistic trust toward a zero-trust architecture.

Deep-Dive Points

• PCM-Lies benchmark: 926 messages from real signer runs (real pytest suites, HTTP requests, file writes, human approvals), 712 of them lies across 16 classes
• PCM accepts only 10/712 lies (1.4%, 95% CI 0.8-2.6%), all of the "stale evidence" type (a test passed once, the code later changed and broke it, but the sender still cites the old pass)
• Baselines: plain A2A accepts all 712; six modeled deployed protocols (signed A2A Agent Cards, uAgents, RFC 9421, SCITT, AP2, Verifiable Intent) accept 504-712; even stacking AP2, SCITT, and RFC 9421 together still accepts 51.3%
• Two independently written verifiers agree on all 926 verdicts; per-message verification takes about 0.8-1.2 ms, with a median message size of 1.9-11.7 KB
• Deployment bar: requires standing up an independent "signer" service and genuinely ensuring the agent cannot touch the signer's keys or log — an architectural change
• Framework relevance: can layer on top of A2A/MCP as an additional verification layer; the paper explicitly positions itself as augmenting, not replacing, existing protocols
• Limitation: the signer itself is the trusted computing base, and the paper does not end-to-end test whether signer isolation actually holds in a real multi-tenant production environment

Reviewer's One-Liner

A formal threat model, proven security properties, and an empirical benchmark all present together — with "what this protocol doesn't solve" spelled out as clearly as the contribution — is a rare level of engineering rigor; but it's solo-authored and not yet peer-reviewed, and the entire guarantee rests on the deployment assumption that the signer is actually isolated, which still needs external validation.

Takeaways for You

• If you're designing a multi-agent system involving money or delegated authority: existing A2A/MCP signatures only prove who sent a message, not that its content is true — PCM's proof-carrying approach is worth directly evaluating
• If you're auditing agent security: use PCM-Lies' 16-class lie taxonomy to check whether your downstream agents can take high-risk actions based solely on an upstream agent's unverified self-report

Today's Takeaway

I used to think agent security was mainly about blocking malicious input. Today's digest points at something more fundamental: what should an agent actually trust? Skill composition, file location, and another agent's word are all currently assumed trustworthy by default — and all three papers show that default assumption can be exploited. Defense design needs to go one step before "block the attack": first draw the trust boundaries.

References

• CoSA: The Conflict of Skills Attack in Real-World LLM Agent Ecosystems (arXiv:2610.35082)
• CoSA official code (GitHub: SIGMIR-ORG/CoSA)
• Where You Inject Matters: The Trust Region Effect in LLM Agents (arXiv:2610.38867)
• OWASP Top 10 for LLM Applications
• PCM: A Proof-Carrying Message Protocol for Verifiable Multi-Agent Communication (arXiv:2610.39109)
• PCM official code and spec (GitHub: Cygnux-Labs/PCM-protocol)
• Google Agent2Agent (A2A) Protocol
• Anthropic Model Context Protocol (MCP)