L2 · MAESTRO
Data Operations
Every data surface the agent reads, writes, or shares at runtime, not training data; shared stores let a compromise propagate laterally between agents.
L2 spans the agent's data surfaces: short-term context, long-term memory, and the retrieval store the model reads at runtime.
The Data Operations layer covers every data surface that the agent reads, writes, or shares at runtime. This excludes training data (that is L1); it covers the live data plane that shapes each inference. In agentic systems this includes vector stores, prompt templates, retrieval pipelines, shared memory, tool output caches, and any corpus that the agent can query or update during a task. Because agents often share data stores across tasks and across peer agents, a compromise in this layer can propagate laterally in ways that are structurally impossible in single-request LLM applications.
What lives here
- Vector store indexes used for retrieval-augmented generation (Pinecone, Weaviate, pgvector, Chroma)
- Retrieval pipelines: chunking logic, embedding generation, similarity scoring, re-ranking
- Shared short-term and long-term memory: conversation history, task state, cross-session stores
- Prompt templates, system-prompt files, and instruction corpora managed outside the model
- Tool output caches and intermediate result stores read by downstream agents
- Structured knowledge bases queried at inference time (SQL, graph databases, document stores)
- Data ingestion and validation logic that controls what enters any of the above
- Data classification tags and access control metadata attached to stored records
In a multi-agent deployment, these surfaces are often shared. A vector store that one agent writes to is frequently the retrieval source for another. The MAESTRO guide (Cloud Security Alliance, Ken Huang, 2025) calls out this shared-write / shared-read topology as the primary reason data-plane threats have elevated severity in MAS compared to single-agent settings.
Concrete example: A legal-research system uses a LlamaIndex pipeline where an ingestion agent chunks and embeds client documents into a shared Weaviate instance, and a separate summarisation agent retrieves from the same store. A malicious PDF submitted by an external party can inject adversarial text at chunk boundaries that is semantically close to legitimate case law. Once embedded, it surfaces in every subsequent query that touches the same namespace, affecting the summaries the second agent produces for all users.
Threats that target this layer
- T1 Memory Poisoning: adversarial content written into a shared memory or vector store (via direct injection such as a malicious document in the RAG corpus, or via an agent that retrieves and re-stores tampered content) corrupts the context that subsequent agents or tasks read. Unlike a single-session attack, a poisoned vector store persists across restarts.
- T12 Agent Communication Poisoning: when inter-agent messages are buffered, logged, or cached in a shared store before delivery, an attacker who can write to that store controls the messages. This blurs the line between data-layer and communication-layer attacks.
- T5 Cascading Hallucination Attacks: retrieval pipelines that return low-quality, outdated, or adversarially seeded chunks amplify hallucination rates. A compromised retrieval corpus turns the model’s tendency to confabulate from a probabilistic nuisance into a reliable attack vector.
- T17 Supply Chain Compromise: third-party data connectors, embedding pipelines, and corpus update jobs are software with their own dependencies. A compromised data pipeline silently alters what enters the vector store without touching the model or the application code.
Mitigations anchored here
- memory content validation: validate retrieved content against an expected schema and provenance record before injecting it into the agent’s context window. Rejects chunks whose embedding source, update timestamp, or access label does not match declared policy.
- memory anomaly detection: monitor vector store reads and writes for statistical deviation from a baseline. Sudden retrieval of previously-unseen clusters, or write patterns inconsistent with normal ingestion, surface poisoning attempts before downstream inference occurs.
- memory-poisoning defence: hardened ingestion pipeline: content hashing on write, ACL enforcement on read, anomaly detection on retrieval distribution, and rate limiting on bulk write paths. Combines preventive and detective controls for the full store lifecycle.
- permission-aware vector retrieval: per-namespace and per-document access control on the vector store, enforced at query time. Prevents one tenant’s data from entering another tenant’s context, and prevents agents from reading records outside their declared scope.
- output provenance tracking: attach retrieval provenance metadata to every chunk returned, so downstream agents and audit logs can trace which store, which document, and which version of a document contributed to a given response.
- data classification: classify records at ingestion time by sensitivity level and attach immutable labels. Classification gates which agents may read a record and what retention and DLP rules apply.
How L2 relates to its neighbours
L2 sits directly above L1 Foundation Models. The distinction is temporal: L1 concerns data baked into weights at training time; L2 concerns data read at inference time. A threat that corrupts training data targets L1; a threat that corrupts a retrieval corpus targets L2. Both ultimately affect model output, but the mitigations differ: you cannot patch a poisoned embedding store by retraining the model.
The immediate layer above L2 is L3 Agent Frameworks, which consumes the data that L2 produces. The agent framework decides what retrieval queries to issue, how to incorporate retrieved chunks into the prompt, and what to write back to shared memory. Data quality at L2 is a precondition for safe reasoning at L3. A retrieval pipeline that returns attacker-controlled content defeats whatever prompt-injection defences the framework layer applies.
L2 is the layer where the boundary between “the model” and “the data” is most easily collapsed. Treating retrieval, memory, and data ingestion as trusted by default is the most common architectural error in agentic deployments, and the one MAESTRO’s Data Operations layer exists to surface.
Threats at this layer
Every threat whose maestroLayers list includes L2. The prose above may discuss a subset; this list is the complete index.
- T1Memory Poisoning
- T12Agent Communication Poisoning
- T17Supply Chain Compromise
- T18RAG Input Manipulation Leading to Policy Bypass
- T27Vector Database Poisoning with Malicious Smart Contract Data
- T28RAG Data Exfiltration
- T49Semantic Drift in Expense Policy Embeddings
- T51Agentic-Browser Cross-Origin Exfiltration
Controls mapped to this layer
Auto-generated from the mitigation catalog: every mitigation whose maestroLayers list includes L2, sorted by maturity tier (Tier 1 production-canonical first, then Tier 2, then Tier 3 research-stage).
- Tier 1Agent SBOM(Signed AIBOM: a cryptographically-bound inventory of every component an agent loads)
An AI agent assembles itself at runtime from a model, prompt templates, plugins, and library dependencies, any of which can be tampered with before they arrive. A signed AI Bill of Materials (AIBOM) locks down that assembly: it records every component with a version and hash at build time, signs the manifest, and verifies it before the agent accepts traffic. A component that does not match its declared hash cannot silently enter the agent.
- Tier 2Data classification(Data classification with tool-access allow-lists — a sensitivity label on every dataset, enforced at every access seam)
Every dataset, document, and external system an agent can reach carries a classification label. The agent's permitted-class set and the tool's permitted-class set are intersected at the moment of every read or write. When the requested data's class falls outside that intersection, access is denied at the seam. This is the data-side complement to least-privilege: it adds a data-sensitivity constraint that role scoping alone does not provide.
- Tier 2Egress DLP(Output egress DLP — inspection gate for PII, secrets, and IP at the agent boundary)
An agent produces output continuously across multiple channels: user-facing responses, tool-call parameter envelopes, log records, and outbound HTTP requests. Any of those channels can carry sensitive content the agent has retrieved, been fed, or been tricked into including. Output egress DLP places an inspection gate at the boundary so that PII, credentials, and proprietary content are classified and either redacted or quarantined before they leave the trust boundary, regardless of how they got into the output.
- Tier 2Mem anomaly(Memory anomaly detection — runtime detection of poisoning that slipped past validation)
An agent's memory store can receive adversarial content that passes schema and policy validation because the content is structurally valid but statistically unusual. Memory anomaly detection addresses this by monitoring write rates, embedding distances, provenance tags, and retrieval patterns at runtime, and quarantining writes whose statistical signatures diverge from the established baseline.
- Tier 2Mem 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.
An agent loads whichever model weights are available at startup unless the runtime is told exactly which artifact to load. If a poisoned or regressed weight is published to the model store, the agent picks it up silently on the next restart. A model registry prevents that: every artifact is registered with a cryptographic checksum and an approval stage, the agent runtime loads by explicit version pin, and new versions must pass a canary evaluation before promotion to production.
Prompt injection succeeds when untrusted content entering an agent's prompt is indistinguishable from trusted instruction. Three layered techniques address that: spotlighting tags untrusted content with a machine-readable origin mark before it reaches the model; delimiter defence rejects input carrying reserved framework tokens before the model is called; and dual-LLM extraction routes attacker-influenceable content through a quarantined model that holds no tool access, so injected instructions cannot reach the model that can act on them.
- Tier 2Provenance tracking(Output provenance tracking — record the source of every claim an agent makes)
When an agent produces a claim derived from retrieved data, that claim needs a record of where it came from: the source document, version, and retrieval time. Without that record, a downstream verifier cannot distinguish a well-grounded output from a fabricated one, a tampered one, or a poisoned one. Provenance tracking attaches source attribution to every claim, carries it through each transformation in the pipeline, and surfaces it in audit logs and user-facing interfaces.
- Tier 2SBOM for AI(SBOM for AI: the model, dataset and infrastructure record a general SBOM has no fields for)
A conventional SBOM inventories libraries, images and packages. It has no field for the weight an agent loads, the corpus it retrieves from, or where that corpus was collected. An SBOM for AI adds those: seven clusters covering the system, its models, its datasets, its infrastructure, the security controls already in place, and the indicators used to watch it. It is recorded in addition to the general SBOM, never instead of it.
- Tier 2Secret scan(Secret scanning on agent-generated artefacts — detecting credentials before they escape the trust boundary)
An agent produces code, configuration files, tool-call payloads, and log records continuously and at a rate no human reviewer can match. Any of those artefacts may contain a live API key, service token, or private certificate, placed there accidentally through model context, or deliberately through prompt injection or context poisoning. Secret scanning places an inspection gate at every agent output seam: regex patterns match known token formats, entropy analysis detects arbitrary high-entropy strings, and validator calls confirm which candidates are live credentials. The CI-secret-scanning pattern is mature; the agentic specialisation is seam placement, moving the scanner from the repository gate to the agent egress point, where artefacts can be intercepted before they reach any downstream system.
An agent that serves multiple users stores conversation history, retrieved facts, and intermediate state in a memory layer. If that layer is not scoped to the originating session, one user's writes can reach another user's retrieval path. Session-scoped memory isolation prevents that by enforcing a hard boundary at the storage layer, so each session can only read and write its own state.
- Tier 2Shared-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.
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.
- Tier 3Memory-poison defence(Memory-poisoning defence — embedding-space anomaly detection and retrieval re-ranking)
An agent that reads from a vector store assumes the stored content reflects what was legitimately written. An adversary who can write to that store can inject passages that divert the agent's retrieval toward attacker-controlled content. This control applies two defensive layers: anomaly detection on writes, which quarantines incoming embeddings that are statistical outliers relative to existing cluster centroids; and re-ranking on reads, which uses a cross-encoder or probe-gradient scorer to demote adversarial candidates after dense retrieval. Both layers are research-stage. No turnkey production implementation exists as of catalogue version; deploy additively on top of Tier 2 baseline controls.