Skip to main content

Command Palette

Search for a command to run...

Two Races at Once: Why AI Is Both a Security Emergency and a Competitive One

Updated
•4 min read•View as Markdown
Two Races at Once: Why AI Is Both a Security Emergency and a Competitive One
H
Father of two, tech lover. Building systems by day, raising curious minds by night.

This is the second chapter of Built to Leave, a series on cloud dependency, sovereignty, and the architecture that makes exit possible. The series follows the problem from its origins — the build-vs-buy trade-off that predates AI — through the structural costs of cloud dependency, the work required to regain control, and the architectural shift that AI workloads are now forcing. Full table of contents: nightthoughts.hashnode.dev/build-to-leave


The previous piece ended with two forces pulling financial institutions toward the same infrastructure, for very different reasons: one defensive, one competitive. This piece looks at what that means once both land on the same roadmap at the same time, based on what I've seen in cloud transformation work, kept at the general level rather than tied to any one employer.

Security is not one bank's problem

Security in a bank is never negotiable. A serious breach doesn't stay contained — banks are wired into each other, and a failure at one institution can ripple into all of them. That's why the sector's response is increasingly collective, not institution by institution. Project Glasswing, launched by Anthropic in April 2026, brings major banks and hyperscalers together — JPMorgan, AWS, Google, Microsoft, Palo Alto Networks — to jointly use AI to find and fix vulnerabilities before attackers do, and by June 2026 it had expanded to roughly 150 more partners across 15+ countries.

The urgency behind that effort just became a lot more concrete. On September 3, 2026, OpenAI released GPT-6 Astra — the first commercial AI model to reach OpenAI's own "Critical" threshold for cybersecurity capability. According to OpenAI's system card, Astra can find previously unknown security flaws and develop new ways to exploit them across well-protected systems, without a person guiding each step. In pre-release testing it discovered two zero-day vulnerabilities on its own. This is no longer hypothetical. As of this month, that capability exists commercially, under gated access. Fighting it requires AI-capable defense, alongside the discipline that comes with it: zero trust as a default, continuous scanning across binaries, source code, third-party libraries, and internal systems, and relentless tracking of vulnerabilities before they can be weaponized.

The other pressure

Security isn't the only force reshaping the roadmap. A second pressure is building in parallel, and it decides who's still standing in five years: competitiveness. There are two different things "AI" can mean here. One is tooling — copilots inside email, code, presentations — which makes existing work faster without changing what the business does. The other is AI as a business function: pricing, credit scoring, fraud detection — AI that changes the product itself. That second category is what actually moves the competitive needle.

Institutions that adopt it early are already pulling ahead on cost and performance; slower movers risk a cost base they can't compete with. Multiple surveys show banks now ranking cost reduction and productivity ahead of security as reasons to invest in AI. Even inside institutions that treat security as non-negotiable, the case for AI is increasingly built around staying competitive, not just staying safe.

Where I've seen this actually play out

The technology was rarely the hardest part. Two things running in parallel were.

The first is applying real security discipline against a technology landscape that, in most institutions I've seen, was never built with that discipline in mind. You can't zero-trust your way through hundreds of small, loosely documented applications overnight, especially against an adversary that can now automate vulnerability discovery at machine speed. Every one of those applications is its own scanning target, its own audit trail, its own zero-day exposure to track. Multiply a hard problem by a fragmented estate, and it becomes close to unmanageable regardless of budget.

The second is organizational: getting an institution to agree, in practice and not just in principle, on what gets funded first when security and AI competitiveness are both labeled the top priority. They compete for the same architects, the same budget cycle, the same production windows. That tension doesn't resolve through better slogans. It resolves by removing the reason it exists.

The fix nobody wants to do first

Most institutions aren't failing to prioritize security or competitiveness. They're trying to do both against an application landscape that should never have gotten this fragmented. Every small, tactically-built application — built to hit a deadline, wrapped around

Built to Leave

Part 2 of 3

# Built to Leave *How cloud dependency became the default — and what it takes to build systems you can actually leave.* A seven-chapter series on cloud dependency, sovereignty, and the architecture that makes exit possible. From the build-vs-buy trade-off through jurisdictional risk, the work of regaining control, and the platform shift AI workloads are now forcing. --- ## 📚 Table of Contents | # | Chapter | Status | |---|---|---| | 1 | [The Old Trade-off — Vendor vs. In-House Before AI Changed the Rules](https://nightthoughts.me/the-old-trade-off-vendor-vs-in-house-before-ai-changed-the-rules) | ✅ Published | | 2 | [Two Races at Once — Why AI Is Both a Security Emergency and a Competitive One](https://nightthoughts.me/two-races-at-once-why-ai-is-both-a-security-emergency-and-a-competitive-one) | ✅ Published | | 3 | [The Sovereignty Illusion — What Companies Get Wrong About Cloud Independence](https://nightthoughts.me/the-sovereignty-illusion-what-companies-get-wrong-about-cloud-independence) | ✅ Published | | 4 | You Can't Govern What You Can't See | 🚧 Coming soon | | 5 | The Architecture of Exit | 🚧 Coming soon | | 6 | Built for the Wrong Workload | 🚧 Coming soon | | 7 | Orchestrating the Agents | 🚧 Coming soon |

Up next

The Sovereignty Illusion: What Companies Get Wrong About Cloud Independence

This is the third chapter of Built to Leave, a series on cloud dependency, sovereignty, and the architecture that makes exit possible. The series follows the problem from its origins — the build-vs-bu