Bellini Capital CISO on AI security governance and the limits of patching faster
In this Help Net Security interview, Brian Blakley, CISO at Bellini Capital, explains why AI makes finding vulnerabilities faster while fixing them still takes time. He argues that “patch faster” is not enough and that teams need to cut exposure while remediation is pending.
Blakley describes a shared metric for CIOs and CISOs, how his team tests for silent model updates, who owns the damage when an AI agent makes a mistake, and why blocking AI tools without an approved alternative backfires.
What’s a belief about AI security you held two years ago that you’ve since abandoned?
Two years ago, I believed AI would give attackers and defenders roughly comparable gains. I’ve completely abandoned that view, and leading security for a vulnerability management platform is what changed my mind.
Our engineers use AI in the IDE and inside the product itself, so I watch discovery accelerate firsthand. While finding vulnerabilities is getting faster for everyone, fixing them isn’t. An attacker can move from flaw to working exploit with almost no friction. On the other side, a defender still has to assess business impact, validate the patch, test compatibility, get change approval, and negotiate a maintenance window with the business.
As a former CISO of a fintech processing $50 billion a year in online transactions, I learned that a payment platform doesn’t go offline because security found an urgent vulnerability. A delayed patch there is usually intentional and standard operational procedure. It was a deliberate tradeoff between the risk of exploitation and the risk of interrupting revenue.
Overall, “patch faster” is necessary but it’s insufficient as a long-term strategy. The better question is how quickly we can shrink exposure while remediation is pending, through segmentation, isolation, compensating controls, and much faster business risk decisions. That gives the CIO and CISO a common objective: keep critical services running while closing the exploitable window.
CIOs tend to be measured on adoption and delivery, CISOs on losses avoided. Is there a metric both offices share in organizations you’ve seen work well? How do you stop people from gaming it?
I’ve seen split scorecards let CIOs and CISOs win while the business loses because their incentives are misaligned. A CIO can ship or deliver on time and on budget while introducing material risk & exposure. A CISO can reduce exposure with controls that stall a project, without proving the delay was worth it.
The best model I’ve seen lives at a billion-dollar insurance-adjacent company that funds AI through small proof-of-value projects with an explicit goal: grow revenue while keeping labor costs flat. Our AI and Data Governance Committee brings business unit owners and operations together with the CIO, CTO, and CISO to vet every initiative against that outcome. The shared measure is the percentage of critical initiatives delivered within agreed financial and operational constraints, with material risks addressed or explicitly accepted by the accountable business owner.
I propose three guardrails that can help prevent gaming. First, define success BEFORE the pilot starts, not at the post-mortem. Second, never score risk acceptance as risk remediation; most of the time a signature documents a decision, but it doesn’t remove business exposure. And third, rescore after go-live if a launch later creates security or operational costs. When executives can each hit their targets while the organization suffers a preventable loss, you’re measuring operational, IT, and security activity, without measuring business success.
When a model provider updates the model underneath a product you depend on, how do you test for behavior changes that matter for security? Has a silent model update ever caused a problem you can describe?
In my experience, traditional change management assumes that if nothing visible changed, nothing meaningful or significant changed. AI breaks that assumption at velocity and scale. The interface, configuration, and version number can stay the same while the model underneath starts reasoning differently. For a vulnerability management company, that isn’t abstract. If the model behind prioritization shifts, a flaw flagged for immediate remediation yesterday could rank as low priority today, with nothing about the vulnerability, environment, or controls having changed. The product works as designed; the customer’s decision has changed materially. The same applies to the coding assistants our India-based engineering team uses daily. A model change can alter the code they suggest without anyone touching a setting.
Our answer is risk-based regression testing. We maintain scenarios built around critical assets, known vulnerabilities, and business dependencies, and compare outputs against validated baselines for shifts in risk interpretation, recommended actions, data handling, and permissions. We pin versions where providers allow it, without assuming they always will. I can’t point to a silent update that caused an incident for us, and I’m careful about what that proves. It may only mean we weren’t measuring the right thing. We spent decades learning to manage software change. Now we have to decide how to manage change in the intelligence behind it.
Suppose an AI agent with delegated permissions does something damaging, such as deleting records or emailing the wrong customer data. Whose budget pays for the cleanup, and whose name goes in the board report? Is that written down anywhere, or are most organizations waiting for the first incident to decide?
Organizations can delegate authority to an AI agent, but they can’t delegate accountability. A recent pilot made that concrete. We deployed agentic AI to make outbound calls, trained on thousands of hours of recorded human calls, and the people who made those calls moved to higher-value work. It was a business win. But before an agent dialed a single customer, the AI and Data Governance committee we formed had to answer your question: when an agent says the wrong thing, who owns it?
Our answer separates three roles. Financial responsibility follows the funding source, whether a business unit, the technology budget, an incident reserve, or insurance. Operational responsibility sits with the teams that restore, investigate, and manage regulatory obligations: IT, security, and Legal. Executive accountability is assigned to and belongs to the business owner who authorized the agent to act, while the CIO, CTO, and CISO answer for their own controls. That framework leads to a practical test: If a human caller needs approval to make an offer or disclose customer data, the agent doesn’t get that authority just because it’s faster. Many organizations haven’t written this down. From my experience, the worst time to decide who owns an agent’s decisions is after it makes one you can’t reverse.
Give me one case where blocking an AI tool worked and one where it backfired. What separated the two?
Blocking an AI tool can be the right call when its risks aren’t understood. What separates success from failure is what leadership does next, and in my experience, I’ve seen organizations get that wrong more often than not.
Walmart is a good example of a block that worked. Its technology arm restricted ChatGPT after noticing activity it considered risky, then evaluated the tool, issued usage guidelines, and reopened access on its network. The block bought time to build a better and more controlled path. It served a strategy rather than replacing one.
The block that backfired is the reported prevalence of shadow AI use where employees keep using ChatGPT through personal accounts despite corporate restrictions. That can be written up as policy circumvention and lost visibility, so it’s not necessarily a breach, BUT companies are closing the approved door without addressing why employees are turning to it in the first place. In an engineering-first culture, that risk is acute. Engineers who’ve seen what an AI assistant does in the IDE won’t stop because a proxy or a written policy says no. These are brilliant engineers and trust me, they’ll find another route.
That’s why a well-established AI and Data Governance committee pairs restrictions with a vetted alternative: business owners and the CIO define the productivity need, the CTO judges technical fit, and the CISO sets the guardrails and boundaries. A dashboard showing near-zero unauthorized AI use proves little. Security can win the argument about which tools are prohibited and still lose control over how the business gets its work done.
Download: The IT and security field guide to AI adoption
