Secure Software Development in the Age of AI Agents

How DevSecOps must evolve when AI systems participate in design, code generation, and software delivery.

For years, secure software development has been built around a simple assumption:

Developers write the code.

Most of our controls follow from that. We train engineers. We publish secure coding standards. We perform reviews, scans, and release gates against the output they produce.

It's clear today that this assumption no longer holds up.

AI coding agents are moving beyond autocomplete and into real implementation work.

Instead, they are reading repository context, generating features, proposing fixes, refactoring code, and increasingly interacting with tools, terminals, and external services as part of the development flow.

As you can imagine, this starts to change the security model we work to.

The issue is not just that AI can generate insecure code. We already know this. Rather the point is that AI shifts where security needs to act.

If we start to assume software delivery now looks like this...

Human Intent --> AI agent --> Code --> Production

...then security cannot start only at the pull request review or pipeline scanning.

It has to begin earlier, shape the agent’s behaviour during development, and still hold through continuous delivery and runtime.

Todays Thinking?

As of today, I see a lot of the discussion around AI-assisted development sitting in one of three places:

• High-level commentary about AI risk
• Vendor messaging about tool capability
• Point solutions focused on improved code scanning

There's obvious value in the above, but it misses the operational question engineering organisations will actually have to answer:

How do you secure software delivery when AI becomes part of the development system?

Traditional DevSecOps controls still matter in that they do not go away. But on their own, they are not enough.

They were designed for a world where the main actor writing and changing code was a human engineer with context, judgement, and organisational knowledge.

AI agents don't have that - at least not by default.

They operate on the basis of the context we provide, the guardrails we embed, the tools we expose, and the constraints we enforce.

This means secure development needs a broader model.

The Development Flow Has Changed

In a traditional view of software delivery, the mental model is straightforward:

Developer --> Code --> Review --> Deploy

In AI-assisted delivery, the flow is better represented as:

Human Intent --> AI Coding Agent --> Generated Code --> Production System

This introduces a different set of security questions.

Not just:

• Is the code vulnerable?
• Did the pipeline catch it?

But also:

• Did the agent receive enough design and security context to build the right "thing" safely?
• Was it guided by usable security guardrails?
• What tools, commands, files, and services could it access while generating code?
• How do we review machine-generated output at the speed and volume these systems can produce?
• How do we learn from runtime behaviour and feed that back into the development loop?

These are not edge cases, but now form part of the flow.

"AI-Native Secure Development Model"

A useful way to think about this is to separate the delivery flow from the security control layers around it.

I've tried to represent this here:

This is how I believe we should start modelling what secure engineering teams need to start working from.

It keeps the traditional parts of DevSecOps, but extends them for a world where AI participates directly in software creation.

1. Design Intent

This is the first missing layer.

