Can the data that feeds the model be tampered with — or read by the wrong people?
Baseline: 1Enhanced: 5Advanced: 28 controls
Who it applies to
Enter only for systems where you integrate, configure or train it (B1). Some of its controls apply only where you train or adapt the model (B1), and one only where the system also acts on its own (B3). Go as deep as your system letter, and implement in your mode.
Why it exists
Secure the data path, not only the model — because an attacker who can touch what the model learns from, or what it consults, never needs to touch the model at all. Many AI systems answer by first looking things up: before responding, they consult a prepared collection of your own documents — policies, manuals, records — so their answers reflect your organisation rather than generic knowledge. That plumbing, usually called retrieval, quietly becomes part of your security perimeter the day you switch it on: whoever can add or alter a document in the consulted collection is, from that moment, shaping what your AI tells your people and your customers. The same logic applies upstream, to the data that trains or adapts a model. Guard the path with the same seriousness as the model it feeds.
What to actually do
Control who can write into anything the AI consults. If an attacker — or a careless colleague — can place a document into the collection your AI draws answers from, they can steer those answers, or plant the hidden instructions described in the Vulnerability dimension, for every user who asks the wrong question. Govern write access to consulted collections with the discipline you apply to a production database: named access, reviewed, logged. A knowledge base anyone can feed is an answer engine anyone can poison.
Treat retrieved documents as untrusted content, even though they are yours. Residence in your own repository does not sanctify a document: it may have arrived by email, been uploaded by a customer, or been edited by someone with bad intent, and any hidden instruction inside it fires when the AI reads it. Pass retrieved content through the same protective screening you apply to user input (the guardrails of the next dimension) before it reaches the model. “It came from our own system” is how this class of attack succeeds.
Verify that one tenant’s data can never surface in another’s answers. Where a data store serving AI is shared — across customers, business units, or classification levels — obtain positive proof of separation: demonstrate, by test, that queries from one tenant cannot retrieve another’s content. In shared stores of the kind AI retrieval uses, separation failures are silent — nothing crashes; the wrong fact simply appears in the wrong answer — and by the time such a leak is noticed it has usually been happening for a while.
Keep the lineage of training data, so contamination is traceable. For every dataset used to train or adapt a model, record where it came from, how it was transformed, and which models it fed — connected to the bill of materials in the Governance inventory. The day a dataset is found to be poisoned, mislabelled, or unlawfully sourced — and in the current landscape that day comes — lineage is the difference between a targeted fix and rebuilding everything on suspicion.
Controls
Baseline1 controls
Control 110
Keep training, validation and test data separate.
BaselinePreventivedeveloperper system
What it is
The split is fixed and documented before training so that evaluation measures the model rather than its memory of the test.
How to implement it · Minimum rules
Fix the split before the first training run: proportions, method (random, by time, by customer) and random seed
Split by the unit that could leak: one customer, document or period never appears in two sets
Remove exact and near-duplicate records across sets before freezing the split
Lock the test set: never used for tuning, feature selection or threshold setting
Store each set with a version and checksum, linked to the model version trained on it
How to start
Before the next training run, write down how the current data is split and check that no record appears in both training and test sets.
Evidence
The documented split per model, with set versions and the result of the cross-set duplicate check.
Mode: light / standard / full
light
The person who trains the model records split, seed and checksums in a spreadsheet.
standard
A versioned script produces the split and its record is saved with every training run.
full
The training platform enforces the split and the evaluation team holds the test set under separate access.
Enhanced5 controls
Control 111
Govern write access to every collection the AI consults.
EnhancedPreventivedeployer or developer (deployer+)per system
What it is
Named, reviewed, logged access; additions to consulted collections are controlled changes.
How to implement it · Minimum rules
List every collection the AI consults (document libraries, folders, databases, web sources), each with a named owner
Grant write access only to named people or service accounts; no shared, public or "everyone" permissions
Treat each addition or edit as a controlled change: who, what, when and who approved it
Send customer uploads and emailed documents to a holding area, never straight into a consulted collection
Log every write, and review write permissions quarterly and whenever someone changes role or leaves
How to start
Export the current write permissions of each consulted collection and remove any broad-group or anonymous access.
Evidence
The permission list per collection, the write log and the dated access reviews.
Mode: light / standard / full
light
The collection owner restricts writing in the storage's sharing settings and logs a quarterly review in a spreadsheet.
standard
Write access is granted through the normal access-request process and content changes follow the change process.
full
The identity team manages access by group with automated recertification; writes go to security monitoring.
Control 112
Screen retrieved content before it reaches the model.
EnhancedPreventivedeployer or developer (deployer+)per system
What it is
The same protective checks applied to user input apply to your own documents.
How to implement it · Minimum rules
Run every retrieved passage through the same input checks used for user prompts, before it enters the model's context
Hidden instructions: text addressed to the model, invisible or white-on-white text, instructions in metadata or comments
Sensitive data that should not reach the model: personal data, credentials, documents labelled confidential
Mark retrieved text in the prompt as quoted material, separate from the system's own instructions
Action: drop or redact the passage, log the event with its source document, notify the collection owner
How to start
Run your existing input screening over a sample of passages retrieved from each collection and review what it flags.
Evidence
The screening configuration for the retrieval path and its event log.
Mode: light / standard / full
light
Switch on the screening of retrieved content built into the AI platform and check its log monthly.
standard
Retrieved content passes through the same gateway checks as user input.
full
A dedicated screening service covers every retrieval path and traces flagged documents to their source.
Control 113
Prove tenant separation in shared stores, by test.
EnhancedDetectivedeployer or developer (deployer+)per system
What it is
Positive verification, repeated when the store or its configuration changes.
How to implement it · Steps
Identify each shared store serving AI and its boundary: customer, business unit or classification level
Plant a unique canary record (a distinctive invented phrase) in each tenant's content
From each tenant's identity, search for the other tenants' canaries: exact text, paraphrases and broad queries
Confirm the tenant filter is enforced by the store or retrieval service, not by instructions to the model
Pass only with zero cross-tenant hits; any hit blocks go-live and is handled as an incident
Repeat on every change to the store, its index, embedding model or access configuration
How to start
Plant one canary document per tenant in the shared store and try to retrieve it while logged in as another tenant.
Evidence
The test plan, the canary list and the dated results of every run.
Mode: light / standard / full
light
Whoever configured the store runs the test by hand and records results in a spreadsheet.
standard
The test is scripted and runs as a required step of every change to the store.
full
The test runs automatically in the release pipeline and periodically in production, alerting security monitoring on failure.
Control 114
Produce and maintain a written security standard for retrieval, with a go-live checklist.
EnhancedPreventivedeployer or developer (deployer+)per system
What it is
Covering who may write into consulted collections, how retrieved content is screened, how tenant separation is proven, and what a retrieval system must satisfy before it is allowed to serve answers
How to implement it · Minimum structure
Scope: the retrieval systems and consulted collections it covers
Write access: who may add or change content, approval and logging rules
Screening: the checks retrieved content passes before reaching the model
Tenant separation: when it is required and how it is proven by test
Go-live checklist: owner named, permissions reviewed, screening on, separation test passed, logging on, sign-off
Owner, annual review and the route for exceptions
How to start
Draft the go-live checklist first and apply it to the retrieval system closest to launch; write the standard around what that exercise shows.
Evidence
The approved standard and a completed, signed checklist for each retrieval system.
Mode: light / standard / full
light
A two-page standard and a one-page checklist kept by whoever leads AI use and approved by management.
standard
The standard sits in the security policy set and the checklist is a mandatory step in the release process.
full
The security architecture team owns the standard and checklist items are verified automatically before release where possible.
Control 117
Protect and validate agent memory and state stores, and treat their contents as untrusted.
EnhancedPreventivedeployer or developer (deployer+)per systemagentic
What it is
Memory that persists across sessions is a poisoning target that retrieval controls do not reach; writes are controlled and contents are screened when read back.
How to implement it · Minimum rules
List every store an agent keeps across sessions: conversation memory, notes, files, state databases
Writes only by the agent's own identity and named administrators; one user's session never writes into another's memory
Scope memory per user or tenant; shared memory only by recorded decision
Screen memory contents on read-back with the same checks as user input and retrieved content
Expire entries after a set period, and allow inspection and deletion of any entry
Log every write with its source session; alert when stored content contains instructions
How to start
List what each agent remembers between sessions and where it is stored, then switch on input screening for memory read-back.
Evidence
The access and screening configuration of each agent memory store.
Mode: light / standard / full
light
Use the agent platform's settings: per-user memory, short retention and the built-in content filter.
standard
Memory sits behind the same access controls and screening as retrieval.
full
Memory stores are managed as production data, with write events in security monitoring.
Advanced2 controls
Control 115
Record lineage for all training and adaptation data.
AdvancedPreventivedeveloperper system
What it is
Source, transformation, and destination models — connected to the bill of materials.
How to implement it · Minimum content
Dataset identifier, version and checksum
Source: origin, supplier or collection method, licence or legal basis, date obtained
Transformations: cleaning, filtering, labelling, augmentation, with script version and who ran them
Destination: every model and model version trained or adapted with it
Link to each model's bill-of-materials entry
Status and known issues: approved, restricted or withdrawn, and why
How to start
Take the most recently trained or adapted model in production and reconstruct its data lineage into this record.
Evidence
The lineage records, linked to each model's bill of materials.
Mode: light / standard / full
light
The person who trains models keeps a lineage register in a spreadsheet and updates it at every training run.
standard
Training scripts write lineage entries automatically and store them with the dataset versions.
full
The data platform captures lineage end to end, so "which models used this dataset?" is answered by query.
Control 116
Detect poisoning in data ingestion.
AdvancedDetectivedeployer or developer (deployer+)per system
What it is
Automated checks on what enters training sets and consulted collections, tuned to the deployment’s stakes.
How to implement it · Minimum rules
Cover everything entering training sets and consulted collections
Source: reject content from unapproved or unauthenticated sources
Content: hidden instructions, invisible text, repeated near-identical insertions, samples far outside the normal distribution
Labels (training data): shifts in label balance, conflicting labels on near-identical samples
Volume: sudden spikes from one source or contributor
Action: quarantine flagged items, alert the data owner, record the decision; set thresholds by the deployment's stakes
How to start
Profile a normal month of ingested data (sources, volumes, label balance) to set baselines, then switch on alerts for deviations.
Evidence
The ingestion-check configuration and the reports of flagged and quarantined items.
Mode: light / standard / full
light
Use the ingestion checks built into the data or AI platform, or a commissioned service, with the data owner reviewing flags weekly.
standard
Scripted checks run in the ingestion pipeline and block flagged items until the data owner releases them.
full
A data-quality team runs statistical and content detectors on every ingestion.
Evidence
The documented data splits per model; Access records for consulted collections; screening configuration for retrieved content; tenant-separation test results; the lineage records; ingestion-check reports. the retrieval security standard and its go-live checklist. The access and screening configuration of agent memory stores.