Definition
An attacker injects manipulated data about malicious smart contracts into the vector database used by ElizaOS agents (an open-source multi-agent operating system built on Solana), causing those agents to interact with the malicious contracts. This is a form of data poisoning specific to the blockchain context: the vector store becomes the attack vector through which fraudulent smart contracts are presented as legitimate and profitable investment targets.
What it looks like in practice
An attacker creates a malicious Decentralised Finance (DeFi) contract and generates a set of fabricated research documents describing it as a high-yield, audited protocol with a long track record. The attacker injects embeddings of these documents into the shared vector database that ElizaOS agents use for Retrieval-Augmented Generation (RAG) investment research. When an agent queries the store for high-yield DeFi opportunities, the poisoned records rank highly. The agent retrieves them, incorporates the fabricated intelligence into its reasoning, and submits a buy transaction to the malicious contract. The contract drains the wallet.
The hallucinated investment cascade cross-layer scenario from the MAS Guide (L1 + L2 + L7) shows how the poisoned retrieval then propagates through agent-to-agent communication: a second agent queries the first agent’s research output and independently confirms the malicious contract as legitimate, compounding the exposure.
Why it’s dangerous in multi-agent context
ElizaOS agents share a common vector database for research and decision-making. A single poisoning event can affect every agent that queries the same store simultaneously. Agent-to-agent communication means poisoned intelligence is relayed laterally: agents cite each other’s (incorrect) conclusions, transforming a single database write into a fleet-wide decision error. Unlike T38 (Emergent Collusion on Blockchain) where harmful collective behaviour arises without adversarial input, T27 is adversarially seeded: the attacker designs the poisoned records specifically to pass the agent’s plausibility checks.
Detection signals
Poisoned records tend to cluster in time, share fabricated provenance markers, and rank anomalously high for queries that historically returned known-good results.
- A batch of newly indexed embeddings all sharing the same ingest timestamp (or a narrow window of less than 60 seconds) and all referencing an unverified external URL as their source. Log ingest-batch metadata and alert on any single-origin bulk ingest event above a defined threshold (e.g. > 20 documents in 60 seconds from one source).
- A retrieval result set for a high-value investment query that is dominated (> 60 % of top-10 results) by documents indexed within the past 48 hours, when historical baseline for that query type shows a much wider age distribution. This is a recency-bias anomaly in retrieval results.
- A contract address appearing in the top retrieval results that is absent from the independently maintained blockchain registry. Cross-reference every retrieved contract address against an external registry before passing the result to the agent’s reasoning step.
- A document’s embedding vector that clusters tightly with other recently indexed documents (inter-document cosine similarity > 0.97) despite claiming to represent independent research sources. A diversity-check on retrieved result sets should flag near-duplicate embeddings from supposedly distinct sources.
- An agent placing a buy transaction for a token that has no on-chain trade history older than 30 days. Instrument the transaction submission layer to look up chain age for any token not already in the agent’s verified watchlist, and require human approval for novel tokens.
Mitigations
- Enforce authenticated write access to the vector database; cryptographically sign ingested documents and verify signatures at retrieval time.
- Apply source provenance filters: reject embeddings derived from unvetted or unverifiable data sources.
- Cross-reference high-conviction retrieval results against an external, independently maintained blockchain registry before committing any on-chain transaction.
- Rate-limit and review newly indexed embeddings before they become eligible for retrieval by production agents.
Relation to base threat (T1–T17)
T27 extends T1 Memory Poisoning. Where T1 addresses short-term context and persistent agent memory, T27 targets the shared RAG vector store that all agents in the fleet query. T28 (RAG Data Exfiltration) is the read-path complement: the same vector store that T27 poisons is the target of direct exfiltration in T28.
OWASP Top 10 for Agentic Applications 2026
The Agentic Top 10 (ASI01 through ASI10) is a separate practitioner-facing publication that maps onto the master Threats & Mitigations threat numbering. T27 is covered by the following Top 10 entries:
-
ASI06 Memory & Context Poisoning primary An adversary writes malicious or misleading data into an agent's persistent memory or shared vector store, so that every future session, and every peer agent reading from the same store, operates on corrupted context. The defining difference from single-turn injection (ASI01) is that the poisoned data survives session reset; the agent's reasoning drifts without any new attacker input.
Source: OWASP Top 10 for Agentic Applications 2026 (Dec 2025) · the Top 10 is a compass into the master Threats & Mitigations taxonomy, not a replacement for it.
Design principles at stake
When T27 is present, these security design principles are the ones being violated or tested. Each links to the full principle; the mitigations below are how you restore them.
- Defence-in-Depth A single poisoning event affects every ElizaOS agent that queries the shared vector database simultaneously, and agent-to-agent citation then propagates the fabricated intelligence laterally: a second agent independently confirming the malicious contract compounds the exposure fleet-wide. Depth means the retrieval result is not the final authorisation for an on-chain action: authenticated write access to the vector database prevents unauthenticated embedding injection at the write path, source provenance filters reject embeddings from unvetted sources before they become eligible for retrieval, high-conviction retrieval results are cross-referenced against an independently maintained blockchain registry before any transaction is committed, and newly indexed embeddings are rate-limited through a review queue before production agents can retrieve them. Defeating the write-path controls does not reach the cross-reference gate; passing the cross-reference gate does not bypass the provenance filter on the next ingestion.
- Memory & RAG Integrity The shared RAG vector database is the long-term memory from which all ElizaOS agents draw their investment intelligence, so poisoning it with fabricated smart-contract research is structurally equivalent to planting a false fact in an agent's persistent memory: every future query inherits the corrupted context. Integrity controls must treat the vector store as a security-relevant write surface: cryptographic signatures on ingested documents verified at retrieval time detect tampering after the fact, source allow-listing ensures that only provenance-verified data sources contribute to the corpus, and rate-limiting on newly indexed embeddings before they reach production retrieval creates a staging window for review. The cross-reference check against an external blockchain registry is the read-time integrity gate that holds even when the store's write-path controls are bypassed.
Recommended mitigations
Auto-generated from the mitigation catalog: every mitigation whose coverage map includes T27, sorted by maturity tier (Tier 1 production-canonical first, then Tier 2, then Tier 3 research-stage).
- Tier 2 Mem validate (Memory content validation — a write-boundary gate on what enters the agent's memory store)
An agent's memory store is a persistent surface: anything written to it can be retrieved by any agent, in any session, for the lifetime of the corpus. Memory poisoning exploits that persistence by writing adversarial content that steers the agent's reasoning long after the attacker has gone. Write-boundary validation prevents this by running every candidate memory write through schema, policy, and provenance checks before it is committed. Content that fails any gate is rejected and never reaches the store.
why it helps Vector store poisoning with malicious financial-instrument data requires the attacker to commit adversarial embeddings to the shared corpus. Schema checks reject structurally malformed payloads; embedding-distance outlier detection flags vectors that are anomalously distant from the trusted cluster centroid; provenance verification rejects writes that cannot be traced to a trusted source. All three gates must fail for a poisoned vector to land.
- Tier 2 Shared-memory ACL (Shared-memory ACL — per-agent, per-namespace read/write access control on shared vector stores)
When multiple agents share a single vector store, the access boundaries between them are not enforced by the store itself unless you configure them explicitly. Without per-namespace write and retrieval controls, an agent that can write to the shared corpus can insert crafted vectors into any namespace it can reach, and any agent that can query the store can retrieve another agent's confidential documents through embedding-space proximity. Shared-memory ACL addresses this by tagging every vector with a principal identifier at write time and filtering every retrieval query to the requesting agent's namespace, enforced at the gateway layer where the agent cannot bypass it.
why it helps Namespace-scoped write ACL constrains a blockchain-integrated agent's write surface to its own partition, so malicious smart-contract data cannot be written into a namespace used by a different agent. Retrieval-side ACL prevents a separate agent from reading poisoned financial-instrument embeddings across namespace boundaries.
-
A vector store returns results by embedding-space proximity, not by who is asking. Without a per-principal filter applied before similarity ranking, a query from tenant A can surface tenant B's vectors if the embeddings are close enough. Vector ACL closes that gap: every retrieval call is scoped to the requesting principal's namespace or payload partition before the store ranks any results, so cross-principal hits are structurally impossible rather than merely unlikely.
why it helps T27 involves malicious embeddings written to one namespace being retrieved by agents operating in a different namespace. Retrieval-boundary namespace isolation prevents cross-namespace reads by construction: an agent querying its own namespace cannot receive vectors written to another namespace, regardless of embedding proximity.
Red-team pivot: MITRE ATLAS techniques
MITRE ATLAS catalogues adversary techniques against AI systems. Where this OWASP threat has an attacker-perspective counterpart, the ATLAS technique is shown below. That is what a red team would actually be doing on the wire. Use this for detection-signal anchoring, threat-hunting hypotheses, and IR runbooks. Source: mitre-atlas/atlas-data v5.6.0.
AML.T0070 RAG Poisoning view on ATLAS ↗ Adversary injects malicious content into documents indexed by a retrieval-augmented generation system so future queries surface attacker-controlled context.
AML.T0051.001 LLM Prompt Injection: Indirect view on ATLAS ↗ Adversary injects prompts via a separate data channel ingested by the LLM (databases, websites, documents) rather than directly in user input.
Agentic angle: Primary injection vector for RAG-backed agents: malicious text in retrieved context becomes instructions the model follows silently.
AML.T0080 AI Agent Context Poisoning view on ATLAS ↗ Adversary contaminates an agent's context store (short-term scratchpad, vector memory, conversation history) so future reasoning is biased toward attacker goals.
Agentic angle: Persistent across sessions: a single successful poisoning influences every later decision until the memory is purged.
References
- OWASP MAS Threat Modelling Guide v1.0 (April 2025) §4 ElizaOS — Layer 2 Data Operations.
Sources
- OWASP-MAS-Guide ↗ · 1.0 (Apr 2025) · §4 Eliza OS — Layer 2 Data Operations