Forty agent runs finished overnight across six repositories. Something approved them. Something decided which ones needed a human first. Show me the thing that decided, show me who is allowed to change it, and show me how you would know if somebody had.

That third question is the one I cannot get a good answer to, and it has very little to do with compliance. It is the plain operational question: what is your list of checks, and what stops somebody editing it?

If you are new to this: AI-DLC is a way of running delivery where AI agents do the building inside a defined process, with people at fixed decision points. I have written about what it is and how to secure it. This post is about the platforms now being built to run it — one in particular — and the governance layer they are missing.

8guardrails we proposed
2that the platform implements
0checks covering the checks themselves

Somebody has already built most of this

AWS has shipped a genuine attempt: Collaborative AI-DLC. It is a sample project in early preview, and I am going to be critical of it — which is a compliment, because it is the first thing in this space good enough to be worth criticising properly.

What it is, in plain terms: a layer that sits on top of coding agents and coordinates them. You write an intent. The system turns it into a plan, walks through the stages, and runs a coding agent in an isolated sandbox for each one. Agents write their outputs into a shared graph rather than into a chat window, so nothing is lost when a session ends. The platform owns all the git operations. People answer questions, approve things, and can steer a run while it is going.

The part that made me sit up is that they built the thing I have been arguing for:

Three panels describing the platform's safety nets — automatic checks in green, a second AI reviewing in blue, a person approving in violet — each with what it is good at and what it is blind to.
Three nets that miss different things is exactly the right shape, and it is more than most organisations run today. Description follows the project’s own documentation.

Three independent safety nets on every step. Ambiguity stops the run instead of being guessed at. Full traceability from requirement to code. Cost, duration and token usage broken down per step.

That is serious design. If you are choosing something today, choose this shape. What follows is not a reason to avoid it — it is the list of things you will have to add yourself.

Marking our own homework

Rather than inventing a fresh list of complaints, the fair test is the one we already published. In the earlier post I proposed a set of security additions to AI-DLC, each buying a property you can name. A platform implementing the method is exactly where those should show up.

So let me mark my own homework against what shipped.

Eight proposed guardrails with a status: threat modelling up front absent, blocking security rules in requirements absent, continuous checking partial, human tuning of noisy checks absent, one hard stop partial, production findings becoming permanent checks absent, the control written as an automatic named check present, and reviewable and diffable like any other rule absent.
Green is present, amber partial, red absent. Status is my reading of public documentation on an early preview — I would be glad to be told I have misread a row.

Two arrive. The rest are worth taking in order of what they cost you.

There is no operations phase. The lifecycle runs through planning, building and delivery, and then stops at the pull request. But the methodology it implements carries on past that point, and that is where the most valuable rule lived: every problem found in production becomes a permanent new check, so a fix stops being a one-off. Without that loop, the platform cannot learn from its own incidents. Ever.

Checks run at the gates, not continuously. A verdict that arrives after the thing it judged has changed is not a slow verdict, it is an invalid one. Checking at step boundaries is better than nothing and it reimports that problem in miniature.

Nobody can tune a noisy check. Checks pass or fail. There is no documented way for a person to calibrate one before it starts blocking people. That rule mattered most of all in the original post, because a false alarm is not an irritation — it is a control failure, and the first unearned block teaches a team that your findings are noise.

No threat modelling up front, and no security dimension to the scopes. The good news here is structural: this is a workflow built from composable blocks, so a threat-modelling step is an addition rather than a redesign.

Now the row that matters most, and the reason this section sits where it does. The guardrail they implemented best is the automatic check — deterministic, tied to a gate, named when it fails, exactly as argued. But that recommendation had a second half: that a control in that shape “becomes reviewable and diffable like any other rule”. That half did not arrive, and it turns out to be the hinge of everything else.

So: who approves a change to the approval gate?

Here is the sentence, from the project’s own documentation, that the rest of this post hangs on:

The workflow is assembled from a library of building blocks — steps, agent personas, rules, the checks themselves, scopes — and platform administrators can, in the documentation’s words, “fork blocks and compose custom workflows in the visual composer”.

For an engine that runs work, that is a feature, and a good one. You can change how work flows without a redeploy. For the thing that defines your controls, it is the entire problem.

Top in green: the governed path — intent, step, check, AI review, person approves, pull request, merge — all checked and traceable. Bottom in red: the ungoverned path — an administrator opens the composer, forks a block, edits the workflow — with an arrow showing it decides which checks exist at all.
Read them as one system. The red path has authority over the green one and less change control than editing a README.

Every change to your product goes through that carefully built pipeline. The change that decides which checks exist goes through an admin screen. No pull request. No second approver. No record in the traceability graph of the very system it governs.

Which means the honest answer to “is this step checked?” is not “yes”. It is “yes, as of the last time somebody looked, and I could not tell you if that has changed.”

I have written before about a control that existed, was reviewed, and had never once actually taken effect. This is the same family one level up. There, the control did not work. Here it works beautifully and can be quietly removed by anybody with an admin role — and the removal leaves no trace in the system built specifically to leave traces.

Three more gaps, in descending order of cost

The agents share one key. Agent credentials live in a parameter store, separate from user logins. The sandboxes are isolated, which is good, but the credential is common to all of them. So the graph can tell you which step produced which artefact, and cannot tell you which agent identity acted under whose delegated authority.

