Catch attacks that cross the agent boundary before they reach your runtime.

When agents call agents — and tools, memory, and shared context sit between them — the trust assumptions of a single-agent prompt check no longer hold. Vigil tracks the four attack surfaces that emerge at the multi-agent boundary: agent impersonation, delegated privilege escalation, tool-result injection, and cross-session memory poisoning. Each is scored and surfaced alongside prompt-injection telemetry so a single monitor covers the whole runtime.

Four surfaces that only appear across agent boundaries.

Prompt injection looks at one agent reading one prompt. Cross-agent attacks look at one agent calling another, borrowing a third agent's authority, or reading back state another session wrote. The four surfaces below are the categories the multi-agent security literature consistently converges on — impersonation, delegated escalation, tool-result injection, and cross-session memory poisoning — each scored by Vigil with a pattern set tuned for the runtime channel it travels through.

01

Agent impersonation

A peer agent presents as a different agent — a different role, a higher trust tier, an admin identity — to obtain tool access it was never granted. The identity claim is the attack; the action taken with the borrowed identity is the payload.[1]

02

Privilege escalation via delegated scopes

A low-privilege agent routes a call through (or as) a higher-privilege peer so the underlying tool provider sees the high-privilege identity and grants the action. Classic confused-deputy shape, but the "deputy" is now another LLM agent — and the trust gap between them is what the adversary rides.[2]

03

Tool-result injection

Adversarial content planted in a tool's return value — a poisoned web fetch, a tampered file read, a crafted email body, a manipulated API response — arrives at the downstream agent as "data" and is obeyed as "instructions". The channel is legitimate; the content is not.[3][4]

04

Memory poisoning across sessions

Adversarial entries written into shared, vector, or persistent memory by one session resurface as authoritative context to a future session that has no reason to suspect them. The poisoned memory is the persistent foothold — re-read on every retrieval until purged.[5][6]

Operator cues that surface in the cross-agent action log.

Cross-agent attacks leave different fingerprints than single-agent prompt injection. The five indicators below are the highest-yield cues to look for in the action log when a chain involves more than one agent, a tool whose return values flow downstream, or shared memory with prior sessions.

Mismatched sender agent id vs. claimed role on an inbound agent call — a "summariser" presenting as a "planner", a "read-only" agent invoking a "write" capability, any identity assertion that does not match the registered role on directory lookup.[1]

Tool calls from an agent whose role or tier has no declared reason to invoke that tool — a "calendar-reader" calling the email-send tool, a "data-analyst" calling the credential-rotate tool. Permission breadth is the single best divergence signal at the multi-agent layer.[6]

Tool outputs containing instruction-shaped text — "ignore previous…", "now do X", "you must first…" — smuggled inside otherwise data-shaped payloads. The content type doesn't match the carrier; data channels should not read like operators.[3][4]

Memory or vector-store writes from sessions with no business justification writing into shared stores — an untitled session writing into "company-facts", a low-privilege agent updating a "user-preferences" memory used by every downstream agent.[5]

Cross-session divergence — a downstream session's tool calls cluster around a memory entry that was written by an unrelated prior session, and the divergence amount is correlated with the memory diff size. Same prompt, different action set, between sessions that should be independent.[6][2]

Six layered controls for the multi-agent runtime.

Cross-agent attacks are not a single detection problem. Identity, privilege, tool I/O, and memory each have their own failure mode, and each needs its own control surface. These six are the controls the research consistently returns to — identity on the wire, scope at the boundary, provenance on tool output, confused-deputy guards at delegation, memory provenance for cross-session reads, and divergence scoring as the last-mile signal.

01

Agent identity attestation

Sign every agent identity at registration; verify the signature on every inter-agent call. Reject any inbound agent message whose claimed role does not match a registered identity with that signature.[1]

02

Least-privilege peer scoping

Per-agent role → tool allowlist; explicit deny on any tool the agent's role has not declared as a use site. Default-closed at the peer layer, not default-open.[6][7]

03

Tool-output provenance tagging

Wrap every tool return value in a clearly-labelled data envelope before it reaches the downstream agent. The model treats data-bearing content as data, not as instructions from the operator.[4][3]

04

Confused-deputy guards at delegation

Block `agent A → tool → agent B` paths where agent B's authority exceeds agent A's. The deputy is now another agent, and the trust gap between agents is the attack surface — close the gap by enforcing that delegated authority cannot exceed issuer authority.[2]

05

Memory provenance & quarantine

Tag every shared-memory write with the source agent id, role, and write timestamp; only memories with a verified (agent, role) tuple count as authoritative context. Untagged writes go into a quarantine bucket that requires operator review.[5]

06

Cross-session divergence scoring

Alert when a session's tool-call set diverges from its per-session baseline by an amount correlated with a memory diff. Same agent, different actions across sessions that should be independent is the cross-agent equivalent of the PID divergence signal.[6][2]

Cross-agent research and sources cited.

The taxonomy, detection signals, and mitigations above are grounded in the multi-agent LLM security research below. Inline citation chips elsewhere on this page map to the numbered entries here. Cross-agent citation numbering is independent from the prompt-injection page so the two pages can each stand on their own.

  1. [1] OWASP Agentic AI — Identity, Delegation, and Trust Threats
    OWASP GenAI Security Project · 2025
    genai.owasp.org
  2. [2] CWE-441: Unintended Proxy or Intermediary ('Confused Deputy')
    The MITRE Corporation
    cwe.mitre.org/data/definitions/441.html
  3. [3] 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 & Mario Fritz · 2023
    arxiv.org/abs/2302.12173
  4. [4] Defending Against Indirect Prompt Injection Attacks With Spotlighting
    Keegan Hines, Gary Lopez, Matthew Hall, Carlos Zara & Microsoft Research · 2024
    arxiv.org/abs/2404.07560
  5. [5] Survey: Memory and Vector-Store Attacks on Long-Lived LLM Agents
    arxiv:cs.CR research area · 2024
    arxiv.org/list/cs.CR/recent
  6. [6] Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations (AI 100-2)
    National Institute of Standards and Technology · 2024
    nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2.pdf
  7. [7] OWASP Top 10 for LLM Applications — Excessive Agency & System Prompt Leakage
    Open Worldwide Application Security Project · 2025
    owasp.org/www-project-top-10-for-large-language-model-applications

Read the run-time detection playbook → Detection Playbook