A DevSecOps checklist for AI-powered applications

An AI-powered application is still an application — it needs the same secure-by-default controls as anything else you ship. But it also adds a few new surfaces: model artifacts, prompts, embeddings, and the data you evaluate against. Here is the checklist we run through, written to slot into an existing DevSecOps pipeline rather than replace it.

Treat models and prompts as artifacts

• Pin model and tokenizer versions; an unpinned upgrade can silently change behavior and cost.
• Version prompts in the repo and review changes like code — they are part of your logic.
• Generate an SBOM that includes model dependencies, not just your package manifest.

Put guardrails at the edges

Assume both the input and the output can be hostile. Untrusted text — whether typed by a user or pulled from a retrieved document — should never be trusted as an instruction, and generated output should be validated before it reaches a downstream system or another user.

• Validate and constrain inputs; defend against prompt injection from user and document content.
• Filter and schema-check outputs before they hit a database, an API call, or the UI.
• Redact PII on the way in and the way out; keep the redaction logic testable.
• Rate-limit per tenant and per key to bound both abuse and runaway cost.

Make it observable and auditable

When something goes wrong with an AI feature, you need to reconstruct exactly what happened. Log the prompt, the retrieved context, the tool calls, and the response — with redaction — so an incident is a query, not an archaeology dig.

• Trace tool/function calls the model makes, with inputs and outputs.
• Monitor token spend as a first-class metric and alert on anomalies.
• Keep an audit trail you can replay for compliance and postmortems.

The goal is not to slow teams down with a security gate. It is to make the secure path the easy, default path — wired into the pipeline once, so every feature inherits it.