Your patch window is a board question.

AI finds vulnerabilities in hours. Most enterprises still patch in weeks.

On 5 May 2026, Singapore's Senior Minister of State for Digital Development and Information, Tan Kiat How, told Parliament that AI is now finding software vulnerabilities "in hours, sometimes minutes," outpacing the patch cycles enterprises have built around them. On the same day, the Commissioner of Cybersecurity, David Koh, sent a letter to the boards and chief executives of Singapore's Critical Information Infrastructure operators. The letter directed them to review their cybersecurity posture against this new threat environment.

The audience was deliberate. "This is not an issue that should be delegated to IT teams alone," Tan said in the same statement. CSA had already addressed it to the people on the hook.

AI-enabled cyber threats are no longer a technical risk for delegation. They are an accountability question at the highest level of the company. The Monetary Authority of Singapore has already convened the chief executives of major financial institutions to address the same problem.

If you run a CII operator in Singapore, you have already received the letter. If you run an enterprise or a growing business anywhere in the region, you should read the rest of this as if you had.

The numbers behind the warning

The UK's AI Security Institute (AISI) published data on 13 May 2026 showing that the length of cyber tasks frontier AI models can complete autonomously has been doubling every 4.7 months since late 2024. That figure had already accelerated from an 8-month doubling time AISI estimated only six months earlier. Two recent models, Claude Mythos Preview and GPT-5.5, exceeded even that faster trend. Mythos Preview completed both of AISI's simulated enterprise attack ranges, including one that no model had previously been able to solve.

The Firefox team turned this from a forecast into a count. On 7 May 2026, Mozilla published the technical details of an effort that used Claude Mythos Preview to audit the Firefox codebase. The result was 271 previously unknown security bugs fixed in a single release, including a 15-year-old bug in the <legend> element and a 20-year-old XSLT bug. In total, Mozilla shipped 423 security fixes in April alone.

The team running the effort describes the new agentic harnesses as something that "can find real bugs and dismiss unreproducible speculation." A few months ago, AI security reports were dismissed as slop. Today they are finding latent bugs that an experienced security team had missed for two decades.

Finding the bugs is now the easy part

In Palantir's Q1 2026 earnings call, CTO Shyam Sankar told investors that current-generation models including Anthropic's Mythos and OpenAI's SPUD, running on Palantir AIP, have "discovered thousands of zero days in major operating systems and browsers." He said the rate of identification "is about to skyrocket." His framing of the new problem was direct: "Finding the bugs is no longer the limiting factor."

Rapid-fire remediation is the new hard problem: knowing exactly what versions of what software are running where, and closing the remediation chain autonomously, at machine speed, across every environment in which your software runs.

AI is moving the discovery side from quarters to hours. Most enterprise patch cycles are still measured in weeks. Tan Kiat How named the same gap when he told Parliament that vulnerabilities are now being found faster than they can be patched.

Where enterprises and SMEs are building today

Enterprise and SME software gets built in three places today. Each carries its own exposure.

The big SaaS platforms. Salesforce and SAP run release cycles measured in months. Salesforce ships three seasonal releases a year. SAP cycles are longer still. Even hotfixes have to pass through customer testing and change control before they reach production. That cadence works for running core business systems. It does not work for a threat environment where AI finds an exploit in hours.

Vibe-coded apps. A growing portion of new SaaS products and internal applications are being built using AI coding agents and low-code platforms by teams without deep security capability. The visible part of the application is the feature set. The invisible part is everything underneath: authentication, access control, secrets management, GDPR and PDPA compliance, logging, incident response, dependency hygiene, and rollback procedure. The code that gets shipped without those layers is exactly the code AI scanners are now finding bugs in at scale. Underneath most of these apps there is no Apollo equivalent and no defensive harness running against the codebase. In many cases, no one has full-time responsibility for keeping the security posture current.

