AI in Operations
The Accountability Gap Nobody Wants to Own
Security teams keep inheriting problems that were never theirs to fix. Here's why that arrangement is breaking down.
Jason Walker
.6 min read
Here is the problem with every security incident post-mortem I have ever sat through: by the time the team finishes the timeline, the root cause is almost always a software defect that shipped months ago, maintained by a team that had zero accountability for what happened next.
The security team patches it. The security team takes the call at 2am. The security team presents to the board. And the software engineering organization that released the defective code? They are already three sprints ahead, building the next thing that will page someone at 2am next quarter.
This is not a technology problem. It is an accountability structure problem. And until organizations are honest about that, no amount of tooling will fix it.
The mental model most organizations operate on goes something like this: software engineers write code, security teams watch for problems, and when problems appear, security fixes them. This model feels natural because it has been the default for twenty years. It is also completely backward.
Aviation safety culture builds chains-of-custody thinking into every process. The pilot who notices a mechanical anomaly does not hand it to a separate "aviation security team" to resolve. The crew that identified the problem owns the communication chain. The mechanic who touched the aircraft last is part of the accountability loop. Nobody gets to say "I built it, now it's your problem." The discipline works because ownership follows the work, not the incident.
Software engineering organizations have, over decades, convinced the rest of the business that their relationship with security works the opposite way. They build. Someone else watches. Someone else fixes. The incentive structures inside most engineering organizations reinforce exactly this split: velocity is measured, security outcomes are not. Engineers ship features, get promoted, and move on. The liability stays with the security team.
This arrangement was already strained. Agentic AI just snapped it.
When vulnerability discovery operates at machine scale, the entire premise of "patch and defend" stops being a strategy. It becomes theater.
I run enterprise cybersecurity across dozens of agencies and hundreds of thousands of devices. The volume of findings at that scale is not a queue you work down. It is a river. The question has never been "can we patch everything?" The real question is "who is accountable for the code that keeps generating findings?"
If the answer is still "the security team," then the security team is responsible for decisions it never made, code it never wrote, and architecture it never approved. That is not accountability. That is a scapegoat structure that happens to have a budget line.
AI-accelerated vulnerability discovery does not change what is broken. It just removes the excuse of "we didn't know fast enough." Now you know. You know at machine speed. And if the software engineering organization still has no accountability for the findings that map to their code, you will know faster and fix slower.
The relationship problem runs deeper than org charts.
The first speaker I heard articulate this clearly made a point that stuck with me: most security failures trace back to a relationship that was never built, or one that was allowed to deteriorate. Not a technology gap. Not a budget gap. A relationship gap.
In a state government context, the relationship problem is structural. Engineering decisions get made in agencies I do not control, by teams I do not fund, under timelines I do not set. If I have not already built working relationships with those teams before a crisis arrives, the post-incident conversation becomes political instead of technical. That cost is enormous.
But the relationship problem and the accountability problem are not the same thing, even though they interact. You can have a great relationship with an engineering leader and still have an accountability structure where their team has no skin in the security outcome. Being friendly with someone does not mean they share your risk.
What actually changes behavior is when software engineering organizations have a stake in what their code does after it ships. Not a soft stake, not a cultural nudge. A real one. Tracked metrics. Visible ownership. Consequences that flow back to the team that introduced the defect, not to the team that found it six months later.
Here is what needs to change, and it is uncomfortable for everyone.
Security teams need to stop accepting defect remediation as their core function. Finding vulnerabilities is a security function. Fixing the code is an engineering function. The moment the security team routinely owns remediation, the engineering organization has learned that shipping insecure code is someone else's problem.
Security leaders need to make this case in budget and governance conversations, not just in hallway conversations with engineering peers. The board cares about risk. Help them understand that the risk sits in the release process, not just in the threat environment.
Engineering organizations need to be measured on security outcomes, not just feature velocity. This does not mean slowing down. It means that when a CVE maps to code your team shipped, your team's metrics show it. Your team's roadmap makes time for it. Your team's lead is the one on the incident call.
And executives need to stop letting the organizational split between security and engineering diffuse accountability. When nobody owns the outcome, the outcome defaults to the person with the most pain tolerance. That is usually the CISO. That is not a strategy.
The instinct in a lot of security leadership circles is to solve this with better tools, better threat intelligence, better automation. All of that matters. But tools do not fix an accountability structure. They just make the gaps more visible, faster.
The discipline that separates a well-run safety culture from a reactive one is not better sensors. It is clear ownership chains that do not break when an incident occurs. The sensor tells you something is wrong. The ownership chain determines whether anyone is actually responsible for fixing the underlying cause, or whether the alarm just gets routed to whoever can be blamed most cleanly.
We are at an inflection point where AI gives organizations the ability to see their attack surface with unprecedented clarity. That is genuinely useful. But seeing a problem clearly is not the same as having the structure to fix it.
The accountability gap is still there. It is just better lit now.
Keep reading
Weekly writing from inside the work.
Practitioner-researcher essays four times a week. No spam, unsubscribe in one click.