How Standard Chartered Uses Frontier AI to Hold the Defender's Window

In an enterprise security conversation hosted by OpenAI, Ruben, Head of Security at Standard Chartered, shared how his team leverages frontier AI models to navigate the latest wave of offensive and defensive competition. The discussion centered on a single concept: the Defender's Window. As frontier models dramatically shorten the time it takes attackers to understand software and identify vulnerabilities, a global bank on the defensive side must gain clarity — faster than the attackers — on which vulnerabilities are truly exploitable.

From "Finding Vulnerabilities" to "Understanding Exploitability"

Ruben highlighted a critical shift that many security teams overlook: the goal shouldn't be adding more entries to an already-long CVE list, but understanding what is actually exploitable.

"Attackers aren't ultimately staring at code repositories and assets," he emphasized. "They're looking at attack paths that cut across systems, APIs, identities, and trust boundaries." This means traditional security programs centered on repositories and individual assets are inherently misaligned with how attackers actually think. The value of frontier AI lies precisely in its ability to span architectures, traverse large numbers of microservices and their repositories, and understand what's actually happening between systems.

Standard Chartered was one of the first banks to evaluate Daybreak, OpenAI's security product. Their initial motivation was straightforward: validate whether frontier AI could deliver risk insights that traditional methods simply couldn't — whether it could understand what was happening across repositories, architectures, and trust boundaries. Early observations confirmed this hypothesis: when the system could understand the full picture across architectures and numerous microservices, the findings were significantly more numerous and more valuable.

CVE (Common Vulnerabilities and Exposures) is a vulnerability identification system maintained by MITRE, where each entry corresponds to a publicly disclosed security flaw. Large enterprises routinely accumulate tens of thousands of CVE backlogs, leaving security teams perpetually stuck in a "find more than we can fix" bind. Traditional scanning tools score vulnerabilities on a per-repository or per-asset basis (e.g., CVSS scores), but cannot answer a more operationally critical question: can an attacker chain together several low-severity vulnerabilities into a complete attack path that traverses multiple systems? This "cross-trust-boundary attack path" perspective is precisely the shift Standard Chartered emphasizes — the benchmark for measuring risk isn't a vulnerability's theoretical severity, but whether it can be practically exploited within the real network topology and identity infrastructure.

Context Matters More Than Model Choice

A phrase that recurred throughout the conversation was "context is king." Ruben arrived at a striking conclusion: having sufficient context is more important than which model you choose.

So in practice, what do you feed the model beyond the codebase? He listed several critical inputs: architecture diagrams and deployment models, asset dependency relationships, other services that connect to or are called by the component, and the original solution intent behind the component. The richer the context provided, the better the results.

Interestingly, this exploration also exposed some taken-for-granted gaps in the SDLC (Software Development Life Cycle). The team had assumed development teams would continuously maintain architecture documentation and similar artifacts — only to discover significant gaps. Those gaps need to be closed before AI can be given accurate context.

SDLC (Software Development Life Cycle) refers to the full process from requirements analysis, design, and coding through testing, deployment, and maintenance. The concept of "shift left" comes from imagining SDLC phases laid out on a timeline left to right, then moving security checks as far left as possible — into the coding or even design phase — rather than waiting until pre-launch or post-incident remediation. The architecture documentation gaps exposed in Standard Chartered's case are a common obstacle to shift-left adoption: if development teams don't continuously maintain architecture diagrams and dependency documentation, the context an AI model receives becomes distorted, and the resulting risk assessments drift from reality. This finding suggests that the ceiling on AI-assisted security tooling is often determined not by model capability, but by an organization's maturity in documentation and knowledge management.

Making AI Findings "Trustworthy"

Introducing AI tools into a security workflow is only partly a technology challenge — the bigger challenge is how teams operate and how to earn the trust of development teams.

