ML Security
Poisoning, artifact integrity, sensitive-data leakage, adversarial inputs, supply chain and inference abuse — defensively, and at the level of what to validate and trust.
Six ways an ML system is exposed that a service is not: poisoned training data, tampered artifacts, memorised sensitive data, adversarial inputs, an untrusted supply chain and abusable inference. Defensively, at the level of what to trust.
A corrupt training source teaches the model wrong behaviour, and the offline metric — computed on the same corrupt data — approves. Provenance, validation, trusted pipelines and slice evaluation are the defence.
Small, deliberate changes to a valid input flip the prediction. Defensively: validate content, test robustness, use ensembles and monitor confidence — and accept that fraud and spam are adversarial by nature.
Pretrained weights and public datasets are dependencies: unpinned, unhashed, unsigned, and loaded by formats that execute code. Pin, hash, sign, use safe formats, and record provenance in the registry.
An endpoint that answers anyone reveals its decision function, its training data and its cost structure. Authenticate, rate-limit, return decisions rather than probabilities, and bound spend on GPU endpoints.