AI finds the flaws faster than you can fix them. Fixing is now the job.
McKinsey argues that frontier AI has moved the security bottleneck from finding software flaws to fixing them. I agree, and the lesson is older than AI: like data defects, software flaws only get fixed when someone owns them and has a budget. That gets hard when the business, not IT, owns the code, and it is the same consequence-and-authority logic the OCC just gave its examiners.
What happened
McKinsey published How frontier AI is rewriting software security rules this month. Its starting point is that two assumptions behind software security no longer hold: that finding and exploiting flaws takes rare expertise, and that defenders have time to assess and fix what they find. Frontier models can now read code and configuration with a security mindset and find flaws at a scale no team was built to absorb.
The article gathers the evidence. Anthropic reported in May that partners in its Project Glasswing had found more than 10,000 high or critical vulnerabilities using a preview model, with several saying their bug-finding rate rose more than tenfold. CVEs fixed per Linux kernel release roughly doubled, from about 500 to more than 1,000, according to a kernel maintainer. HackerOne reported vulnerability submissions up 76% year over year. On the other side, Verizon’s 2026 breach report found the median time to fully fix known exploited vulnerabilities rose from 32 to 43 days, with only 26% fully fixed. Regulators have noticed: the European Central Bank asked the banks it supervises for action plans on vulnerability management and AI-enabled defenses by 31 October.
The authors propose four levers that move together:
- Cyber practices. Use several models and tools, bring every finding into one record, rank findings by real exposure, require reproducible proof before engaging a developer, and scan continuously.
- Operating model. Build security into the engineering platform. Treat coding-agent access as privileged access, separate who proposes a change from who can weaken its checks, give critical shared components an owner and run remediation at three speeds: rapid response, normal delivery and retirement.
- Risk and control framework. Replace qualitative risk appetite with exposure tolerances by asset tier, rate risk on exploitability and business impact rather than severity labels, make risk acceptance owned and time-bound, and bring agents into the control framework as a distinct class of privileged actor.
- Technology. Assume breach and limit the blast radius, strengthen the basics, pair experts with agents on the logs and retire systems that cost more to secure than they are worth.
It applies the model by what a firm controls: new development, existing systems and commercial software, and recommends starting with one delivery path and a small set of critical systems for the first 90 days.
My view
The central point is right, and it reaches well beyond the security team. When finding a flaw becomes cheap, the scarce resource is the ability to fix it safely. A program that measures how many flaws it found is now measuring the easy part.
A flaw is a defect, and defects need an owner and a budget
I’ve seen this pattern before, in data. Every firm that has run a data quality program learns the same lesson: finding defects is easy, and the issue log grows until someone owns each dataset and has the time and money to fix it. Automated profiling made discovery cheap years ago. It didn’t fix a single record. The firms that improved data quality were the ones that named an owner for each critical data product, gave that owner a budget and capacity, and agreed in advance how long a known defect could stay open. Everyone else built a longer list.
Software flaws now behave the same way. AI has turned vulnerability discovery into the equivalent of automated data profiling: a constant stream of findings, most of them real. The article’s answer, exposure tolerances by tier, owned risk acceptance with an expiry and capacity decisions made explicit, is the data quality playbook applied to code. It works only if each finding lands on someone who owns the system and has the capacity to act.
For most software, that is the easier half. IT owns the code. There is a backlog, a change process, a release pipeline and an engineering budget the fix can compete for. The hard question is what happens when IT doesn’t own the code.
When the business owns the code
AI coding tools have made it possible for people outside engineering to build real software. A trader monitors flows with a script, an analyst builds a pricing tool, an operations team automates a reconciliation, all with Claude Code or a similar assistant. That is a real productivity gain, and it is also software with no backlog, no change window, no maintainer and often no entry in any inventory.
Now point a frontier security model at it. If the scan finds a serious flaw in a desk-built tool, who fixes it? The engineers don’t own it and may not know it exists. The person who built it may have moved on, may not understand the fix and has no budget or time set aside for maintenance. If the tool runs with its builder’s access, the flaw is reachable through everything that person can open. And the scan only happens if someone knows where the code lives, which for business-built tools is often a laptop, a notebook or a shared drive outside the pipeline the article describes.
This is the risk behind Goldman’s decision to take AI coding tools back from traders and bankers. The reporting cited productivity and risk management. My reading was that the exposure is software nobody owns, running with access nobody designed. The security article adds the second half of that story: even if the code were found, there would be no one funded to fix it. The article’s list of what a firm controls covers new development, existing systems and commercial software. I’d add a fourth line for business-built software, with the same rules: it gets an owner, an inventory entry, its own bounded access and a path to engineering or retirement. Without those, the cheapest control is the one Goldman chose, and that gives up the productivity.
Coding agents are privileged users
The article says coding-agent access should be designed as privileged access: write rights limited to a task branch through a short-lived credential tied to the agent’s identity, no access to production credentials or data, and limits enforced outside the model because agents read untrusted text that can carry injected instructions.
That is the most important sentence in the piece for firms adopting AI coding tools, and it is worth checking whether yours has done it. In many setups a coding agent runs with the developer’s own access: their repositories, their tokens, sometimes their cloud credentials. It reads issue text, documentation and third-party code written by anyone. That combination of broad inherited access and untrusted input is how a helpful tool becomes an attack path. It is the same pattern behind OpenAI’s own security warnings: the risk isn’t the model, it’s the access the model inherits. For business users building with these tools, the inherited access is often broader than a developer’s, because it includes production data the developer would never be given.
It’s the same logic the OCC gave its examiners
The article cites bank supervisors in Europe and the US, but not the OCC’s new guidance. Its risk framework lines up closely with the OCC’s new examiner guidance on AI. Both reject rating by technical labels. The OCC classifies AI by the consequence of a mistake and the authority delegated, not by model sophistication. The security article rates flaws by exploitability and business impact, not severity scores. Both tier by consequence and set tighter limits for the top tiers. Both treat agents as actors that need their own identity, a documented purpose, limited permissions and an owner. Both ask whether someone with authority can stop the thing quickly, whether that is pausing an agent or switching off an exposed service. And both extend responsibility to suppliers: the OCC to provider agents, the article to vendors’ patch speed.
For a bank, that overlap is useful. An examiner looking at AI and a supervisor looking at cyber resilience will ask the same questions about the same systems: what can it reach, what can it do, who owns it, who can stop it and what is the record. A desk-built tool written with an AI assistant falls under both. Firms that build one inventory, one set of tiers and one evidence trail will answer both reviews from the same source. Firms that run them separately will build it twice and reconcile the differences under pressure.
Exposure ranking is a data problem
The advice to rank flaws by reachability and business impact depends on something most firms don’t have: an accurate map of which systems hold or can reach which data, and who owns each. A critical flaw in a system that can read client assets is a different problem from the same flaw in an isolated tool. Without that map, every finding looks equally urgent, and the backlog wins. It is the same map firms need for AI agents and for the OCC’s purpose statements, so it is worth building once.
Evidence does double duty, and scale is the risk
The pipeline that tests a change should keep the evidence against the exact version released, including which identity, model and dependencies produced it. That record is what lets a firm trust agent-written code, and it is the same record an auditor or examiner will ask for.
Where I’d add caution is on scale. Four coordinated levers is the right design and also a large program. The article’s advice to start with one delivery path and a few critical systems is the part to take most seriously, and I’d include at least one business-owned tool in that first scope, because that is where the ownership gap will show first.
Why it matters
For the industry. Every firm that ships or depends on software now faces more known flaws than it can fix on old timelines, and its suppliers do too. AI coding tools add a growing body of software written outside engineering, often with broad access and no owner. The firms that cope will treat flaws the way mature firms treat data defects: owned, budgeted, tiered by consequence and closed or accepted on a deadline. In banking, they will also find that their cyber, AI and model risk reviews are asking the same questions.
How it connects to our work. Agent Onboarding gives each agent, including coding agents, its own bounded identity, an owner and limits enforced outside the model. Data Product Certification is the ownership model this needs: a named owner, a contract and a standard to meet, applied to data and equally to the tools built on it. AI Governance Evidence covers the release records that show who or what produced a change and how it was checked. Six steps I’d take first:
- Take coding agents off personal credentials. Give each its own short-lived identity, limited to the task, with no production access.
- Find the business-built code. Inventory tools built outside engineering, especially with AI assistants, and record what each can reach.
- Give every system an owner and a budget. A flaw without an owner who has capacity to fix it is a finding, not a fix.
- Set exposure tolerances by tier. Agree how long a proven flaw may stay open, who can accept the risk and until when, and align the tiers with your AI risk tiers.
- Map systems to data. Rank flaws by what the affected system can reach, not by its severity label alone.
- Retire what no one will own. Give systems that cost more to secure than they’re worth, including orphaned desk tools, a funded retirement date.
Sources
- How frontier AI is rewriting software security rules, McKinsey & Company, November 2026. The figures above, including those from Anthropic, a Linux kernel maintainer, HackerOne, Verizon and the European Central Bank, are as cited in this article.
- Related Viewpoints: Goldman takes AI coding tools back from traders and bankers, The OCC will judge bank AI by what it can do and OpenAI’s security warnings show what an internal AI tool can find.
Disclosure: I was previously McKinsey’s global firm chief data officer.
Linked sources are the record. Check them for the full reporting.