Shift in: how GenAI is driving security into development teams

[maryiat]

Describe the enquiry

Why?
It is becoming harder to secure software the moment GenAI enters the picture, and I think this gradually changes who owns security work inside an organisation.

Conventional security testing rests on a model that has worked for decades: a specialised team (security engineers, pentesters, a central security function etc.) periodically assesses a system against known methodologies like vulnerability scans, penetration tests, threat models, checklists like the OWASP Top 10 etc. This model assumes the attack surface is relatively stable between assessments, and that a point-in-time review stays valid for weeks or months afterwards.

GenAI-based systems break that assumption. Their attack surface is not just code. It might be prompts, retrieved data, model behaviour, agentic actions taken on a user's behalf and so on. None of this is static. A system prompt can change on a Tuesday, a RAG data source can be re-indexed on a Wednesday, a model provider can update the underlying model on a Thursday, and each of those updates can change security exposure. By the time a specialised security team finishes a scheduled review, the system they reviewed may no longer exist in the form they tested.

My hypothesis is that this mismatch is accelerating a shift already underway in software delivery: security is moving from something a centralised, specialised team assures periodically, to something software development teams themselves monitor and prevent continuously as part of how they build and ship. AI may be forcing security to shift in: continuous red-teaming, guardrails, runtime monitoring owned by the team that ships the feature, security expertise embedded inside delivery teams rather than gatekeeping them from outside etc.

I don't yet know how strong this shift really is in practice, or what conditions make it true or false. That's what this enquiry is for.

Expected results
I'd like to have a deeper understanding of:

• Whether the shift from specialised security teams to continuous, team-owned security monitoring is actually happening in real organisations adopting GenAI? Or specialised security functions remain essential, just changed in form.
• What continuous security monitoring and prevention concretely looks like when it's done well inside a development team (practices, tooling, ownership, skills required etc.).
• The conditions under which this shift holds vs. breaks down. For example, company size, regulatory context, AI maturity, risk appetite, existing competence etc.
• What skills and mindset development teams actually need to pick up to own this responsibly, and how realistic it is to expect them to acquire these on top of their existing workload.
• Entry points (resources, guidelines) to start competence upgrade of existing dev teams.
• Who ends up accountable when something goes wrong. If security ownership moves into dev teams, does responsibility move with it, and how does that interact with compliance/audit requirements?
• How the shift looks different depending on the type of GenAI system involved. For example, a simple chatbot vs. an agentic system with tool access and the ability to take real-world actions.
• How mature organisations are actually building this today. Is it emerging organically inside teams, or being deliberately designed and rolled out top-down?

Collaboration

Collaboration
I've formed this hypothesis from my own experience as a security champion and from following the AI security space, but I don't have full visibility into how this plays out across different organisations and industries. What I would like to get from the community supporters is:

• Critique or complement the hypothesis. Feel free to tell me where it's wrong, incomplete or too early to call
• Share real-world experiences or stories, from your own organisation, that support or contradict it
• Share pointers to relevant research, frameworks, or articles on this topic
• Recommend people who might be interested in weighing in on this — I'd like to widen the conversation

Target artifact
An article, a talk, a workshop