IRM Consulting & Advisory
Generative & Agentic AI Security

MLOps Security

A stage-by-stage MLOps security playbook for SaaS teams: pickle risk, model signing, NIST SP 800-218A, drift and bias monitoring, and when API-only teams can skip it.

How to secure each stage of a machine learning pipeline, from raw data to the model in production, and when you can skip most of it

MLOps security is the set of controls that keeps the data, code, models and infrastructure in a machine learning pipeline trustworthy from ingestion to production. It covers who can change training data, how model files are stored and verified, what reaches the serving endpoint, and how you detect that a model has drifted, been tampered with, or started treating groups of users unfairly.

Every few weeks we get a version of the same call. A SaaS company of 60 or 80 people has moved from calling a hosted model to fine-tuning its own, usually on customer support tickets or product usage data. Then an enterprise prospect's security questionnaire asks, "Describe the integrity controls on your model training pipeline," and nobody knows who owns the answer. The pipeline works. Nobody designed it thinking like an attacker.

What does an attacker actually want from your ML pipeline?

Three things, in our experience: your data, your model, or your model's behavior. Training sets often hold a company's most sensitive records, copied into a bucket with looser permissions than production. Model theft matters when fine-tuned weights are your edge. Behavior manipulation is the newer category: poisoning training data, swapping a model artifact, or planting a backdoor so the model misbehaves only on a trigger.

Two public frameworks help. MITRE ATLAS catalogs real adversary techniques against AI systems in the same style as ATT&CK. NIST AI 100-2 E2025, published in March 2025, gives the taxonomy: evasion, poisoning and privacy attacks for predictive AI, plus supply chain and prompt injection attacks for generative AI. Questionnaires increasingly cite both by name.

The cost side is not theoretical. IBM's Cost of a Data Breach 2026 puts the global average breach at $4.99M and found that 92% of organizations reporting an AI-related breach lacked proper AI access controls. Access control is the boring first fix most pipelines skip.

Which controls belong at each stage of the pipeline?

This is the table we use in assessments. The opinion it carries: most teams over-invest in exotic adversarial ML defenses at the serving layer and under-invest in plain access control and integrity checks at the registry. Fix the registry first.

Stage

Main threat

Control we expect to see

MITRE ATLAS

NIST AI 100-2 E2025 class

Ingestion

Poisoned or unlicensed source data; PII copied in without basis

Allow-listed sources, provenance record per dataset, PII scan before landing, hash each snapshot

AML.T0020 Poison Training Data; AML.T0010.002 Supply Chain: Data

Poisoning

Feature store

Silent modification of features; over-broad read access

Write access limited to pipeline service identities, versioned features, change log reviewed weekly

AML.T0020 Poison Training Data

Poisoning

Training

Malicious base model or dependency; compromised training job

Pinned dependencies, base models from approved sources only, isolated training network, no long-lived cloud keys

AML.T0010.003 Supply Chain: Model; AML.T0010.001 AI Software

Supply chain (GenAI)

Model registry

Artifact swap or backdoored model promoted to production

Signed models, signature verified on promotion, two-person approval, safe serialization formats

AML.T0018 Manipulate AI Model; AML.T0011.000 Unsafe AI Artifacts

Poisoning (model); Supply chain

Serving

Model extraction, membership inference, abuse of the endpoint

Authentication, per-tenant rate limits, output filtering, no raw confidence scores unless needed

AML.T0024 Exfiltration via AI Inference API

Privacy; Evasion

Monitoring

Drift, bias or tampering nobody notices

Baseline metrics per release, drift and fairness alerts with an owner, rollback tested

AML.T0031 Erode AI Model Integrity

All classes (detection)

Four of the six rows are solved mostly by identity and integrity controls you already know from software delivery. Our guide to DevSecOps for developers covers the CI/CD half, and the ML pipeline should inherit it rather than reinvent it.

Why is the model file itself a security risk?

Because many model formats are code. Python's pickle format, behind older PyTorch checkpoints and many scikit-learn artifacts, can import and execute arbitrary functions when the file is loaded. MITRE ATLAS lists this as AML.T0011.000 Unsafe AI Artifacts: serialized models, loaded without checking, give an attacker code execution. OWASP LLM04:2025 calls out malicious pickling in the same breath as data poisoning.

The ecosystem has moved. PyTorch 2.6 flipped the default of torch.load to weights_only=True, specifically because of pickle's code execution risk. Formats such as safetensors store weights without executable content. Our rule for clients is short. Never load a pickle file you did not produce yourself, inside a pipeline that holds production credentials.

Signing closes the second gap: proving the model in production is the one you trained. The open source model signing project, built on Sigstore with OpenSSF and others, reached version 1.0 on 4 April 2025. The training job signs the model with a short-lived identity certificate, the signature is recorded in a transparency log, and your deploy step refuses anything whose signature does not verify against the expected identity. For a small team this is an afternoon of pipeline work.

