#1738146: Why Be Responsible When We Can Just Blame AI?
| Description: |
AI is making it easier than ever to ship fast and assign blame later. But who owns AI-generated code? This episode digs into what happens when an agent deletes your inbox, and why "a human approved the pull request" is starting to sound a lot like an alibi. This week’s episode is hosted by David Spark, producer of CISO Series, and Andy Ellis, principal of Duha. Joining them is their sponsored guest, Jadee Hanson, CISO, Vanta. The compliance receipt nobody reads Let's give SOC 2 some credit. It wasn't designed to be useless, but point-in-time audits have made it that way. By the time a PDF lands in procurement, the security posture it describes is already months out of date, said Bil Harmer, CISSP, CISM, CIPP of Craft Ventures. The problem is that nearly every SOC 2 report comes back spotless, which tells you nothing about the state of a vendor's actual controls. The industry knows this is broken and keeps buying anyway. Real improvement means moving toward continuous verification and full transparency, where buyers can see live control data instead of a frozen snapshot. The first vendor willing to show their messy, dynamic environment openly will face scrutiny. They'll also be the ones raising the bar. Who signs off on the AI that wrote the code AI-generated code is already shipping into compliance-sensitive environments, and the governance hasn't caught up. The instinct is to require a human to approve every pull request. But the question came up in the cybersecurity subreddit: Who owns the code after it ships, after a reorg, after the team that wrote it no longer exists? Ownership at commit time isn't enough. Every piece of code running in production needs traceable accountability back to someone making active decisions about it, whether that accountability runs through a person or an AI operator. The review problem is real, but the ownership problem is older. AI just made it more urgent. The agent that wouldn't stop An AI agent deleted a Meta AI safety director's inbox. It had been told to confirm before acting. It didn't. The instinct is to call this an AI problem, but for Ross Young of the CISO Tradecraft podcast, it's really a systems design problem that predates AI entirely. Giving an agent admin-level access and trusting a prompt as the kill switch aren't control strategies. Kill switches belong in identity and access management, in scoped permissions, in chaos testing that asks what happens when the agent goes rogue before it does. Every system powerful enough to help at scale is powerful enough to cause damage at scale. The architecture has to account for that from the start. The questionnaire that should not exist AI in GRC has become shorthand for LLMs autofilling security questionnaires. That's a great floor for the tech, but hardly the ceiling. The questionnaire itself is the problem. Static questions sent to vendors produce static answers that don't reflect how a security program is performing week to week. The more useful application is an AI that continuously monitors your own program, flags when you've been missing vulnerability SLAs for 3 weeks, and lets buyers query live control data directly instead of waiting for a document. We should be trying to eliminate the paperwork, not make it more efficient. Listen to the full episode on our blog or your favorite podcast app, where you can read the entire transcript. If you haven’t subscribed to the CISO Series Podcast via your favorite podcast app, please do so now. Listen to the full episode here. |
|---|---|
| More info: | https://www.linkedin.com/pulse/why-responsible-when-we-can-just-blame-ai-cisoseries-xa2dc/?trackingId=KMN7ev8QT%2BGof5Yapscm5w%3D%3D |
| Date added | May 19, 2026, 9:22 p.m. |
|---|---|
| Source | |
| Subjects |