"Just running a demo for the dev team isn't enough. You need hard evidence," Ruben said. Standard Chartered's approach was to form cross-functional groups pairing the application security team with development teams. Every finding had to be validated against code, against architectural deployments, and against the real environment — and that work had to be done together.

More importantly, there's a mindset shift required: stop fixating on "what did we find" and focus instead on improving remediation efficiency and achieving the right security outcomes. When developers understand the root cause of a problem, they won't build the next feature the same way; and rather than "naming and shaming," the goal is to fix issues together — even using frontier AI to assist with remediation. "This isn't just another dashboard," Ruben concluded, and it's not about piling another item onto the backlog.

Using Speed to Redefine Security's Role

Large institutions like Standard Chartered have established processes and governance structures that were often not designed for the speed required today. How do you build internal organizational confidence to keep pace?

Ruben's answer is to change how security is positioned within the organization. Historically, security has been seen as a gatekeeper or a blocker — now it needs to become an enabler. The practical approach is to integrate security capabilities into the pipeline and give developers earlier access — that is, to "shift left." He particularly endorsed the idea of giving developers a virtual sandbox environment in the development cycle, allowing them to validate at runtime that a vulnerability is actually exploitable, and then prioritize by exploitability once they see the evidence. When developers realize the security team is helping them "move faster and more safely," trust builds naturally. This aligns with the philosophy of using agentic coding tools to accelerate work and avoid creating the traditional security burden.

Build the Foundation: AI Amplifies Everything It Sees

When asked "how should you think about security differently than you would have five years ago," Ruben offered a piece of advice that is both pragmatic and worth deep reflection for any security leader: get the fundamentals right first.

He outlined several foundational priorities: reduce technical debt, lower technical complexity (for example, don't use too many programming languages), keep architecture documentation up to date, and establish solid identity and access controls. The reasoning is direct: "When AI is unleashed into an environment, it amplifies everything it sees." Organizations with a solid foundation are the ones who will extract the most value from AI.

One finding that was slightly surprising — yet reassuring — was that testing didn't surface a flood of outrageous issues. Most findings were within the range of what the team expected. But one category of issues did emerge: problems in areas that traditional tools had been unable to identify before. That is precisely the core value of the new approach.

A Global Footprint: Team Structure and the Road Ahead

Standard Chartered operates across numerous global markets, facing a wide range of regulatory regimes and systems. Its security coverage is enormous — far more than just scanning code repositories.

Fortunately, its development teams are concentrated in a few hubs, which makes coordination and collaboration more manageable. Standard Chartered's vision for its security team is to "empower developers to self-serve with the right tools" — enabling them to move forward safely while placing the right checks at the right moments.

Ruben also laid out clear expectations for product teams like OpenAI: the ability to run at scale. Scanning repository by repository doesn't scale. He wants to run batch operations and detect vulnerabilities across a sandbox environment. Because large numbers of applications are interconnected, what defenders truly need to understand is the blast radius — if something gets compromised, how far can the attack spread? He expressed enthusiasm for OpenAI's concept of a "defense factory."

This conversation sketches a portrait of enterprise security's transformation in the age of frontier AI: from accumulating vulnerability lists to focusing on exploitability; from acting as a blocker to becoming an enabler; from relying on model selection to investing in context quality and foundational infrastructure. The defender's window is narrowing, and outrunning this race demands not just technology, but a fundamental reimagining of how organizations collaborate.

"Blast radius" is a term borrowed from explosion physics. In security, it refers to the maximum range of assets that an attacker can reach through lateral movement after compromising a single component or account. In microservices architectures, services are tightly coupled through APIs and internal trust relationships, meaning the compromise of a low-privilege service can rapidly propagate through service call chains all the way to core data layers. The "defense factory" concept is essentially about automating and scaling blast radius analysis — moving away from isolated per-repository assessments and instead simulating real attack propagation paths in a sandbox. This allows defenders to see, before an attack occurs, "if this gets breached, which systems get hit next" — enabling remediation priorities based on actual impact scope rather than theoretical scores.