What does NIST SP 800-218A add for teams that train models?

NIST SP 800-218A, published in July 2024, is a community profile of the Secure Software Development Framework (SSDF) for generative AI and dual-use foundation models. It adds AI-specific practices and tasks to SSDF 1.1 for organizations that produce models, build systems on them, or acquire them. If you already attest to SSDF for US federal customers, 800-218A is the natural extension and a reference auditors recognize.

For Canadian companies there is no direct equivalent yet, so we map the same controls to ISO/IEC 42001 when clients want a certifiable management system. Our ISO 42001 readiness offering uses this exact stage table as its technical evidence base.

How should you monitor for drift and bias once the model is live?

Drift monitoring is a security control, not just a data science chore. A sudden shift in input distribution or output behavior can mean the world changed, or it can mean someone is feeding the model crafted inputs. The May 2025 joint AI data security guidance from CISA, NSA, FBI and international partners names data drift alongside data supply chain risk and maliciously modified data, and notes that abrupt changes can signal an attack.

Bias monitoring carries legal weight on both sides of the border. In the US, the FTC's 2021 Everalbum order required the company to delete models and algorithms built from improperly used photos. Deleting the model itself is why provenance records matter. In Canada, PIPEDA's safeguards principle covers unauthorized modification of personal information, and Quebec's Law 25 requires notice when a decision about a person is based exclusively on automated processing. Healthcare SaaS adds the HIPAA Security Rule integrity standard. Our data security and privacy team maps these per client.

What we set up in practice:

  • A baseline for each released model: accuracy on a held-out set, input feature distributions, and outcome rates by any segment you can lawfully measure.

  • Drift alerts beyond an agreed threshold, routed to a named owner.

  • A tested rollback to the last signed model, timed. If it takes more than an hour, fix that first.

When do you NOT need an MLOps security program?

If your product only calls a third-party model through an API, you do not have an ML pipeline to secure. You have a vendor and a data flow. Govern it with vendor due diligence, a written rule on which data may be sent, contract terms on retention and training use, and logging of prompts and responses. Our post on shadow AI covers the usage side, and securing AI agents covers tool-calling risk. Retrieval-augmented generation sits in between: your knowledge base can still be poisoned, which our data poisoning guide addresses.

It is also premature if the platform underneath is weak. Missing MFA on cloud accounts, containers running as root and long-lived CI/CD secrets will be used long before anyone crafts a backdoor. Fix those first.

And for a single experimental model that never touches production or customer data, a lighter path works: one controlled data location, a provenance note, restricted access, and a review before anything depends on it. Scale up when the model starts making decisions about customers, money or people.

What is the right order of operations for a small team?

First 30 days: see and lock down

Inventory every dataset, feature table, model artifact and serving endpoint, with an owner each. Remove human write access to training data and the registry. Rotate any long-lived keys the pipeline uses. Ban loading untrusted pickle files.

Days 31 to 60: integrity

Add dataset hashing and provenance records at ingestion. Introduce model signing at the end of training and verification at promotion. Pin dependencies and approve base model sources. Our governance, risk and compliance work documents these as auditable controls.

Days 61 to 90: detection and evidence

Stand up drift and fairness baselines, alerts and a tested rollback. Map the controls to MITRE ATLAS, NIST AI 100-2 and SP 800-218A so the next questionnaire takes an hour, not a week.

Most teams we work with do this inside a Virtual CISO engagement, and the smallest Crawling tier starts from $2,000/mo for 15 to 20 hours. If you want a second opinion on where your pipeline stands, book a consultation.

Frequently asked questions

Is MLOps security different from DevSecOps?

It extends it. DevSecOps secures code and infrastructure; MLOps security adds data, model artifacts and model behavior as things that can be tampered with. Reuse your CI/CD controls and add the registry, signing and monitoring layers on top.

Do we need to sign models if we already restrict registry access?

Yes, once a model affects customers. Access control stops outsiders; signing proves the artifact in production is the one your training job produced, which also covers insider changes and compromised credentials.

Does the EU AI Act force us to do this now?

Not urgently for most SaaS firms. The main high-risk obligations now apply from 2 December 2027 and 2 August 2028 under Regulation (EU) 2026/1744. Build the controls because customers already ask; see our AI governance page for timing.

Victoria Arkhurst, CISSP, CRISC, CISA, CDPSE, is the founder of IRM Consulting & Advisory and has 25+ years of experience in security, risk and audit.

Keep Reading

Related Articles

Our Industry Certifications

Our diverse industry experience and expertise in AI, Cybersecurity & Information Risk Management, Data Governance, Privacy and Data Protection Regulatory Compliance is endorsed by leading educational and industry certifications for the quality, value and cost-effective products and services we deliver to our clients.

Copyright © 2026 IRM Consulting & Advisory. All Rights Reserved.