What 100 CISOs told a16z about security in 2027
a16z asked 100 CISOs about 2027. 70% want every fix retested; 13% run AI tools that find or fix. The gap, the Record’s numbers, and where to start this week.
Six of the twelve public AI security incidents of 2026 on MATT’s Record came after 28 September. This week a16z published a survey of 100 CISOs whose plans for 2027 read like a reply: test on every change, order fixes by proof, retest every fix.
Their own numbers also show how far there is to go. 70% want every fix retested and verified, while 13% have AI offensive security or remediation tools in production. 83% say more frequent security testing is important, while 18% run most of their offensive testing continuously today.
The survey is a16z’s: The New Security Agenda ↗, 100 CISOs at companies with more than 1,000 employees, published on 28 October 2026. 87% expect security spending to rise, and all seven of the most-selected 2027 initiatives involve AI. This piece sets it beside MATT’s Record, an open dataset anyone can download and cite, and adds three things the survey leaves out: the gap between what CISOs want and what they run, how long fixes take in practice, and the one-sentence rule behind most of the year’s incidents.
The five findings that matter to a product team
- →Testing moves to every change. 83% rate more frequent security posture testing as important, 54% as very important. 18% already run most offensive testing continuously against production; 52% expect to within a year.
- →Proof decides the order of fixes. 70% want fixes retested and verified, 67% want remediation ordered by validated exploitability, and 57% want fixes or tickets generated automatically.
- →AI-written code gets its own line. Nearly half put AI code security among their top five priorities for 2027, up from about a quarter in 2026.
- →The agents inside the company are a new surface. 46% name agents exceeding their permissions or being compromised among their biggest worries, and 45% plan a purchase or upgrade for internal AI agent security within twelve months.
- →Buyers start with what they own. 44% look first to features from a security platform they already use; 21% start with an AI-native vendor. Filling a gap the incumbent cannot address is the top reason they would choose a startup, named by 47%.
The gap in a16z’s own numbers
Set side by side, the survey’s figures describe a wide gap between what CISOs want and what they run. The widest is in testing itself: 83% call more frequent testing important and 18% test continuously. Next comes proof that fixes work: 70% want every fix retested and 13% have AI tools that find or fix in production. Even trust in agents moves slowly, from 36% who let them act on low-risk tasks today to 60% who expect to within a year.
a16z reports that most new security spending will go to tools, and that is where these gaps point. Each one is a place where a team can say what it wants but cannot yet show it happening on every release.
Why the agenda moved this year
The Record lists every public incident of 2026 in which an AI model found or exploited real systems or acted outside its scope, or in which an AI tool was the way in. It holds twelve entries. Seven touched live systems beyond the actor’s own. In four, the work was finding vulnerabilities in real software, from a 27-year-old OpenBSD bug to the two PHP flaws patched on 21 October. a16z also points to eMudhra, a certificate authority whose signing keys turned out to be guessable; we set out what happened.
The pace has changed too. Six of the twelve were disclosed between 28 September and 26 October.
PHP2Shell shows the clock. Calif found the first paths on 1 August with an AI model, inside OpenAI’s Patch the Planet programme. PHP shipped fixes on 21 October. Amazon recorded an exploitation attempt against its honeypots on 17 October, four days before the flaws were disclosed (Amazon ↗).
1. Testing runs on every change, and the pentest stays
The survey’s clearest shift is cadence. 52% expect most offensive testing to run continuously against production within a year, and 44% expect it to be built into CI/CD within five years, triggered by code or infrastructure changes.
For a team that releases weekly, a yearly test looks at one release in about fifty. The pentest still earns its place: it brings depth, a human tester’s judgement and the report an auditor expects. What changes is that the rules that matter most get checked on every release in between. Start with the surface a new signup can reach: who can read whose data, what a free account can spend, what a password reset reveals. More on that in why annual pentests fall short and on the continuous assurance page.
2. Finding is fast; fixing decides the outcome
a16z’s sharpest point is that discovery is now the quick part. Fixing still means finding the owner, deciding the change, testing it and deploying it. 70% of the CISOs want each fix retested and verified, and 67% want the order of fixes set by validated exploitability: proof that an attacker can actually do something, under stated conditions.
You’re able to find vulnerabilities faster, but you’re not able to patch faster.A fintech CISO, quoted by a16z
In practice that means three habits. Ask for a working attack path with every finding, so the queue is ordered by what can happen and what it would cost the business. When a fix lands, run the exact attack again and try the paths next to it. Then keep that check running, so a fix that holds today is re-proven on every release after it. Severity scores alone are a weak guide; the same bug can carry two very different scores, as the Next.js ImageResponse case showed.
The Record puts dates on the gap between finding and fixing:
- →PHP2Shell: found with an AI model on 1 August, fixed on 21 October, 81 days later. Amazon recorded an attacker probing the flaw on 17 October, four days before the fix shipped. A related bug had been flagged in 2024 and its fix stalled.
- →eMudhra: weak keys in place for about 17 months, blocked 100 minutes after the report. The eight certificate authority keys were created on 30 April 2025; once a researcher reported them on 17 October 2026, Chrome blocked the affected certificates within two hours and eMudhra revoked all eight within 16 hours (the full story).
Once someone looks with the right check, the finding is quick. The long stretch is the time before anyone looks, and the time between a finding and a fix that holds.
3. AI‑written code is now a priority of its own
Nearly half of the CISOs put AI code security among their top five for 2027, roughly double the share for 2026, and 83% report production use of coding assistants or agents. The useful test checks what actually shipped and how it behaves once deployed, whoever or whatever wrote it. The checks reviewers skip in AI-written code are a starting point, and the AI-written code page covers how MATT tests it.
4. The agents inside the company are a new attack surface
Agents act with the permissions of the people who run them, which makes their actions hard to tell apart from their users’. 55% of the CISOs have MCP servers or other agent-to-application integrations in production. Among their biggest worries: employees leaking sensitive data into AI tools (47%), agents exceeding their permissions or being compromised (46%), and prompt injection or leakage through AI applications (29%). 63% of responses describe security slowing at least some AI adoption.
The Record shows how this plays out. An AI note-taking tool was the way into Vercel in April, and in the ten days to 28 October, OpenCode, Warp and Coinbase disclosed leaks that came through the tools around their products, two of them blamed on AI agents. The practical step is to write down what each agent may read, change and spend, in plain sentences, and test those rules whenever the agent, its tools or its permissions change. Clear rules are also what lets a security team approve the next AI project sooner.
5. Buyers want to know how much work a tool really finishes
Some categories in this market hold dozens of vendors making similar claims, and full trials are expensive. One CISO, narrowing seven or eight vendors to three, called a proof of concept for every one of them “not humanly possible”. The questions the CISOs asked are practical: how much of the work does the product complete, how much follow-up stays with the team, which actions can it take safely, and what does it cost to run?
Those four questions belong in any evaluation. Our buyer’s guide to AI security audits adds the ones we would ask: what the audit leaves behind, how fixes are retested, and what happens at the next release.
What the Record adds: ten incidents, ten one‑sentence rules
Ten of the Record’s twelve incidents broke a rule that fits in one sentence. The other two, Mozilla’s 271 Firefox fixes and the open GLM-5.3 model, are shifts in what AI models can do, with no single rule behind them. The rules below describe what each incident shows was missing, and only that.
| Incident | The rule it broke | Kind |
|---|---|---|
| OpenAI’s models reach Hugging Face, July | A test sandbox must never reach the internet or anyone else’s servers. | Agent boundary |
| Anthropic and Meta agents reach real companies, August | A test environment must never reach another organisation’s production systems. | Agent boundary |
| GPT-6.1 Astra in a UK AISI test, September | A model must stay inside the networks it is told are in scope. | Agent boundary |
| Anthropic’s unintended actions, October | An agent under test must never act on a live website beyond what its task allows. | Agent boundary |
| Context.ai into Vercel, April | A tool connected to an employee’s workspace must never open a path into internal systems. | Connected tool |
| OpenCode’s console, October | An API key a customer stores with a tool must only ever be usable by that customer. | Connected tool |
| Warp’s vendor, October | Customers’ agent records must never be reachable through a vendor’s dependencies. | Connected tool |
| OpenAI’s community forum, July | Access to a community forum must never lead to access to internal code. | Identity path |
| OpenBSD’s TCP stack, April | A packet from the network must never be able to crash the system. | Code flaw |
| PHP2Shell, October | A request from someone who has not logged in must never run code on the server. | Code flaw |
Four of the ten are about where an AI agent may go, which is the worry 46% of a16z’s CISOs named. Three are about what a connected tool may reach. Only two are classic code flaws. A written rule is where the work starts; testing it on every change is how a team knows it still holds. The published rules show what that looks like for a product.
What the survey says, and where to start
| The finding | What it means for a weekly release | Where to start |
|---|---|---|
| 52% expect continuous offensive testing within a year | A yearly test sees one release in about fifty | Pick the rules a new signup must never break and test them on each release |
| 70% want fixes retested; 67% order them by validated exploitability | A closed ticket is a claim until the attack fails | Rerun the original attack after every fix, then keep it running |
| Nearly half rank AI code security in their top five | Assistants raise the volume of change | Test deployed behaviour, whoever wrote the code |
| 46% worry about agents exceeding their permissions | Agents carry their users’ access | Write down what each agent may read, change and spend |
| 44% start with their security platform’s features | The remaining gaps are specific to the product | List what the platform cannot see in your product |
What the survey leaves open
It reflects 100 CISOs at companies with more than 1,000 employees, and a16z gives no date or method for the fieldwork. Smaller software companies ship to the same internet, often without a security team of their own.
MATT is built around the loop the survey describes. It writes down the rules a product must hold, proves which ones are broken with a working attack path, helps the team fix them, and re-proves every rule on every release, alongside the pentests and platforms a team already runs. It starts with a 15-minute discovery call with a co-founder.
Questions
What did the a16z CISO survey find?
a16z surveyed 100 CISOs at companies with more than 1,000 employees about 2027. 87% expect security spending to rise, all seven of the most-selected initiatives involve AI, 52% expect offensive testing to run continuously within a year, and 70% want every fix retested and verified.
What is continuous offensive security?
Testing a product the way an attacker would, each time its code or infrastructure changes. It sits alongside the annual penetration test and covers the releases in between.
Does continuous testing replace the annual penetration test?
The pentest stays. It brings depth, a human tester’s judgement and the report auditors expect. Continuous checks cover the releases between tests, re-proving the rules that matter most on each one.
What does validated exploitability mean?
A finding comes with a working attack path that shows what an attacker can actually do under stated conditions. Ordering fixes by that proof, and by what each would cost the business, is what 67% of the surveyed CISOs want.
What is the gap between what CISOs want and what they run?
In a16z’s survey, 70% of CISOs want every fix retested and verified while 13% have AI offensive security or remediation tools in production, and 83% call more frequent testing important while 18% test continuously today.
Where should a smaller software company start?
With the surface a new signup can reach. Write five to ten plain-English rules that must always hold, such as one user never reading another user’s data, and test them on every release.