Securing AI-DLC: Process Integrity Is Not Product Security

That gap is the subject of this post. But the gap only makes sense if you know what the methodology actually does, so let me start there.

What AI-DLC is

The AI-Driven Development Life Cycle is an AI-native methodology published by AWS as an open-source set of workflows. The full rule set, the phase definitions and the extension mechanism are public in awslabs/aidlc-workflows, and everything I describe below is drawn from that repository rather than from any engagement.

Its starting position is that the two common ways of using AI in delivery are both wrong. Treating AI as an assistant — completion, docs, tests — leaves your process untouched and therefore leaves the inefficiency untouched. Treating AI as autonomous and asking it to produce an application from a requirements document fails for the opposite reason: the model has no access to the business context that determines whether an answer is correct.

AI-DLC takes a third position. AI is a structured collaborator operating inside a defined process, and the process itself is rewritten around that. One loop does the work, and it repeats for every activity in the lifecycle.

Three things about that diagram carry most of the methodology’s weight.

The loop always ends with a human. The agent drafts, asks structured clarifying questions, gathers context, and then stops. It cannot self-approve, cannot skip a stage, and cannot proceed on ambiguity. Two outcomes exist at a gate: approve, or request changes.

Depth adapts to risk. A bug fix skips the design ceremony and goes almost straight to code. A new customer-facing service runs the full set. The workflows even ship a dedicated CVE-response scope that documents not only which stages run but why the others are skipped — which is a level of explicitness about process decisions I wish more methodologies had.

Context persists in the repository. Plans, requirements, designs and an append-only audit trail live as markdown alongside the code. The phases are cumulative: Inception decides what and why, Construction decides how, Operation runs it, and each hands the next a richer record. Work is organised into units of work rather than epics, and cycles are bolts — hours or days — rather than multi-week sprints.

The mechanism underneath all of this is worth naming, because it is what makes security tractable later: the governance is not a wiki page. It is machine-readable rules in the repository that constrain the agent’s behaviour, plus deterministic checks that fire at stage gates.

Two properties, one word

Now the gap.

AI-DLC is unusually strong on process. Artefacts carry stable identifiers, so a requirement traces to a story, to an acceptance criterion, to the code — with gaps and orphans reported by name rather than by vibe. At each phase boundary the method re-verifies that chain before the next phase begins. Every input, decision and approval lands in the audit trail with a timestamp.

That is a better decision record than most regulated programmes I have audited produce by hand.

It is also entirely a claim about method.

Process integrity answers did a human decide, and can I prove it. Product security answers is the thing we built actually safe. Reading the first as the second is a category error, and a comfortable one, because the first produces evidence while the second produces work.

None of this is a criticism of the methodology. It never claimed to be a security product. It claims to be a process with well-defined places to attach governance — and that is exactly what makes the attachment worth designing properly.

Why a faster review does not close it

The reflex is to keep the existing security review and try to speed it up. That reflex misdiagnoses the problem.

A security review is a statement about a specific artefact at a specific moment, and its value decays as the artefact changes. Traditional delivery worked because the artefact was stable for months while the review took weeks — the verdict was still true when it landed. Bolts invert the arithmetic.

Which is why cutting a four-week review to one week buys nothing structural. You improved a number without crossing the threshold that matters. The fix is continuous validation of properties that stay true as the artefact moves.

Security at each phase

So here is the overlay, mapped onto the three phases rather than bolted alongside them. Each addition attaches to a place the methodology already has, and each one buys a specific property.

Inception — put the threat model before the code. Security tenets are opted in during requirements analysis, as blocking rules rather than advice. The threat model is generated and then walked with the customer’s own technical leads: STRIDE for the conventional components, and an agent-aware method for the parts where the threats are prompt injection, tool misuse and autonomous escalation. Data classification lands in the non-functional requirements, where it can drive design, instead of arriving as a finding later.

The property this buys is not a document. It is that the team enumerating the threats is the team that owns the system — and nobody argues about a mitigation for a threat they identified themselves.

Construction — validate continuously, block never. The threat model goes into the coding agent’s context, because a threat model nobody reads at the moment of writing is a filing exercise. Validation runs on file save and returns a specific line and a specific fix. Static analysis runs on commit, in the background, with zero builder involvement until a finding is calibrated. Adversarial testing runs against the running build before production.

