3. Layer 1: Secure Your Data
Introduction
Chapter 2 Section 3 closed by reducing the whole of data poisoning to four questions you can answer in an afternoon:
Who can publish to our corpus? Who can push an adapter into our pipeline? Who can write to our vector store? Does an end user’s thumbs-down reach a training set?
Three of those four are Layer 1’s, and this section is where they get closed. Notice what they have in common: not one of them asks about the model, the prompt, or the attacker. They all ask who holds write access to something the model will later read – because that is the only variable every data attack in Chapter 2 depended on. Pretraining poisoning needed 250 documents in a crawled source. RAG poisoning needed five per targeted question. Memory poisoning needed one tool result on the write path. None of them needed scale, and none of them needed a vulnerability. They needed access.
That is also why Layer 1 is the cheapest layer to get right and the most expensive to get wrong. A poisoned RAG corpus costs an un-index to reverse; a poisoned pretraining run costs a retraining run. The distance between those two numbers is the argument for this layer.
What will I get out of this?
By the end of this section, you will be able to:
- Classify an AI data asset by sensitivity, and apply the inheritance rule that governs derived stores such as embeddings and caches.
- Determine which Layer 1 controls you actually own for a given deployment pattern, and identify the assets for which you hold none.
- Specify vector store and RAG corpus controls that close a write path, and distinguish those from controls that only make a breach legible afterwards.
- Explain what Data Security Posture Management does and does not do, and name the control that performs the enforcement DSPM only reports on.
- Map Layer 1 to its four OWASP categories, and state for each one which layer completes the defense Layer 1 cannot finish.
- Judge where encryption helps, given that most Layer 1 attacks are carried out by a principal with legitimate write access.
What Layer 1 Owns – and What It Cannot Stop
Section 2 established that layers are best compared by the kind of control they contain rather than by their number. Layer 1 is the first place that vocabulary has to earn its keep, so start by locating this layer inside it.
Layer 1 is preventive with a detective component, and almost never in the request path.
- Preventive (build-time). Corpus vetting, ingestion gates, lineage records, classification, integrity hashes. All of it happens before a request exists. By the time a user asks a question, the corpus is either clean or it is not, and nothing in Layer 1 will make that determination again during the request.
- Detective (out-of-band). DSPM discovery and classification, access-pattern monitoring, periodic hash re-verification. These produce findings, not blocks.
- One genuine in-path exception. Access control on the vector store is evaluated during retrieval, so it can cause a retrieval to return nothing. That single exception is why Section 2’s comparison table marks Layer 1 as partly able to stop a live request while Layer 2 is a flat no.
What this layer cannot do, stated plainly
Layer 1 cannot detect a poisoned document at query time. It cannot tell that a retrieved passage is asserting something false. It cannot stop a model from repeating something that is legitimately in its corpus, for a user who was never entitled to read it – that is a retrieval-time entitlement decision, and it belongs to Layer 5.
What Layer 1 can do is make the bad data not be there. That is a weaker guarantee than interception in exactly one respect (it only works if you act before ingestion) and a stronger one in every other (there is nothing left to intercept, forever, for every user).
This is the inverse of the coverage warning in Section 2. Layer 1 is named as a primary defense in only 4 of the 20 OWASP categories – the second-lowest count of any layer. But coverage counts how many categories a layer touches, not how completely it resolves any of them, and Layer 1 is the only layer that can remove a failure mode rather than intercept it. A low count and high leverage are not in tension; they are the signature of a layer that acts on state rather than on traffic.
Which Layer 1 Controls Are Yours
Chapter 1 Section 3 made a promise about this chapter:
“The layers stay constant, but which ones are yours is set by the choice you make here.”
Layer 1 is where that comes due, and it comes due harder here than anywhere else in the Blueprint. Every other layer at least exists in every deployment. Layer 1 can be almost entirely someone else’s, and a checklist that does not say so will have you auditing encryption on model weights you have never possessed.
Read the table by column, and find the column you are actually in.
| Layer 1 asset | Vendor SaaS assistant | Cloud API / serverless + your data plane | Self-hosted |
|---|---|---|---|
| Pretraining corpus | Vendor | Vendor | Vendor of the open-weight model |
| Fine-tuning dataset | Vendor, or none | You (if you fine-tune) | You |
| RAG corpus and ingestion gate | Vendor connectors, vendor policy | You – entirely | You – entirely |
| Vector store and its metadata | Vendor, usually invisible | You – entirely | You – entirely |
| Conversation logs | Vendor retention policy | Shared: your app logs, vendor’s abuse-monitoring retention | You |
| Persistent memory store | Vendor – see the case below | You, if you built one | You |
| Embeddings | Vendor | You (the store), vendor (the embedding model) | You |
Three consequences fall out of this, and they are the point of the table:
1 · The middle column is where Layer 1 work concentrates. Cloud API or serverless inference with your own retrieval pipeline is the dominant enterprise pattern, and it hands you the two assets that carry nearly all of Layer 1’s risk – the corpus and the vector store – while the model, the weights and the pretraining data stay the vendor’s problem. If you are in this column, the four questions in the introduction are almost entirely answerable by you, which is good news: the controls are ordinary access-control engineering.
2 · The left column has no Layer 1 answer, and pretending otherwise is worse than admitting it. When you consume a finished assistant, the corpus, the memory store and the retention policy are product behaviour. Your control surface is contractual and configurational – a data processing agreement, retention settings, connector scoping – not architectural. This is not a gap you close at Layer 1; it moves to Layer 4’s shadow-AI governance and vendor assessment. Note that a vendor SaaS assistant is not one of the five deployment patterns in Chapter 1, precisely because you are not deploying a model at all.
3 · Self-hosting adds the pretraining corpus you cannot inspect either. Running open weights transfers the serving stack to you, and it does not transfer the training data, which you almost never receive. The 250-document pretraining result therefore applies to a corpus that is nobody’s to audit in practice. The control that answers it is not a Layer 1 data control at all – it is Layer 2’s provenance and pre-deployment scanning, which is why Chapter 2’s comparison table splits pretraining poisoning and fine-tuning poisoning across two different layers.
Use this before the checklist, not after
The Layer 1 checklist at the end of this section is written for the middle column. Run this table first and strike every row you do not own – an audit finding against a control you cannot implement is noise, and it costs you credibility on the findings that are real.
Data Security Posture Management (DSPM)
DSPM is the discipline of continuously discovering, classifying, and monitoring an organization’s data assets so that risk to them is visible. Gartner, which named the category in 2022, frames it as providing visibility into where sensitive data is, who has access to it, how it has been used, and what its security posture is.
Read that definition carefully, because the verbs matter and the next subsection depends on them.
What DSPM Does Not Do
DSPM reports. It does not enforce.
It is easy – and common in vendor material – to describe DSPM as though it blocks things. It does not. DSPM will tell you that a fine-tuning dataset in an object store is writable by eleven service principals, that a RAG corpus contains PII, or that a vector store was modified at 03:00 by an identity that has never touched it before. Every one of those is a finding.
The control that actually prevents the poisoned record from reaching the training pipeline is the IAM policy and pipeline gate you implement in response to the finding. DSPM is how you learn the gate is missing; it is not the gate.
This distinction is not pedantry, and it is the same error Section 2 found drawn into the Blueprint’s own defense-in-depth diagram: a detective control described as a blocker produces an architecture that looks defended and intercepts nothing. An organization with excellent DSPM coverage and no ingestion gate has perfect visibility into a corpus anyone can write to.
Why AI Data Is Different
DSPM for traditional IT covers databases, file shares, cloud storage, and SaaS applications. AI systems add asset classes most of that tooling was never built to reach:
- Training and fine-tuning datasets – often terabytes, often assembled from many sources, and in the fine-tuning case often containing the most concentrated proprietary knowledge an organization holds
- RAG corpora – a second copy of documents whose originals already have decades of access control around them
- Embeddings and vector stores – derived numerical representations, in a store that usually also holds the original chunk text
- Conversation logs – user queries and model responses, accumulating continuously, frequently containing PII that nobody decided to collect
- Persistent memory stores – durable state written by a process that reads untrusted content
A traditional DSPM tool can scan a SQL column for card numbers. Scanning a vector store for embedded PII, classifying a training corpus by sensitivity, or tracing a fine-tuning example back to the account that submitted it are different problems, and coverage of them is the specific thing to test when evaluating a tool.
Model weights are a Layer 2 asset, deliberately
Weights are data in the ordinary sense, and you will see them listed under data security in a lot of material. This course puts them in Layer 2, because every control that matters for them – signing, hash pinning, serialization safety, provenance, pre-deployment scanning – is model-supply-chain work rather than data-governance work, and because a weights file is executable in practice (the pickle problem). Encrypting a backdoored checkpoint at rest protects it perfectly. The boundary is worth stating because the two layers meet at fine-tuning: the dataset is Layer 1, the resulting checkpoint is Layer 2.
The DSPM Workflow for AI
graph LR
D["<b>Discover</b><br/><small>Inventory all AI data<br/>assets: corpora, vector<br/>stores, logs, memory<br/>stores</small>"]
C["<b>Classify</b><br/><small>Assign sensitivity,<br/>including by inheritance<br/>for derived stores</small>"]
M["<b>Monitor</b><br/><small>Track write access,<br/>re-verify hashes, alert<br/>on anomalous flows</small>"]
P["<b>Report</b><br/><small>Findings: who can write<br/>where, what is exposed,<br/>what drifted</small>"]
G["<b>Enforce</b><br/><small>IAM policy, ingestion<br/>gate, retention job --<br/>NOT part of DSPM</small>"]
D --> C --> M --> P
P -.->|"Continuous<br/>reassessment"| D
P ==>|"Findings drive"| G
style D fill:#2d5016,color:#fff
style C fill:#2d5016,color:#fff
style M fill:#2d5016,color:#fff
style P fill:#2d5016,color:#fff
style G fill:#1565c0,color:#fff
The loop is continuous rather than one-time, and the reason is specific to AI data: these assets change on a different schedule from the databases DSPM grew up on. RAG corpora take new documents daily. Conversation logs grow every session. Vector stores are rebuilt wholesale when an embedding model is upgraded – an event that silently re-derives every vector in the store and is easy to miss as a security-relevant change. A classification decision made at the last quarterly review describes a store that no longer exists.
Defense Connection
DSPM is how the LLM05: Data and Model Poisoning write path becomes visible. For the feedback-loop poisoning attack in particular, DSPM’s contribution is answering the question “where did this training example come from?” – and Chapter 2 is explicit that the load-bearing control there is a human review gate between the feedback store and the training set. DSPM finds out whether that gate exists. It is not the gate.
Data Classification for AI Systems
Not all AI data carries the same risk, and classification is what makes controls proportional rather than uniform. For AI systems it does one more job that traditional classification rarely has to: it has to handle derived stores.
The Inheritance Rule
A derived store inherits the classification of its most sensitive source
A vector store built from an HR share, a legal folder and a public wiki is one store, and it must be governed as HR-and-legal data whatever the retrieval layer calls it. The same holds for embeddings, caches, chunk tables, evaluation sets sampled from production traffic, and conversation logs that quote retrieved content back.
This rule exists because the intuitive alternative – classify the derived store by what it is (numbers, a cache, an index) rather than by what it was made from – is how a store of vectors over confidential documents ends up rated MEDIUM and deployed with a connection string.
Sensitivity Tiers for AI Data
| Data Type | Sensitivity | Key Risks | Required Controls |
|---|---|---|---|
| Fine-tuning datasets | CRITICAL | Poisoning, business logic theft, PII leakage | Strict write access controls, version control, sensitivity scanning, human review gate |
| Persistent memory stores | CRITICAL | Durable poisoning invisible to the user, cross-session compromise | Write-path allowlist, provenance per entry, user-confirmed writes only |
| Vector stores and embeddings | Inherited – as sensitive as the most sensitive source document | Corpus poisoning, metadata tampering, plaintext chunk exposure, embedding inversion | Authn/authz, RBAC split by operation, encryption, integrity hashing, write audit |
| RAG corpora | Inherited, typically HIGH | Poisoning, stale data, entitlement drift after indexing | Source authentication, ingestion gate, per-chunk provenance, freshness tracking |
| Conversation logs | HIGH to CRITICAL | PII exposure, business intelligence leakage, compliance exposure | Encryption, retention policy with automated deletion, PII detection and redaction |
| Pretraining corpora | HIGH, and usually not yours | Poisoning before the model exists | Provenance where available; otherwise a Layer 2 problem |
Two tiers in that table changed shape relative to a traditional data inventory. Vector stores and embeddings are the ones people under-rate, for the reasons in the inheritance rule. Persistent memory is the one people miss entirely, because it does not look like a data store – it looks like a product feature.
Defense Connection
Classification is the first control against LLM02: Sensitive Information Disclosure, and Chapter 2 Section 6 is precise about which route it closes. Of LLM02’s three routes, the common one is not extraction or memorization – it is retrieved content passed straight through to a reader who was never entitled to it, with no attacker involved. Classification is how you know that content is in the corpus. Enforcing entitlement inside the retrieval query is the control that stops it reaching the wrong reader, and that is Layer 5. Redaction after retrieval is strictly worse than never retrieving.
Vector Store and Embedding Security
Vector databases are the backbone of RAG systems – the pattern from Chapter 1 Section 6 that you saw attacked in Chapter 2 Section 3. They index embeddings for nearest-neighbour search, and they hold three things: the vector, the original chunk text, and the metadata that retrieval filters on.
The store is a copy of your data, not an index over it
This is the single most consequential misconception about vector stores, and it drives most of the under-classification in the previous section. The pipeline needs the original passage to put in the prompt, so the chunk text is usually stored alongside the vector. Anyone who can read the store can read your documents, in plaintext, without ever touching the source system that permissions them.
A vector store is therefore a data-governance object that happens to support similarity search – not a piece of retrieval infrastructure that happens to contain data.
Security Controls for Vector Databases
The 2026 position on vector store security is not that the controls are missing from the products. Pinecone, Milvus, Qdrant, Weaviate and pgvector all ship authentication, role-based access control, and encryption at rest and in transit; several carry SOC 2 attestations. The gap is between what the products support and what deployments turn on – a vector store stood up during a proof of concept, reached over a connection string with a single all-powerful key, and then promoted to production because it worked.
| Control | What It Does | Why It Matters for AI |
|---|---|---|
| Authentication and authorization | Requires identity verification before any read or write | Closes the direct-write path that bypasses every ingestion validation |
| RBAC split by operation | Separate permissions for ingestion, query, and administration | The ingestion pipeline writes; the application reads; nobody does both. Prevents lateral movement from a compromised app to the corpus |
| Metadata write control | Restricts who can modify per-chunk metadata | Metadata filtering is the entitlement check, so whoever writes metadata decides who retrieves a document – privilege escalation with no code execution |
| Encryption at rest | Encrypts stored vectors, chunk text, and metadata | Relevant precisely because the chunk text is there in plaintext otherwise |
| Encryption in transit | TLS for all connections to the store | Queries and retrieved passages are both sensitive payloads |
| Write audit and query logging | Records modifications and retrievals with identity and timestamp | The only way a tampering event becomes reconstructable; detective, not preventive |
| Integrity verification | Hashes over stored chunks and their vectors | Detects modification that arrived outside the ingestion pipeline |
The choice most teams make by default and should make deliberately
A dedicated vector service and a vector extension of a database you already run (pgvector being the common case) are not equivalent from a Layer 1 standpoint. The extension keeps vectors, chunk text and permissions inside one system that already has your audit tooling, backup policy, IAM integration and DLP coverage pointed at it. The dedicated service is a new data store with its own access model, and every one of those controls has to be re-established around it. Choose the dedicated service for scale or feature reasons, not by default – and if you do, budget the governance work rather than discovering it during an audit.
Embedding Inversion Risks
Even where the chunk text is not stored, the vectors alone are not anonymous. Vec2Text (Morris et al., EMNLP 2023) reconstructs source text from embedding vectors by iteratively refining candidate text until its embedding matches the target, recovering a substantial share of short inputs exactly, including from commercial embedding models.
The practical consequence is a one-line rule: embedding is a transformation, not de-identification. “We only store vectors, not the documents” is not a privacy control, and it should not be accepted as one in a design review. Protecting the source document store is necessary and not sufficient; the derived store needs its own classification, its own access control, and its own encryption.
Defense Connection
Vector store controls are Layer 1’s answer to LLM09: Vector and Embedding Weaknesses. Chapter 2 catalogued four distinct weaknesses – poisoning through ingestion, direct writes that bypass ingestion, metadata manipulation for entitlement bypass, and readability of the store itself. Note that they need different controls: the ingestion gate stops the first, store authentication stops the second, metadata write control stops the third, and only classification and encryption address the fourth. A team that hardens the ingestion pipeline and leaves the store reachable has closed one of four.
Protecting RAG Corpora
RAG is the most widely deployed enterprise AI pattern and the largest attack surface in a typical AI application. Protecting the corpus is the highest-leverage work in Layer 1, for a reason Chapter 2 quantified.
The Scale Problem, Stated Correctly
It is five documents per targeted question, not five per corpus
PoisonedRAG (Zou et al., USENIX Security 2025) injected five malicious texts per attacker-chosen question into a corpus of millions and achieved roughly a 90% attack success rate. The result is routinely repeated as “five documents backdoor a corpus of millions,” which gets the unit wrong in both directions.
It is narrower: the attack is targeted. Five documents buy control of the answer to one question the attacker picked in advance, not general control of the corpus.
And it is worse: an attacker does not want general control. They want the answer to “what is our refund policy?”, “is vendor X approved?”, “what are the wire instructions?” – and each costs five documents. Corpus size is irrelevant, because similarity search does not care how many documents it did not return.
The transferable point: dilution is not a defense in retrieval. What protects a corpus is knowing who can write to it.
Getting this unit right changes what you do about it. “Five documents compromise everything” suggests a detection problem of impossible difficulty. “Five documents per question, and the questions are the ones your business cares about” suggests something tractable: enumerate the high-value questions your corpus answers, and audit provenance on the chunks that currently answer them.
The RAG Data Supply Chain
graph LR
SRC["Source Documents<br/><small>Internal docs, policies,<br/>knowledge base articles</small>"]
ING["Ingestion Pipeline<br/><small>Parsing, chunking,<br/>embedding generation</small>"]
VS["Vector Store<br/><small>Vectors + chunk text<br/>+ metadata</small>"]
RET["Retrieval<br/><small>Similarity search,<br/>metadata filtering</small>"]
LLM["LLM Generation<br/><small>Response using<br/>retrieved context</small>"]
SRC -->|"1. Access-controlled<br/>document feed"| ING
ING -->|"2. Provenance +<br/>integrity hash per chunk"| VS
VS -->|"3. Entitlement enforced<br/>inside the query"| RET
RET -->|"4. Context with<br/>source attribution"| LLM
ATK["Attacker with<br/>corpus write access"]
ATK -.->|"Poisoned document<br/>through the front door"| SRC
ATK ==>|"Direct write --<br/>bypasses every<br/>control at step 1-2"| VS
style SRC fill:#2d5016,color:#fff
style ING fill:#2d5016,color:#fff
style VS fill:#2d5016,color:#fff
style RET fill:#2d5016,color:#fff
style LLM fill:#2d5016,color:#fff
style ATK fill:#8b0000,color:#fff
The two attacker edges are the reason this is drawn as a supply chain rather than a list of controls. A poisoned document entering at step 1 is caught by source authentication and recorded by provenance. A direct write to the store at step 3 is caught by neither, because every validation the ingestion gate performs was at step 1. Hardening ingestion while leaving the store writable moves the attacker one hop and costs them nothing.
Key Protection Strategies
Source Authentication. Accept documents only from verified, authorized feeds. Allowlist the sources; require provenance metadata or signatures on ingested content. This closes the front door in the diagram.
Access-Controlled Ingestion. Separate ingestion from retrieval with RBAC so that the application layer holds query-only credentials. “Any authenticated user can add a document” is the most common form of this defect, and it is why the ingestion gate does more work than any content filter – both instruction-bearing and fact-bearing poisoned documents arrive through it.
Per-Chunk Provenance. Record, for every chunk: where it came from, when it was ingested, who approved it, what transformations were applied, and which embedding model produced its vector. The last field is the one usually omitted and it is load-bearing twice over – it tells you which vectors are stale after a model upgrade, and it scopes the blast radius if a compromised embedding model has to be assumed.
Integrity Hashing. Hash each chunk at ingestion and re-verify on a schedule. A hash change with no corresponding change-management record is the signal that a direct write happened.
The Ability to Un-Index. RAG poisoning is the cheapest data attack to reverse – the model is clean, so removing the documents ends it. That is only true if you can find them, which is what provenance is for, and if your pipeline supports selective deletion and re-embedding. Many do not, which converts a low-cost incident into a full corpus rebuild.
Entitlement Freshness. Access was correct on the day a document was indexed. Then a folder’s permissions changed, or someone left, and the index still holds a copy carrying the old label. A vector store is a cache of your permissions model, and caches go stale. Re-index on permission change, or resolve entitlement at query time against the live source.
Content Freshness. Track document age and flag stale content. In security advisories, product documentation and regulatory guidance, a confidently cited stale answer fails the user much the way a poisoned one does.
Defense Perspective: ChatGPT Memory Exploitation (SpAIware)
The attack (from Chapter 2 Section 2): Johann Rehberger showed in 2024 that ChatGPT’s long-term memory could be written to by indirect prompt injection. Hidden instructions in content the user asked ChatGPT to read invoked the memory tool, and the stored directive then exfiltrated every subsequent conversation to an attacker’s server through an auto-rendered image. OpenAI fixed the exfiltration channel in September 2024; writing arbitrary instructions into memory via injection was not fixed. By 2026 the technique is automated – MemGhost delivers the same primitive to inbox-reading agents through a single email.
Why this case belongs in Layer 1: persistent memory is a data store. It is durable, it is read into every future request, and it is written to by a process that reads untrusted content. That combination is a Layer 1 asset by every definition in this section, and treating it as “a product feature” instead is what made the attack a standing backdoor rather than one bad session.
The control, stated as narrowly as it can be: ASI06: Memory and Context Poisoning turns on one question – what is allowed to write to memory, and is a tool result on that list? Everything else follows from the answer:
- A write-path allowlist that admits user-confirmed actions and excludes model-generated content derived from processed documents. This is the whole control; the rest is enforcement detail.
- Provenance per entry, so every memory records whether it originated in a user request or in processed content – which makes the allowlist auditable and the incident reconstructable.
- CRITICAL classification, which is what causes write validation to be required at all rather than treated as a nice-to-have on a cache.
And now the uncomfortable part: if you are a ChatGPT user, you own none of this. Look back at the ownership table – the memory store sits in the vendor column. Every control above was OpenAI’s to implement, and the vendor with full access to the primitive chose to fix the channel instead. The Layer 1 lesson for a consumer of that product is not a control; it is that memory features are a vendor-assessment question and a Layer 4 governance question – and tenancy of any memory or cache feature is one of the four questions Layer 4 puts to a vendor. The Layer 1 lesson for anyone building an agent with memory is that this is your write path, and nobody else will gate it.
Encryption and Data Protection Patterns
Encryption is the control most reliably present in an AI data architecture and the one most often expected to do work it cannot do. Start with the limit, because it reframes the rest.
Encryption does not address most Layer 1 attacks
Go back through the attacks in this section. Corpus poisoning, direct writes to the vector store, metadata tampering, feedback-loop poisoning, memory poisoning – every one is carried out by a principal with legitimate write access, through a path the system is supposed to support. Encryption at rest is transparent to exactly that principal. The corpus is decrypted for the pipeline that poisons it.
Encryption defends a different and narrower threat: someone who obtains the storage without obtaining the credentials. A stolen snapshot, a mis-scoped bucket, a decommissioned disk, a backup in the wrong account. That threat is real, which is why encryption stays on the checklist – but if encryption is the strongest control on your corpus, the corpus is unprotected against everything in Chapter 2 Section 3.
With that established, the at-rest patterns worth knowing are the ones where AI data differs from ordinary data:
| Data Type | Pattern | The AI-specific consideration |
|---|---|---|
| Vector stores | Database or volume-level encryption | Encrypt the chunk text, not just the vectors – the plaintext passages are the exposure. Confirm encryption does not disable the index type you rely on |
| Conversation logs | Per-user keys, with rotation | Per-user keys make right-to-erasure tractable: destroy the key and the records are unrecoverable without rewriting a log store you may not be able to rewrite |
| Fine-tuning datasets | Dataset-level encryption plus access logging | The access log is the part that matters. This is the CRITICAL asset with the fewest legitimate readers, so any read is worth recording |
| Large training corpora | Hardware-accelerated encryption | Throughput, not secrecy, is the design constraint; software encryption can bottleneck a training pipeline reading terabytes |
In transit, use TLS 1.3 for every hop – application to vector store, application to model endpoint, inter-service calls, and pipeline transfers from source to ingestion. The hop teams most often leave unencrypted is the internal one between the ingestion job and the vector store, on the reasoning that both sit inside the same network. That is the hop carrying every document in the corpus.
Layer 1 → OWASP Mapping
Layer 1 is named as a primary defense in four of the twenty categories across the LLM Top 10 and the Agentic AI Top 10. For each one, the honest statement has two halves – what Layer 1 resolves, and what it hands to another layer.
| Category | The route Layer 1 acts on | What Layer 1 does | What it cannot do | Completed by |
|---|---|---|---|---|
| LLM02: Sensitive Information Disclosure | Sensitive content sitting in a corpus or a derived store | Classification, inheritance rule, PII scanning, retention limits, encryption | Decide at query time whether this reader is entitled to this passage | L5 – entitlement inside the retrieval query, response filtering |
| LLM05: Data and Model Poisoning | Write access to fine-tuning data and feedback stores | Ingestion gate, provenance, integrity hashing, human review gate before training | Anything about a checkpoint that is already poisoned, or a pretraining corpus you never see | L2 – signing, hash pinning, pre-deployment scanning |
| LLM09: Vector and Embedding Weaknesses | The store itself: writes, metadata, and readability | Authn/authz, RBAC by operation, metadata write control, encryption, write audit | Prevent an entitled identity from being reached in the first place | L3 posture on the store’s exposure; L5 on who reaches it |
| WarningASI06: Memory and Context Poisoning | The write path into persistent memory | Write-path allowlist, per-entry provenance, CRITICAL classification | Detect a poisoned instruction inside content the agent is reading | L5 – context validation on the way in |
Read the fourth column down and a pattern appears: Layer 1’s boundary is always the moment a request exists. Everything upstream of that moment is Layer 1’s; everything from the request onward belongs to a layer that can see the request. That is a more useful way to remember the split than the numbering, and it is the same conclusion Section 2 reached from the control-type axis.
AI Scanner Cross-Reference
AI Scanner contributes to Layer 1 at one specific point: it tests whether a model has memorized and will reproduce sensitive training data, which is the extraction route of LLM02: Sensitive Information Disclosure. That is a pre-deployment check on the consequence of a Layer 1 failure – by the time it fires, the sensitive data is already in the weights, and the fix is upstream in corpus curation. Treat a positive result as evidence about your data pipeline, not as a model defect. Section 9 covers the full scan-protect-validate-improve loop.
TrendAI Vision One provides the DSPM half of this layer – discovery, classification, and access monitoring across AI data assets and traditional ones in the same inventory. The integration argument is specific rather than general: the inheritance rule in this section only works if the tool can see both the source document store and the derived vector store, and can tell that one was built from the other. A DSPM product that classifies the HR share correctly and treats the vector store built from it as an unremarkable database will report a clean posture over exactly the gap this layer exists to close.
Key Takeaways
- Every data attack in Chapter 2 depended on write access rather than on scale or on a vulnerability, which makes “who can write to what the model will read” the whole of Layer 1’s question
- Layer 1 is preventive and detective, not in-path: it cannot intercept a request, and in exchange it can make the bad data not exist at all – permanently, for every user
- Derived stores inherit the classification of their most sensitive source; a vector store holds the chunk text in plaintext and its vectors are invertible, so it is a copy of your data rather than an index over it
- DSPM reports and does not enforce; the IAM policy and ingestion gate you build in response to its findings are the controls that actually close a write path
- Which Layer 1 controls exist for you is set by your deployment pattern – a vendor SaaS assistant leaves you none of them, which is why the ChatGPT memory case has a Layer 4 answer for its users and a Layer 1 answer only for people building agents
- Encryption defends against obtaining the storage without the credentials, and is transparent to every legitimate-write-access attack in this section
Test Your Knowledge
Ready to test your understanding of AI data security? Head to the quiz to check your knowledge.
Up next
Layer 1 stops at the moment a request exists, and it hands two things forward. Poisoned checkpoints and the pretraining corpus you cannot audit go to Layer 2. In Section 4 you will see how model signing, hash pinning, serialization safety and pre-deployment scanning close what data governance cannot reach – starting from the position that a weights file is executable code until proven otherwise.