We can think of this in the context of security requirements and threat modelling in the old "shift-left" thinking (which you'll never hear me say out loud).

The premise here though...

AI agents are only as good as the context they are given. If the input is vague, incomplete, or missing key constraints, the output will reflect that.

In practice, too many teams still frame AI-driven development like this:

Build me a payments service
Add authentication to this app
Create an API for customer records

This is not design intent, but instead I see it as loose instruction.

If we want secure outcomes, agents need structured inputs that describe what is being built and the boundaries it must respect. This includes things like:

• Functional requirements
• Architecture context
• Trust boundaries
• Security requirements
• Threat scenarios
• Implementation constraints

Secure development is not just about detecting bad code after the fact.

It is also about shaping the conditions that make safe implementation more likely in the first place.

For AI-assisted development, that shaping starts here.

2. Developer Guardrails

The second layer is the set of rules and instructions that guide the agent while it works.

In a traditional environment, a lot of security guidance sits in documents that humans may or may not read (probably the latter).

In an AI-assisted environment, that is weak control. If the agent cannot consume the guidance, it cannot follow it.

This means guardrails need to become explicit and machine-usable.

Examples include:

• Repository instruction files
• Secure coding rules
• Approved patterns and libraries
• Framework-specific requirements
• Prohibited implementation approaches
• Architecture and trust-boundary constraints

This is one of the biggest practical shifts AI introduces into secure development.

Security guidance can no longer live only as policy for humans - it needs to exist as working context for machines.

3. Agent Runtime Security

Modern coding agents are not just generating code in a text box.

Now they can execute commands, inspect files, call tools, access documentation sources, interact with MCP servers, and make network requests.

At that point, the agent is not just a coding assistant - it is a semi-autonomous actor operating inside a development environment.

With this some obvious risks being to emerge.

An agent with broad access and weak controls can expose secrets, interact with sensitive files, execute unsafe commands, or retrieve untrusted external context that influences its output.

So this layer is about constraining what the agent is allowed to do while it is working.

That may include:

• Limiting command execution
• Controlling file and directory access
• Restricting network reachability
• Allow-listing tools and services
• Isolating secrets and credentials
• Introducing approval points for higher-risk actions

This starts to become a core part of controlling how we operate agents.

4. AI Code Review

Once AI starts producing more code, review pressure will increase.

The existing answer in many teams is simply “we still do PR reviews.” That is true, but it is not a complete strategy.

If output volume increases and code generation becomes easier, review models need to adapt.

This is where AI-assisted reviews can play a role.

Used properly, AI review layers can help identify insecure patterns, validate policy conformance, flag design inconsistencies, and focus human reviewers on areas of real risk.

This does not remove human accountability, but it does improve coverage and signals so we can focus on what matters.

The important point is that code review in an AI-assisted SDLC should not be treated as a manual checkpoint alone. It becomes a combined control made up of:

• Human judgement
• Automated policy validation
• AI-assisted security review
• Contextual pattern detection

This aims to create a blended model which stands up against pressure testing in the longer term.

5. DevSecOps Pipeline Controls

This layer should sound familiar! In my view, it still remains essential.

Static analysis, dependency scanning, secret detection, IaC validation, build policy enforcement, and release gating still matter. In many organisations these are the most mature parts of the secure delivery pipeline.

Despite the maturity, AI still filters in and changes the conditions under which they operate.

It can increase the pace of code generation, the size of change sets, and the amount of “plausible but wrong” implementation that enters review. This means the pipeline is often dealing with more output, more frequently, and sometimes with less human scrutiny upstream than before.

So pipeline controls remain a backbone, but they should be understood as necessary and not sufficient.

If the only answer to AI-assisted development is “we already run SAST”, then the control model is incomplete.

6. Runtime Monitoring

The final layer is runtime visibility.

Whatever confidence we have in design inputs, guardrails, review, and release controls, deployed systems still tell the truth. Runtime telemetry shows how the system behaves under real conditions, how it is used, where it drifts, and where things break.

This makes runtime monitoring more than a downstream detection capability, but also a feedback loop.

Done properly production insights should help improve:

• Future design intent
• Security guardrails
• Code review focus
• Release policies
• Threats

Having a feedback loop is important because AI-assisted development will evolve quickly.

Static control sets will age badly and teams will need to learn and adapt continuously.

What this means for DevSecOps

I do not think AI replaces DevSecOps, but I do think it forces DevSecOps to mature.

For years, many security programmes have concentrated on inserting controls into pipelines and hoping that is enough to shape secure delivery.

In human-led engineering environments, that has always had limits. In AI-assisted environments, those limits become harder to ignore and will undoubtably begin to break - and fast!

If AI becomes part of the delivery system, secure development needs to account for:

• The quality of the intent
• The context provided to the agent
• The guardrails that shape its behaviour
• The runtime permissions it operates under
• The review model applied to its output
• The feedback we capture from production

This is a hollistic and more realistic control model.

Closing view

The most important change here is not that AI can write insecure code. We already know software can be written insecurely - that is nothing new!

The important change is that software development is becoming a system in which humans and AI collaborate, and we have to govern that system, not just inspect its final output.

That is why I think secure development needs to evolve from a mostly code-and-pipeline view into something more complete:

Design intent, guardrails, runtime constraints, review, delivery controls, and feedback from production.

This is the model I will explore through a series of future posts.

I encourage feedback and challenges to this thinking throughout, as things are undoubtedly going to evolve and change (probably by the time ive finished writing this)...one thing is for sure though, we're in for a fun ride.

The next post will focus on the first layer:

Design Intent, and why it is the missing foundation for secure AI-driven development.