That is exactly what regulators have started naming. Singapore’s framework for agentic AI, published in January 2026 and the first written specifically for agents, asks that each agent carry a verifiable identity and an audit trail of which agent acted under whose authorisation. The Cloud Security Alliance’s research on the gap puts numbers on the distance: 92% of organisations lack full visibility into their AI identities, and 95% doubt they could detect or contain a compromised agent.

A traceability graph is not evidence. The graph is excellent for navigation — follow a requirement to the code that implements it. But it can be written to, the platform writes to it, and there is no documented export or signature. In an earlier post I drew the line between a transcript and an action log: one is context, the other is evidence. This is the richest context I have seen in this space, and it is still context.

Cost is measured; authority is not. This one is almost funny, and it shows exactly what organisations measure by default.

Left in green, measured today per step and per intent: how long the step took, words in, words out, cost at today's prices, did the check pass. Right in red, measured nowhere: what it was allowed to touch, which repositories it could write to, which secrets it could read, whose authority it acted under, how bad it would be if hijacked.
A finance dashboard grew around agent runs before a security one did. Tokens have a price; authority does not, so nobody built the meter.

You can see to the cent what a piece of work cost. You cannot see what it was allowed to do. And the reach of a run is perfectly computable — it is just the sum of what each step could touch. Putting that number next to the money would change more design conversations than any policy document I could write.

What the tool has to become

Not a replacement. A second layer alongside the first, mostly built from things we already know how to do.

Top in green: the layer that runs the work — orchestrator, agent runs, typed artefacts, traceability graph, automatic checks, AI review, human gates, cost metering — described as largely solved. Bottom in amber: the layer that governs it, with six requirements — the workflow lives in git, an identity per run, authority on every action, a write-once record, reach as a number, re-checking triggers.
Four of the six are things we already demand of any system that touches money. We are not yet demanding them of the system that writes the system.
  1. The workflow lives in git. Reviewed in a pull request, signed, and pinned when it runs. A change to a check is itself a checked change. Everything else here is optional; this is not.
  2. An identity per run. Short-lived, attributable, scoped to the piece of work. Never one shared platform key. You want to be able to say this run, acting for this person, could do these things for eleven minutes.
  3. Authority recorded on every action, not just the action. The chain of who allowed what is the thing an incident needs and an auditor asks for.
  4. A write-once record, separate from the working graph, exportable and signed.
  5. Reach as a number, shown beside the cost, per step and per intent.
  6. Re-checking triggers. When the workflow changes, everything approved under the old one is unverified until somebody says otherwise.

Number one is a repository and a branch protection rule. You could do it this quarter.

Where this costs you

Putting the workflow in git slows down workflow changes. That is the entire point and people will still find it annoying. A team that could retune a step in ninety seconds now waits for a review. Expect somebody to ask for “small” changes to be exempt, and expect that exemption to be where your next incident comes from.

An identity per run is real work in your identity system, and that system then sits on the critical path for delivery. Easily the most expensive item here.

And for a small team shipping something with a small blast radius, most of this is overhead. If your agents cannot reach production data or move money, run the platform as it ships, put the workflow in git, and skip the rest until something changes. Governance proportional to consequence, as always — applying all six to an internal tool is theatre, and theatre teaches engineers that security advice does not distinguish between cases.

What I would do on Monday

  1. Find the artefact that defines your checks and put it under change control. Whatever your platform, something somewhere is that list. Find it, commit it, protect the branch, require a second approver. If it lives in a database behind an admin screen, export it nightly and diff it — a poor version of the right answer that takes an afternoon.
  2. Work out the reach of one intent by hand. Add up what every step could touch. Show the number to the team that owns it. I have never seen that fail to change somebody’s mind.
  3. Ask who has the admin role, and whether that list is the same as the list of people you would let delete a production gate. It usually is not.

Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, citing rising costs, unclear value, and inadequate risk controls. I suspect the third causes the second: programmes that cannot show what their agents were allowed to do struggle to defend the spend, and programmes that cannot defend the spend get cancelled.

The thing I keep coming back to

We built a whole generation of tooling to make software delivery legible to the people paying for it. Tickets, boards, burndowns — all so that somebody who was not there can find out what happened.

The agentic version of that problem is harder and more interesting, because the thing that needs to be legible is not progress any more. It is authority: what was permitted, by whom, under which rule, and whether that rule was the one you thought it was.

Collaborative AI-DLC gets you most of the way and leaves the last door open. For an early preview of a sample, that is a perfectly reasonable place to stop. It is not a reasonable place for you to stop, because that door is in your build pipeline now.

Put the workflow in git. Everything else on the list is a project; that one is an afternoon, and it is the difference between having a gate and having a rumour about a gate.

Sources, and what each is good for

  • Collaborative AI-DLC and its documentation — AWS Samples. The platform discussed throughout, and the source of both quoted phrases. Early preview: read the code before pointing it at production repositories.
  • Model AI Governance Framework for Agentic AI — Singapore IMDA, January 2026. The first regulatory framework written for agents rather than models, and the clearest published statement of what an agent audit trail should contain.
  • The AI Agent Governance Gap — Cloud Security Alliance. Where the identity statistics come from, and a good account of why existing AI frameworks do not reach autonomous agents.
  • Gartner on agentic AI cancellations — June 2025. More useful for the stated causes than the headline number.

I write about this work as it develops. If you are standing up governance for one of these programmes, I am reachable on LinkedIn, and the tooling I maintain lives under shenril and BlueSquadron.