Enterprise-grade AI DevSecOps — model registry hardening, cryptographic artifact signing, secure AI CI/CD design, drift as a threat signal, dependency governance, AI SBOM enforcement, and the complete advanced security checklist for production ML systems.
Most enterprise security programs have a mature DevSecOps practice for traditional software: SAST/DAST in the pipeline, dependency scanning with Dependabot or Snyk, container scanning with Trivy, SBOM generation with Syft. These are well-understood, well-tooled disciplines. AI systems require all of those — and a second, overlapping security discipline that targets the behavioral attack surface traditional tools cannot see.
The behavioral attack surface is what makes AI DevSecOps genuinely different: a model checkpoint is not just a binary artifact with CVEs; it is a probabilistic system with exploitable semantic properties that can only be discovered through adversarial testing. A system prompt is not just a configuration file; it is a security control whose effectiveness degrades under mutation attacks and must be verified through bypass rate measurement. A RAG knowledge base is not just a database; it is a retrieval surface where adversarial content planted at ingestion can execute arbitrary instructions weeks later when retrieved. Traditional DevSecOps tools have no visibility into any of these.
The foundational DevSecOps integration guide: AI DevSecOps and MLOps Security: Securing the AI Development Pipeline →
The model registry is the highest-value target in enterprise MLOps infrastructure. It controls which model goes to production — which means an attacker who compromises the model registry can deploy a backdoored model, roll back to a vulnerable version, or silently replace production model weights. The blast radius is the entire AI system: all users, all interactions, all tool calls, from the moment of deployment until the compromise is detected.
Cryptographic artifact signing: Every model artifact stored in the registry should be signed with a key that is never accessible to the CI/CD pipeline itself — requiring a separate, hardware-backed signing step with a different identity. The signature is verified at deployment time before the artifact is promoted to production. An artifact whose signature cannot be verified against the expected signing key is rejected, regardless of any other pipeline gates that passed. This prevents a compromised pipeline from deploying a modified model — the pipeline can build artifacts, but only the signing key can authorise deployment.
Immutable version storage: Model versions should be append-only in the registry — once a version is registered, its weights cannot be modified. Any modification produces a new version with a new version number, a new signature requirement, and a new deployment approval workflow. This makes silent model replacement impossible: an attacker who modifies weights must also register a new version (triggering approval workflows) or break the signature check (triggering deployment block).
Separation of duties for deployment: The identity that builds and registers a model artifact should be different from the identity that promotes it to production. CI/CD service accounts have registry write access for new versions. A human approver (or an automated approval gate that includes adversarial security testing) holds the promotion authority. The approval gate cannot be bypassed by the CI/CD identity — it requires a different credential set. This prevents a single compromised credential from enabling both artifact modification and production deployment.
Deployment audit trail: Every registry operation — new version registration, version promotion, production deployment, rollback — is logged in an immutable audit trail with the identity of the operator, the version affected, and a cryptographic record of the artifact state. This audit trail is the forensic record that enables incident investigation when a compromised model is discovered: it tells you when the compromise was introduced, which identity registered the compromised artifact, and how long the compromised model was in production.
A mature AI CI/CD pipeline has four security gates that a deployment must pass before reaching production. These gates run in sequence — failure at any gate blocks progression:
Gate 1 — Traditional security scan: SAST on application code, dependency vulnerability scan on all packages, container image scan on inference containers, secrets detection to prevent API keys or credentials from being committed. This gate is identical to traditional DevSecOps and uses the same tools.
Gate 2 — Model integrity verification: Verify the model artifact's cryptographic signature against the signing authority. Verify the model version hash matches the registered hash in the model registry. For fine-tuned models, verify the fine-tuning dataset provenance hash is in the approved dataset registry. Any mismatch blocks deployment.
Gate 3 — Adversarial security testing: Run the HexTyx scan against the staging deployment. Gate criteria: risk score < 70, bypass rate < 50% per mutation strategy, zero confirmed leaks. This gate catches the security properties that Gates 1 and 2 cannot see — prompt injection vulnerability, jailbreak resistance, credential leakage, tool abuse potential. A model or prompt change that passes Gates 1 and 2 but introduces a new injection vulnerability will be caught here.
- name: AI Security Gate (HexTyx)
run: |
hextyx scan --target $STAGING_ENDPOINT --fail-on-risk 70 --fail-on-bypass 50% --fail-on-leak --format sarif,json
- uses: github/codeql-action/upload-sarif@v3
with: { sarif_file: scan_results.sarif }Gate 4 — Calibration seeding: Before production promotion, seed the Aegis calibration loop with the Gate 3 scan output. This ensures that production Aegis detection rules are updated with any new bypass patterns discovered in staging before the first production request is served.
The supply chain security controls that protect what goes into the pipeline: AI Supply Chain Security: Protecting Models, Plugins, Dependencies →
In traditional ML operations, drift is a quality problem: the model's outputs are diverging from expected patterns, typically due to distribution shift in the input data. In AI security operations, drift is additionally a threat detection mechanism: unexpected behavioral shifts that don't align with any known input distribution change may indicate active adversarial influence — a corpus poisoning campaign that has successfully shifted retrieval patterns, a prompt injection campaign that is gradually conditioning the model's session-level behavior, or a dependency compromise that has altered inference behavior.
The AIZA-HexTyx signals that serve as drift detection mechanisms in production:
Memory Graph novel cluster emergence: Every new AttackNode in the Memory Graph that doesn't cluster near existing nodes (cosine similarity < 0.82 to all existing centroids) represents a novel attack pattern. A burst of novel cluster formation — multiple new clusters forming in a short window — signals either a new attacker probing the system or a change in the attack surface that is generating patterns not seen before. Monitor GET /graph/clusters daily; a >20% increase in cluster count week-over-week triggers a re-scan.
MultiTurnTracker QUARANTINED rate: The fraction of sessions escalated to QUARANTINED verdict is a population-level behavioral signal. A rising QUARANTINED rate without a corresponding rise in new user accounts signals that existing users are attempting increasingly adversarial interaction patterns — a coordinated campaign or a systematic probing effort that MultiTurnTracker's stage-pattern matching is detecting across sessions.
Bypass rate longitudinal trend: Track bypass rate per mutation strategy as a time series, not just a point-in-time scan result. A bypass rate that is monotonically increasing over consecutive scans — even if each individual measurement is below the alert threshold — signals that the model's defenses against that strategy are eroding. This is behavioral drift with a security consequence: the model's resistance to a specific attack class is degrading.
CP2 block rate per source collection: A rising rate of CP2 blocks from a specific RAG source collection signals that the content of that collection is changing in ways that increasingly match injection patterns — the signature of an active corpus poisoning campaign against that data source. Alert threshold: >5% CP2 block rate from any single source collection triggers immediate investigation of recent ingestion from that source.
The automated testing guide that provides the scan cadence for drift measurement: Automated LLM Security Testing: The Complete 2026 Guide →
Enterprise AI stacks have two dependency graphs that traditional tooling manages poorly: the Python package graph (managed by pip/poetry/conda) and the AI component graph (models, plugins, data connectors, orchestration frameworks). Standard dependency scanners cover the first graph. The second graph requires purpose-built governance.
AI component graph governance: Maintain a formal inventory of every AI component: model API dependencies (provider, model string, DPA status, last scan date), plugin/tool dependencies (tool name, version, tool permissions, last security review), data source dependencies (source name, trust classification, last validation date), and orchestration framework dependencies (package name, pinned version hash, security scan status). This is the AI SBOM — the governance artifact that maps the entire AI dependency graph and enables rapid impact assessment when any component is compromised.
Transitive dependency visibility: AI orchestration packages (LangChain, LlamaIndex, AutoGen) have deep transitive dependency trees. A compromise in a transitive dependency — a package that LangChain depends on, but that your team never explicitly installed — can affect your AI system without appearing in a first-level dependency scan. Use dependency tree analysis tools that surface the complete transitive dependency graph, and maintain alerts on any transitive dependency associated with AI framework packages.
Plugin execution sandboxing: AI agent plugins should run in isolated execution environments with explicit permission grants — not in the same process as the AI agent. Each plugin gets only the permissions required for its function: a calendar plugin gets calendar read/write, not filesystem access. Plugin execution sandboxing ensures that a compromised plugin cannot access resources outside its declared permission scope, limiting the blast radius of a plugin supply chain attack.
The agentic runtime governance that enforces plugin permissions at runtime: AI Autonomous Agentic Runtime Governance: Complete Enterprise Control Guide →
Model Registry:
AI CI/CD:
Drift detection:
Dependency governance:
The risk classification framework that determines governance depth for each AI component: AI Risk Classification: The Complete Enterprise Governance Guide →
Integrate the 4-gate AI CI/CD security pipeline — HexTyx adversarial scan + SARIF output + calibration seeding — into your GitHub Actions or GitLab CI in under 15 minutes.
Set Up Advanced AI Security Gates →