Don't Let Security Get Left Behind in Agentic Development

|

Thought Leadership

Daniel Cohen, Head of Product

As AI coding agents collapse the SDLC into single sessions, Seezo weaves adaptive security directly into the developer's workflow, without giving up governance.

AI’s impact on the SDLC

Security touchpoints have always been placed in the seams of the software development lifecycle. Do design reviews/threat modeling before development starts. Do code review at PR. Check dependencies at build. Back to the start for the next sprint.  

This makes sense when there are meaningful transitions between discrete stages required to avoid material rework costs when things are not done right. Not only are these transitions disappearing, but the duration of the stages themselves are getting shorter¹ and there is far more code getting pushed through far more iterations of the SDLC². 

The security assessment/vulnerability backlog is already severe. If we don’t address the underlying scalability and workflow alignment issues, these gaps will widen. 

“Shift left” has been the deafening rallying cry for overwhelmed security teams struggling with scale for two decades. How does that work when design/implementation/testing (basically everything on the left side of the SDLC) collapses into a single session with a coding agent where security teams have no visibility? What’s the value of secure development training when the devs aren’t explicitly writing software anymore? 

In reading/listening to dozens of perspectives on the extraordinary offensive security capabilities of frontier AI models³, many throw their hands up and say “we are going to get breached, let’s just contain and try to minimize the blast radius.” Yes, let’s do that, but let’s also take advantage of the opportunity presented to us to build security into the place where software now gets designed and written. 

A Different Perspective

To build a better solution, we need to think differently about how to build security into the new AI SDLC model. We can no longer rely on the natural decelerators in traditional SDLCs to inject security touchpoints/gates. Point-in-time security feedback will be stale by the time the next coding session starts. Static artifacts can’t grow with an agent’s dynamic context bouncing between design, development, and testing. 

We can’t keep building discrete touchpoints onto a time-based, one-directional, linear model of the SDLC. When developers are moving back-and-forth between SDLC stages within minutes, and releasing new features in hours, we need to:

  • Meet builders where they are with AI plugins, skills, integrations, workflows, etc.

  • Provide useful secure design output that can be used as context for the agents to reference continuously at the right time

  • Allow for context to adapt during the session to new information

  • Deliver results reliable, scalable, and useful enough to ensure developers do not disconnect the security tools

  • Give security teams Telemetry to monitor, audit, and govern what’s happening inside the coding agents 

Sources
¹ McKinsey — Generative AI fuels creative physical product design
² GitClear — The AI code quality and maintainability gap
³ DARPA — AIxCC results

What We’re Building at Seezo

Seezo’s developer-first security workflow will have four connected capabilities: selective guidance while work is taking shape, deeper assessment when warranted, persistent security requirements, and validation that carries those requirements into implementation. 

While developers and their agents are working, Seezo will supply the security context relevant to the task. The context comes from the organization’s security standards and is selected based on the area of work. It becomes part of the working context, helping shape the design and implementation without taking over the session or changing code independently.

Some changes still need an explicit, deeper review. Developers can start that review from the coding agent and continue working while it runs. The assessment happens asynchronously, the result returns to the same workflow, and the resulting security requirements persist beyond the conversation.

Those persisted requirements connect design review to implementation. When code exists, Seezo can validate the implementation against the requirements from the assessment, locally or in CI. This is not a replacement for every form of code scanning. It answers a focused question: does the implementation honor the security design decisions and requirements that were reviewed?

CI is another surface for the same operations. Depending on the artifacts in a pull request and the organization’s configuration, CI can run an assessment on a design document, validate an implementation against an existing assessment, or run both where appropriate. Results return through the pull request instead of sending developers into another interface.

The Seezo platform is the system of record for assessments and requirements, giving security teams governance over what happens inside the coding agents. Security will know what skills were invoked, when and by whom they were run, on what branch, and whether the resulting requirements were honored in the implementation. For regulated organizations, this gives auditors visibility into agent-driven code changes that they lost when coding agents entered the workflow.

Security shouldn't wait at the disappearing seams of the SDLC. Security should follow the work from the first design decision, through implementation, to the pull request with context that adapts to what the developer and their agent are doing in the moment. And it should do that without asking developers to step out of their workflow to operate a security process; security should meet developers where they are. The AI-SDLC gives us the chance to build a better security model. One that weaves security into how software gets made, without giving up the governance we can't afford to lose.