Security and the Inner Development Loop

It's no secret that AI is changing how software is created, but what does that mean for securing the software delivery part of the SDLC?

For years, a secure SDLC has mostly assumed that meaningful security validation begins once code reaches source control. A developer writes code, commits their changes, opens a pull request and the familiar controls follow:

• SAST
• SCA
• Secrets Scanning
• IaC
• Dynamic Testing
• CI/CD policy

This still works (for now)...but what has changed within agentic workflows is much more now happens before a commit exists.

Modern AI coding agents don't generate code in a single step. Rather, they are given an objective, they read repository context, plan an implementation, generate code, execute commands, run tests, inspect failures, refine the solution and repeat that process until the task is complete.

For the purpose of my post I'll refer to this autonomous execution flow between developer intent and source control as the Inner Development Loop.

Drawing this out, it would look something like this:

This isn't a new SDLC, but rather an additional execution layer that now exists before source control.

I'm calling this part out because it changes where a meaningful part of engineering work now happens.

By the time a pull request is opened, an agent may already have explored multiple implementations, selected dependencies, modified infrastructure, executed tests and rewritten large parts of the codebase.

As a result, a pull request is where the outcome of that process is reviewed.

This is obviously not new as a pull request is always where the outcome of software development ends up. However, the economics are different as testing and iterations happen before this in an automated way.

What does this mean in practice?

We need to bring security testing into the Inner Development Loop.

The concept of validating changes before they reach source control in a pull request has existed for years. Many development teams use pre-commit hooks to run formatting, linting, unit tests or lightweight validation before code is committed. Some organisations have extended these hooks to include security tooling.

In practice, however, comprehensive security validation has remained centred around pull requests and CI/CD pipelines. Running heavyweight analysis locally has traditionally been slower and potentially disruptive to developer workflows, and dependent on developers choosing to execute the tooling.

Agentic development processes helps support in changing this.

An autonomous agent doesn't care whether it performs ten iterations or one hundred. Running SAST again, fixing a finding, executing another unit test or trying a different dependency is simply part of completing the task.

The controls themselves haven't changed. What executes them and when they execute has.

The objective is not to replace existing DevSecOps controls.

We must still maintain these controls within CI/CD as well, to act as final assurance for the team that will ultimately be accountable for the agentic development output.

The objective is to make them available while the agent is still working. In this scenario the result should be a much more 'complete' task outcome.

Equally, the goal is not to move every security control before the pull request. Some controls will always belong in CI/CD or production. Instead, the execution loop gives us an opportunity to run many existing controls continuously while software is being generated.

This also lines up with the wider AppSec discussion that pull requests are becoming too late as the first place to start governance in agentic workflows.

Where I’m landing is that we need a practical model for where those controls actually sit, so I've been trying to think of this in two parts.

First, preventive controls. These govern what an agent is allowed to do before it does it. This includes identity, permissions, approved MCP servers, tool access, repository scope, network access and policy enforcement.

Second, validation controls. These determine whether the thing the agent has produced is acceptable. That includes SAST, SCA, secret detection, IaC validation, unit tests, integration tests, AI assisted review and the other security checks we already expect in the SDLC.

The important bit is that these controls are no longer just gates at the edge of the workflow. Instead...

...they become part of the environment the agent works in.

This is the change I’m getting at when talking about security in the Inner Development Loop.

AI hasn’t magically changed SAST, SCA, secret scanning or CI/CD. A scanner is still a scanner and policy is still a policy.

What has changed though is the execution of these things and the way we must think about the model around them.

If an agent can generate, test, fix and regenerate code before a commit exists, then security can run in that same loop (like a pre-commit hook). It can inform, block, guide and validate while the work is still in motion.

The Secure SDLC does not disappear - we just need to adjust and evolve when and where things run to maximise efficiency and speed.

The repository, pull request and pipeline all remain important, but they are no longer the whole picture. The agent runtime, its tools, its identity, its permissions, its context and its tool access during the development loop all become part of the software delivery path.

This is why I think the term Inner Development Loop makes sense. Not because it gives us another buzzword, but because it gives us a practical place to put the controls we already know we need.

If software is increasingly being shaped before source control, then securing the build part of the SDLC has to start before source control too.

As always...I encourage feedback and challenges to this thinking, as things are undoubtedly going to evolve and change.

Thank you!