The design decision that gets argued most is that none of this blocks the commit. The reasoning: blocking during active development reintroduces exactly the friction the team just paid to remove, and the reliable outcome of friction is that your control gets routed around. Surface the issue; keep the commit.

The rule that spans all of it: a human calibrates findings before they can block. False positives are not an irritation, they are a control failure. The first unearned block teaches the team your findings are noise, and you do not get that credibility back cheaply.

Operation — one gate, then a loop. After continuous validation there is exactly one hard gate: no unresolved critical or high findings reaching production. Adversarial testing continues against the running system. And every production finding is promoted into the methodology’s own guardrail mechanism, so a correction becomes permanent rather than becoming a retrospective action item.

Three layers, three questions

Stepping back, the overlay above is one of three layers, and separating them by the question each answers has ended more circular arguments for me than any other framing.

Layer 1 is procedural and free — take it, rely on it for evidence, and stop there. Layer 3 is architectural and well documented: scoped identity per agent, policy-mediated delegation so authorisation cannot expand along a chain of agents, schema validation, guardrails. AWS has published prescriptive guidance for least privilege in agentic workflows and guardrails and alignment controls, and the load-bearing sentence in that material is the one I quote most often: instruction-following alone is not enforcement.

Layer 2 is the gap, and the only layer that answers whether the artefact in front of you is safe today.

Write the control as a sensor, not as a paragraph

The most under-appreciated thing in the methodology is that it already contains the right unit of enforcement, and it is not prose.

AI-DLC ships sensors: deterministic checks with a declared severity that fire at a stage gate and emit a named failure. One of them refuses to close a stage when any substantive claim in a document lacks a resolvable source tag. That is provenance enforced as a check rather than requested as guidance.

So express your security bar in that shape: deterministic, gate-bound, named on failure, traceable back to the requirement that motivated it. It inherits enforcement the method already has, and it becomes reviewable and diffable like any other rule.

The alternative — which I see constantly — is a long prose section in a steering file describing good security practice. That is a promise. A sensor is a constraint. I have written about that distinction at the tool boundary; it holds just as sharply at the process boundary.

Right-sizing follows the same precedent. Copy the discipline of that CVE-response scope: a prototype gets tenets and static analysis; a customer-facing GenAI service gets adversarial testing and agent-specific threat modelling. One security configuration for every service produces theatre in the cheap cases and gaps in the expensive ones.

Earn the right to block, then block once

One gate is a deliberate quantity. Gate everywhere and approvals become reflexive. Gate nowhere and you are shipping on optimism. Place it at the point of no return and it keeps its meaning.

Where this costs you

Someone owns the sensors, and that someone is senior. You have converted review hours into maintenance of a rule set — a better trade, not a free one, and now visible to whoever plans capacity.

Non-blocking validation means a determined team can ignore inline findings all the way to the gate and then hit a wall. The mitigation is not to start blocking earlier; it is to make the gate’s contents visible from the first day of the bolt.

Generating a threat model per unit of work produces more threat models than anyone will read. Without calibration they become the security equivalent of an unowned alert channel.

And the whole argument assumes the cadence is genuinely fast. If your team ships quarterly, the shelf-life problem does not apply to you, a conventional review is fine, and this design is overhead I would talk you out of.

How you know it is working

Not from the finding count. Two tells.

Your security engineers stop reviewing code and start editing sensors and threat models. That is the time-allocation shift the whole design exists to buy, and it is the hardest part organisationally — a re-skilling problem wearing an automation problem’s clothes.

And when someone asks whether a service is secure, nobody reaches for the audit trail. They reach for the outcome coverage and the open findings, and they can tell you which of the two questions they are answering.

The methodology described here is public: see awslabs/aidlc-workflows for the workflows, phase definitions, scopes and sensors, and the AWS guidance linked above for the runtime layer. The three-layer split, the shelf-life argument, the per-phase overlay and the control-as-sensor recommendation are my own positions, developed on GenAI delivery programmes with automotive and financial-services customers. They are opinions, not anyone’s official guidance.