Open up a tab or LLM and do quick lookup for “how to secure AI training data” and what guidance do you get back?
Encrypt at rest.
Encrypt in transit.
Field-level encryption for sensitive attributes.
Rotate your keys.
Tokenise the PII.
All good advice. All things you should do.
And none of them address the attack I raised in my post from yesterday.
Because encryption is a confidentiality control. Poisoning is an integrity attack. An attacker who adds 250 documents to your training corpus doesn’t care that the corpus is encrypted – the pipeline decrypts it to train on it, and their documents get decrypted along with everything else.
You can have flawless encryption and a completely poisoned dataset. The two are orthogonal.
So this post is about the integrity side of the equation.
But let’s address the confidentiality side of the equation properly first, because there’s one thing in it that does actually go wrong.
Briefly looking at your confidentiality controls
Encryption at rest and in transit for AI data is the same problem you’ve already solved already in your organisation.
Your existing standards apply. Nothing about a parquet file of training data makes AES behave differently. So the point of failure is almost never the algorithm itself.
It’s in your key handling.
Specifically: a data science environment that was stood up fast, with a service account that has broad access to the key material, because getting the training job running mattered more at the time than getting the key hierarchy right.
So the question to ask isn’t “is the training data encrypted”. The answer is likey “yes”.
The question is: “which identities can decrypt it, and is that list the same list you’d approve today?”
Field-level encryption and tokenisation are worth more here than they are in a typical application, for one specific reason…
A model trained on tokenised PII can still learn the patterns you want it to learn. But it can’t memorise and later regurgitate a customer’s actual tax file number, because it never saw one.
That’s a genuine reduction in blast radius rather than a compliance box. Treat it as a design decision, not a checkbox.
Addressing integrity, your open vector
I’m going to cover four controls here. These are the ones that address poisoning, and they’re less talked about, because they’re not what your encryption vendors sell.
1. Write-path access control
Chances are that your access reviews are optimised for read access. Asking “who can see sensitive data.” That’s a privacy question for the auditors.
For your training data, flip that approach. Who can write to it – including who can write to the upstream systems that feed it, and who can write to the retrieval stores your RAG deployment reads from.
Read access leaks data. Write access changes what your model believes. In an AI pipeline the second one is the bigger exposure, and should be enumerated.
2. Cryptographic integrity on datasets
Hash your training datasets. Sign them. Record the hash alongside the model artifact that was trained on them.
Then, when someone asks what data this model was trained on, you can answer with a cryptographic assertion rather than a recollection.
This is cheap – just a few lines in a pipeline.
3. Immutable staging
Between “data arrived” and “data was used for training”, there should be a stage that cannot be modified in place.
One that is write-once, append-only and versioned.
Otherwise having a mutable staging bucket that jobs read from and write to means you can’t distinguish between the scenarios of “this data changed because the pipeline transformed it” and “this data changed because someone changed it”.
If you can’t tell those apart, you have no integrity story at all.
4. Ingest-time provenance capture
This isn’t lineage reconstructed afterwards from logs.
This is provenance recorded at the moment of ingestion, as a property of the data itself. Source. Timestamp. Contributing identity. Trust tier.
This is the control that does the most work, and it’s the hardest to retrofit. Which is why it’s the one to start now rather than next year.
What ASD says
ASD’s Australian Cyber Security Centre published an AI Data Security information sheet in May 2025, developed with the NSA and international partners. It’s a short read and addresses this topic.
If you need something to put in front of a data engineering team that doesn’t read like security guidance, that’s the document. It carries the authority of the national cyber authority, and it’s written for practitioners rather than for a risk register.
The landscape today
Here’s what I keep running into.
Organisations will spend a lot on data loss prevention for their AI pipeline – controls that stop data getting out….
…And spend little to nothing on controls that govern what gets in.
Which is backwards for a system whose entire behaviour is determined by what got in.
It’s understandable why…
Exfiltration has a regulator, a notification obligation and a headline attached to it. Poisoning has none of those yet – no breach notification triggers when your model learns something wrong.
But “no regulator has named it yet” is a poor basis for a control strategy. Especially when the thing being protected is the decision-making layer you’re about to put in front of customers.
So what can you do?
Split your AI data budget and look at the ratio. In-controls versus out-controls.
If it’s worse than 1:4, you’ve found something to adress in this quarter’s budget.