How to integrate AI security into the development and deployment lifecycle — model registry security, CI/CD gates for AI, dependency management, drift monitoring as a security signal, and the complete DevSecOps checklist for AI systems.
Traditional DevSecOps shifted security left — into the development pipeline, not just production monitoring. The principle is sound for AI systems too, but the implementation is different. For a traditional application, "security in the pipeline" means SAST, dependency scanning, and container vulnerability checks. For an AI system, it additionally means: adversarial testing before deployment (HexTyx scan as a CI/CD gate), model provenance verification (ensuring the model being deployed is the one that was tested), prompt change validation (every system prompt change triggers a re-scan), and behavioral drift monitoring in production (detecting when the deployed model's behavior diverges from the tested baseline).
The AI DevSecOps lifecycle has three phases that traditional DevSecOps doesn't: the model selection/training phase (before any code is written), the prompt engineering phase (where security properties are established in the system prompt), and the production drift monitoring phase (where model behavior must be continuously validated against the tested baseline). Ignoring any of these phases creates security gaps that code-level controls cannot close. The automated testing foundation: Automated LLM Security Testing: The Complete 2026 Guide →
AI systems have a supply chain: the base model, fine-tuning datasets, embedding models, and any third-party model APIs. Each supply chain component is a potential attack vector. AI supply chain security is an emerging discipline, but several controls are available now:
Model provenance verification: Before deploying any model (including model API calls to Anthropic), verify the model version is the one that was security-tested. Anthropic model strings (e.g., claude-sonnet-4-20250514) are immutable — a change in model string means a different model that requires re-testing. Version-pin all model API calls in production configuration and treat a model version change the same as any other dependency upgrade: re-run the full security test suite.
Fine-tuning data validation: If using fine-tuned models, the fine-tuning dataset is part of the supply chain. A fine-tuning dataset that contains adversarial examples — even inadvertently, through compromised data sources — can shift the model's behavior in ways that create new vulnerabilities. Validate fine-tuning datasets for injection patterns, adversarial content, and data provenance before training. The same ingestion validation controls applied to RAG pipelines (Stage 1 of the RAG security guide) apply to training data.
Third-party plugin and tool security: AI agents that use third-party tools (via plugins, MCP servers, or API integrations) inherit the security posture of those tools. Every third-party tool added to an agent's tool manifest extends the attack surface. Before adding any tool: review the tool's security documentation, test IDOR and injection resistance of the tool's API, and document the tool in the AI System Inventory with its risk classification.
System prompt changes are equivalent to code changes in AI systems — they change the system's behavior, and that behavior change can introduce new vulnerabilities. Every system prompt change should trigger a re-scan before deployment. Most teams don't do this because the process isn't automated. The solution is integrating system prompt change detection into the CI/CD pipeline:
# In your CI/CD pipeline — detect prompt changes and trigger re-scan
if git diff HEAD~1 HEAD -- prompts/ | grep -q "^+"; then
echo "System prompt changed — triggering security re-scan"
hextyx scan --target $AI_ENDPOINT --fail-on-risk 70 --fail-on-bypass 50% --format sarif
fiThis pattern ensures that every system prompt commit goes through the same adversarial testing gate as every code commit. A prompt change that increases the bypass rate above 50% on any mutation strategy blocks the deployment — the same way a critical CVE in a dependency blocks a code deployment.
The full CI/CD gate configuration: AI Security Testing Pipeline: Step-by-Step Enterprise Guide →
AI systems have two dependency layers that traditional DevSecOps tools don't cover: model API dependencies and knowledge base content dependencies. Both require active management:
Model API dependency management: Create a model version lock file — the AI equivalent of package-lock.json. Every model API call in production should specify a version-pinned model string. Any model version upgrade is a controlled change that requires re-running the security test suite against the new model version. Upstream model providers regularly update models; without version pinning, a silent model upgrade can change the system's security properties.
Knowledge base content dependency management: Every data source that feeds your RAG knowledge base is a content dependency. Maintain a manifest of all content sources with their last validation timestamp, last ingestion timestamp, and validation status. This manifest is the RAG equivalent of a dependency lock file — it tells you exactly what is in the knowledge base and when it was last validated.
Traditional dependency security: Standard dependency scanning (Dependabot, Snyk, OWASP Dependency Check) applies to the AI application infrastructure — the Python dependencies for FastAPI, the vector database client libraries, the embedding model SDKs. These are normal software dependencies that carry normal CVE risk. Run them in the same pipeline as the AI-specific security tests.
Model drift is usually discussed as a performance problem — the model's outputs diverge from expected quality over time. From a security perspective, drift is also a signal that the security baseline has changed. A model whose behavior has drifted may have different vulnerability characteristics than the model that was security-tested at deployment.
Behavioral drift detection with Aegis: The Memory Graph's cross-model transfer detection and novel cluster emergence signals serve as production drift indicators. If the attack cluster distribution in the Memory Graph changes significantly — new attack clusters forming, existing clusters becoming more active — it signals that the threat landscape or the model's responses to it have changed. This triggers a re-scan.
Bypass rate trend monitoring: Track bypass rate as a longitudinal metric, not just a point-in-time scan result. A bypass rate that is increasing over time — even if each individual measurement is below the alert threshold — signals that the model's defenses are eroding. The calibration loop's history endpoint (GET /gateway/calibration/history) provides the longitudinal record.
Semantic response consistency testing: Include a set of canary prompts in your production monitoring — prompts that should always produce the same category of response. If canary prompt responses start changing, it signals model drift that may require a re-evaluation of security properties.
The pre-deployment audit guide that establishes the baseline for drift comparison: How to Audit an AI Model Before Deployment: Complete Enterprise Guide →
┌─────────────────────────────────────────────────────────────────────┐
│ AI DevSecOps Pipeline │
├───────────────┬──────────────┬───────────────┬──────────────────────┤
│ Supply Chain │ Development │ Pre-Deploy │ Production │
├───────────────┼──────────────┼───────────────┼──────────────────────┤
│ Model version │ SAST on AI │ HexTyx full │ Aegis runtime │
│ pinning │ application │ 21-category │ monitoring │
│ │ code │ scan │ │
│ Fine-tuning │ │ │ Calibration loop │
│ data │ Dependency │ CI/CD gate: │ (weekly minimum) │
│ validation │ scanning │ --fail-on- │ │
│ │ (Snyk/ │ risk 70 │ Bypass rate trend │
│ Plugin/tool │ Dependabot) │ --fail-on- │ monitoring │
│ security │ │ bypass 50% │ │
│ review │ Prompt │ │ Novel cluster │
│ │ change │ SARIF → CI │ alerting │
│ Content │ detection │ security tab │ │
│ source │ → auto │ │ Drift detection │
│ validation │ re-scan │ Evidence │ (canary prompts) │
│ │ │ package gen │ │
└───────────────┴──────────────┴───────────────┴──────────────────────┘The risk classification framework that determines how much DevSecOps rigor each AI system requires: AI Risk Classification: The Complete Enterprise Governance Guide →
The agent security controls that complement the DevSecOps pipeline: AI Agent Security: Preventing Goal Hijacking and Privilege Escalation →
Set up the HexTyx CI/CD gate in under 10 minutes — automatic security scanning on every AI deployment, SARIF output to GitHub/GitLab Security, and deployment blocking on risk threshold breach.
Set Up AI DevSecOps Gate →