Shipping AI features fast
Your old gates caught bad code.They never watched for how AI breaks.
A gate is a checkpoint where an artifact must pass defined checks, and emit evidence, before it may proceed. Classic DevSecOps gated one artifact type: code, its containers, its infrastructure. AI changes the picture in two ways at once, and this framework keeps them deliberately separate. AI works the gates (agents now assist or run the checks) and AI passes through the gates (models, prompts, agents, and tools now flow down the pipeline as new artifact types). So every gate here has three lanes.
Everyone gates code. This pipeline also gates models, prompts, agents, and tools, for security, safety, and privacy, with the same evidence discipline.
A framework model (v0.2), prescriptive rather than measured. It maps to public frameworks: OWASP DSOMM, Cloud Security Alliance (CSA) AI Controls Matrix (AICM) / AI Security Maturity Model (AISMM), SLSA, and EU AI Act risk categories. The play that runs these gates is in the catalogue as ai-sdlc-tollgates →
DEVSECAIOPS · GATE FRAMEWORK · v0.2
Eight gates. Three lanes. Three lenses.
Every gate checks code, AI systems, and AI artifacts, for security, safety, and privacy.
Design
PLAN · before any code or model work begins
Pre-commit
WORKSTATION · before code enters the repo
Source
COMMIT · PR · on every push and pull request
Build
ARTIFACT · producing the deployable thing
Test
VERIFY · evals are to AI what unit tests are to code
A model can pass security red-teaming and still fail its fairness threshold. Each eval suite blocks independently.
Deploy
ADMISSION · into the runtime environment
Permission manifest compiled to enforcement. Kill-switch verified before go-live.
Human-in-the-loop checkpoints for consequential decisions; DPIA sign-off as an admission condition.
Retention and data-residency config verified; model card published (tri-lens: security, safety, privacy).
Runtime
CONTINUOUS · not a one-time checkpoint
Agent behavior monitored against the manifest; drift from declared scope is an incident. Shadow-AI sweep.
Harm monitoring with an incident taxonomy, a user feedback channel, periodic eval re-runs.
Personal information (PII) egress classification, DSAR readiness, retention enforcement as a continuous check.
Attest
MEASURE · closes the loop, feeds the next Design gate
Maturity per gate: exists → automated → blocking → evidence-mapped → measured
Three lanes, one pipeline.
Each gate asks the same question three times, once per lane. Most repositories cover only the first. Within the third lane, every check is evaluated again across three lenses: security, safety, and privacy. Putting all three lanes, and all three lenses, in a single pipeline view is what this framework is for.
L1 · Lane
Classic
Is the software artifact safe to proceed?
DevSecOps baseline
L2 · Lane
AI-augmented
Is AI helping run this gate, and is that itself governed?
AI for Security
L3 · Lane
AI artifacts
Are the AI artifacts (model, prompt, agent, tool, data) safe to proceed, across every lens?
Security for AI · Security from AI · checked for security, safety, and privacy
The eight gates.
Design to Attest. Each card reads top to bottom as the three lanes, then the evidence the gate emits for the attestation loop. The coral lane (L3) is the part classic pipelines never defined.
G0
Design
Plan
Before any code or model work begins.
L1
Threat model exists for the change; security requirements defined; abuse cases documented.
L2
AI-assisted threat modeling permitted with human sign-off (STRIDE plus agentic extensions such as MAESTRO). The AI output is reviewed, never auto-accepted.
L3
AI use-case risk classification (EU AI Act category, internal tier); data-governance decision on what may train or ground the system; and the AI-vs-human allocation decision recorded before build. This is designed AI adoption, not bolted-on.
Evidence emitted
Threat model doc, risk classification record, allocation decision record.
G1
Pre-commit
Workstation
On the developer workstation, before code enters the repo.
L1
Pre-commit hooks; secrets scanning (no credentials in code); linting.
L2
If a coding agent authored the change, its session is attributable: which agent, which prompt, which human requested it.
L3
Prompt hygiene: no secrets, personal information (PII), or internal identifiers in system prompts, agent instructions, or skill files. Prompt and skill files linted against schema.
Evidence emitted
Hook logs, secret-scan pass, agent attribution metadata.
G2
Source
Commit · PR
On push and pull request.
L1
SAST; dependency and SCA scanning; license compliance; IaC scanning.
L2
AI code review runs as advisory (agent suggests, human approves). AI-generated code is flagged and gets the same or stricter scrutiny, never less.
L3
AI-BOM / MLSBOM generated and diffed: models, datasets, embeddings, prompts, and agent tools declared like dependencies. Skill and MCP-tool supply chain checked (SkillBOM/ToolBOM: lockfiles, pinned versions, admission policy). Dataset provenance and poisoning checks on any training data.
Evidence emitted
Scan reports (SARIF), AI-BOM artifact, tool lockfile diff.
G3
Build
Artifact
Producing the deployable thing.
L1
Container and image scanning; artifact signing (Sigstore); SLSA provenance attestation; reproducible build checks.
L2
Build-time agents run in isolated, ephemeral environments with read-only defaults. Any write is buffered through safe outputs: typed, limited, sanitized, never direct.
L3
Model artifact scanning (unsafe serialization such as pickle exploits); model signing and provenance verification (the model deployed is the model approved); guardrail configs and system prompts versioned and packaged with the artifact.
Evidence emitted
Signed artifact digest, SLSA attestation, model signature verification log.
G4
Test
Verify
Verification before release.
L1
DAST; IAST; integration security tests.
L2
AI-driven test generation and fuzzing permitted; results triaged with human confirmation for severity high and above.
L3
AI evals as release-blocking tests: prompt-injection and jailbreak suites; guardrail effectiveness tests; agent behavioral evals against the permission manifest; tool-poisoning tests for MCP integrations. Evals are to AI what unit tests are to code.
Evidence emitted
Eval scorecards with thresholds, red-team test reports, guardrail test results.
G5
Deploy
Admission
Admission into the runtime environment.
L1
Policy-as-code admission control (OPA/Kyverno); change approval; environment segregation.
L2
Deployment agents act under least-privilege, task-scoped, expiring credentials (non-human identity discipline). No standing agent credentials.
L3
The agent permission manifest is the deployment contract: declared tools, data scopes, network egress, spend and rate caps compiled into enforcement, not documentation. Human-in-the-loop checkpoints for irreversible actions; model card published; kill-switch and rollback path verified before go-live.
Evidence emitted
Admission policy decision log, signed permission manifest, published model card, rollback test record.
G6
Runtime
Continuous
Continuous, not a one-time checkpoint.
L1
Monitoring and alerting; WAF; CSPM; vulnerability-management cadence.
L2
Agent-assisted Security Operations Center (SOC) (triage, fusion, investigation) with an auditable investigation ledger. AI conclusions are traceable to evidence.
L3
Runtime guardrails on inputs and outputs (injection detection, PII-egress classification); agent behavior monitored against the manifest (drift from declared tools or scopes is an incident); MCP and tool-call telemetry across trust boundaries; shadow-AI discovery; periodic re-run of the G4 evals against the live system.
Evidence emitted
Guardrail block/allow logs, manifest-drift alerts, eval re-run results, shadow-AI inventory.
G7
Attest
Measure
The gate that closes the loop, and the one this practice owns.
L1
Evidence from G0 to G6 aggregated; audit trail complete; DSOMM-style activity levels updated.
L2
AI-generated assessment narratives are drafted by the agent, attested by the human. The signature is human.
L3
Gate evidence mapped to control frameworks (Cloud Security Alliance (CSA) AI Controls Matrix (AICM) controls, AI Consensus Assessments Initiative Questionnaire (AI-CAIQ) answers) and maturity instruments (CSA AI Security Maturity Model (AISMM) level, DSOMM level). Slope is measured, not just state: is gate coverage moving toward engineering-excellence, or is only adoption volume rising?
Evidence emitted
Control-mapped evidence bundle, maturity scorecard with baseline and trajectory.
The gate contract.
Every gate, in every lane, is defined by the same six fields. This is the uniform schema that makes attestation possible: define the trigger and the checks, then emit evidence the loop can measure.
Trigger
The pipeline event that invokes the gate: PR opened, artifact built, deploy requested.
Artifacts in scope
code · container · IaC · model · dataset · prompt · agent · tool/skill.
Checks
The specific verifications, each mappable to a skill in the library.
Pass criteria
Objective thresholds: no criticals; eval score at or above X; signature valid.
Evidence emitted
What the gate produces for G7. This is what makes attestation possible.
Break-glass
Who may override, under what conditions, with what logging. An ungated override path is how gates die in practice; an honest framework defines it.
Two overlays: how a gate matures, and how it hardens.
Maturity is DSOMM-style: each gate, in each lane, climbs a five-step ladder. A gate that merely exists is not the same as one whose effectiveness is measured.
Hardening is the rule this practice cares about most: the more autonomous the AI at a gate, the stronger the human attestation the gate demands. The gate is the same; the enforcement scales with the AI Cyber Maturity Model (AI-CMM) autonomy tier (our model · calibrated to SAE J3016).
| AI-CMM tier | Enforcement | Attestation |
|---|---|---|
| Assisted | Advisory: the gate runs, surfaces findings, never blocks. | Reviewer acknowledgement; no signed attestation required. |
| Augmented | Blocking with override: a named reviewer can override with a recorded justification. | Override is auditable; the AI-use policy names who may override. |
| Autonomous | Hard-block: the gate stops the change; no PR-level override. | Mandatory human attestation by an accountable owner before the change proceeds. |
The worked example.
Gate G4, lane L3, security lens (prompt-injection and jailbreak evals as a release-blocking test) already has a modeled worked example in the case-study library. A children’s-storybook app was fitted to its own attack classes and taken from a 53% baseline catch-rate to 100% fitted, held-out 5/5. Modeled, not measured. Same shape as the gate.
Not your role?
Each role has its own way in. Here is where the others start.