Full-stack custom applications. This is the category where Firefox tells us the most. Mozilla has one of the most scrutinised security postures in open-source software, and 271 bugs were sitting in their code waiting to be found. If your enterprise is running a custom-built operational app, a customer portal, a data integration layer, or any system written in-house over the last decade, your latent bug count almost certainly is not zero. It is unknown. And the patch capacity required to ship 423 fixes in a month is rare in most enterprise IT functions.

The SME problem is sharper than the enterprise problem. SMEs are building products and selling them to enterprise customers. They sit inside the supply chain of the same CII operators David Koh wrote to. CSA has noted that threat actors target non-CII systems precisely because they are less secured and act as entry points into critical infrastructure. Smaller vendors have the least patch infrastructure, which makes them the most attractive entry point of all.

Palantir just proposed a standard for this

In May 2026, Palantir published the Mission Assurance Security Standard for Software, or MA-S2. It is a candidate standard, released publicly for comment, fronted by Shyam Sankar. The framing in its opening pages is the same argument this article has been making. AI-assisted vulnerability discovery has created what Palantir calls "a new bottleneck of vulnerability triage, remediation, and orchestration."

MA-S2 is designed to sit on top of existing frameworks like SOC 2, FedRAMP, IL5/IL6, NIST SP 800-53 and ISO 27001, rather than replace them. It addresses the specific gap those frameworks were not written for: software security in an environment where adversaries have automated, high-volume vulnerability discovery.

The standard sets out four control domains.

Discovery is continuous and AI-augmented. Periodic matching against a known-CVE database is no longer enough.

Triage runs through attack path modelling, ranking a finding by where it sits in a real attack chain rather than by its raw severity score.

Inventory is real-time and machine-readable. Every vendor knows exactly what software is running where, on what version, air-gapped environments included.

Remediation is orchestrated across the entire fleet from a single control plane. Patches are deployed or vulnerable releases recalled without manual, environment-by-environment work.

What makes MA-S2 useful beyond Palantir is how it is meant to be used. An organisation can run it as an internal self-assessment of its own software posture. A procurement team can use it to evaluate the software vendors it buys from.

The appendix sets out seven plain questions any buyer should be able to get answered, including how patch deployment is orchestrated across a fleet, how long it takes from identifying a vulnerability to deploying a fix in a customer environment, and how the process handles air-gapped or compliance-constrained environments. If your vendors cannot answer those, you have a meaningful gap.

Where Apollo and Foundry fit

MA-S2 is written to be vendor-neutral and does not require Palantir. It is not a coincidence, though, that the standard reads like a description of infrastructure Palantir already runs.

Palantir Apollo is the continuous deployment layer underneath Palantir's own products. It orchestrates deployment across cloud, on-premise, edge, and air-gapped environments from a single control plane. That is the autonomous remediation orchestration domain of MA-S2 in practice. The published Foundry release notes show platform updates shipping weekly, not quarterly. When a vulnerability is found in the platform, the patch reaches every Foundry environment, including the air-gapped ones, without the customer coordinating the deployment.

Building on Palantir Foundry and AIP addresses the other side of the standard. Apps built on the platform inherit its security primitives: authentication, access control, audit, lineage, sandboxing of custom functions, and governance of AI models and agents. Custom code surface area shrinks substantially compared to a full-stack build, which means there is far less of your own code for an AI scanner to find bugs in.

Apollo was built by Palantir to solve its own problem first. The company had to ship software to defence and intelligence customers across networks with no internet access, on infrastructure the customer could not modify, in environments where patch latency is operationally critical. Two decades of deploying into that environment is what MA-S2 now sets out as the standard.

The board question

CSA has already shifted the conversation to the board. MAS has convened bank CEOs. The next letter from a regulator may go to your chair.

Two questions worth getting an answer to before it does. How long is your patch window, and what would it take to compress it by an order of magnitude? And can your software vendors answer the MA-S2 procurement questions, because if they cannot, their exposure becomes yours.

The discovery side has moved to hours. The infrastructure to compress the remediation side already exists. Whether your enterprise adopts it, and holds its suppliers to it, is what your board will eventually have to answer.