As AI lowers the cost and persistence of cyber‑attacks, weaknesses in core banking platform architecture become easier to find and exploit. 10x Banking’s Chief Information Security Officer, Richard Moore, outlines five practical questions banks should ask core banking vendors to assess whether their platforms can withstand AI‑driven security pressure.
The recent attention around Claude Mythos, AI agents, and “autonomous attackers” has understandably intensified security concerns across banking. Much of that discussion focuses on what these models are capable of doing. From a security practitioner’s point of view, that framing misses the more important shift.
AI has not changed the nature of cyber-attacks. The techniques that account for most real incidents are well understood: scanning for exposed services, exploiting known vulnerabilities, abusing credentials, and moving laterally through trusted systems. Those techniques predate Claude, and they are not going away.
What has changed is the economics; models like Claude reduce the cost of analyzing systems and repeatedly exercising the same attack paths. Activities that once required time, expertise, and persistence can now be carried out cheaply and continuously.
Most systems weren’t built for this level of repetition. Controls that are effective when exploitation is rare or selective often fail when the same weakness is tested over and over again without pause. Architectural shortcuts, slow patching cycles, and overly broad trust relationships stop being theoretical, one‑day risks.
This is where legacy technology becomes a real problem. Older core banking platforms were typically designed around infrequent change, expensive upgrades, and long patch cycles. Security fixes are bundled into major releases, which creates friction, cost, and delay. That delay used to be tolerable. Under AI‑driven conditions, it becomes a source of risk in its own right.
Older core banking platforms were typically designed around infrequent change, expensive upgrades, and long patch cycles... That delay used to be tolerable. Under AI‑driven conditions, it becomes a source of risk in its own right.
Through our work supporting our client JPMorganChase, a launch partner in Anthropic’s Project Glasswing, we see that the organizations responding best to cybersecurity challenges are reinforcing fundamentals that already mattered: containment, isolation, fast remediation, and evidence that controls work as expected under pressure.
The questions below are designed to assess whether your core banking platform can manage risk, scale, and resilience in today’s operating environment.
1. Is each bank fully isolated at the infrastructure level, or does the platform rely on shared components?
This is the first question I would ask of any core banking platform vendor.
AI makes persistent probing cheap. If a platform shares runtime environments, networks, identity systems, or trust relationships across multiple banks, any weakness that exists will eventually be discovered and reused. Logical isolation at the application layer may appear sufficient under normal operating conditions, but at scale it becomes a shared failure mode.
As a greenfield core banking platform, 10x was designed with this problem in mind from the outset. Each bank runs in its own isolated environment with no trust relationship to any other client. Production and non‑production environments are separated. There is no shared runtime, and no structural path for one bank’s issue to affect another.
Access is constrained as well. Client environments are isolated from 10x itself. There is no standing administrative access. Even platform engineers must request time‑bound access for specific tasks.
2. How much of the core banking platform is reachable from public networks?
Reducing attack surface is still key. Many platforms continue to expose services directly to public networks and rely on monitoring and detection to manage risk.
A more defensive design removes exposure wherever possible. At 10x, connectivity between our platform and client or integration partner systems is handled using private, cloud‑native services such as AWS PrivateLink. Services are not reachable from the public internet by default.
From an attacker’s perspective, this removes entire classes of automated scanning and exploitation. Banks should expect core banking platforms to explain clearly which services are exposed, why they are exposed, and what protections exist when exposure is unavoidable.
3. How quickly do vulnerabilities become non-exploitable once identified?
Legacy platforms often struggle here because upgrades are expensive and disruptive. Security patches are tied to major releases and so deferral becomes normalized. Under AI‑driven conditions, that delay becomes a material risk.
Modern platforms need to work differently. At 10x, continuous updating is part of the platform design. Clients are always on the latest supported version without additional cost or bespoke upgrade projects. That removes a persistent source of accumulated risk.
Open‑source dependencies are monitored and upgraded automatically through controlled artifact repositories. Unsupported software is tracked as an executive‑level risk, not deferred as technical debt. Vulnerability scanning is embedded directly into build and deployment pipelines, and high‑severity issues block promotion into production environments by default.
Claude increases the number of attempts. Whether those attempts result in impact depends on how quickly weaknesses are removed.
4. How is privileged access restricted, monitored, and time‑bounded?
AI doesn’t need special access. It abuses the access humans already have.
Standing privileged access is one of the most reliable paths from initial compromise to serious impact. If a device or credential is compromised, the attacker inherits the same level of access.
At 10x, access to production systems is just‑in‑time. No one has permanent administrative access. Access must be requested, approved, logged, and it expires automatically. If a device is not fully patched, access is denied. This applies to everyone, including our CEO.
At 10x, access to production systems is just‑in‑time. No one has permanent administrative access... If a device is not fully patched, access is denied. This applies to everyone, including our CEO.
This approach is intentionally restrictive. It limits blast radius when credentials are abused and removes long‑lived attack paths that AI makes easier to exploit.
Banks should be cautious of platforms that treat standing privilege as an operational requirement rather than a risk to be eliminated.
5. How are supply‑chain and AI‑generated changes governed and contained?
Core banking platforms are ecosystems. Open‑source libraries, cloud infrastructure, SaaS services, and AI tooling all become part of the attack surface.
AI lowers the barrier to analyzing the same open‑source components platforms rely on. That makes dependency hygiene critical. At 10x, dependencies are sourced through trusted repositories, and software bills of materials are maintained so exposure can be assessed quickly when new threats emerge.
The same discipline applies to AI. AI‑generated code, configurations, or recommendations are not treated differently. They are scanned, tested, and deployed through the same controls as human‑authored changes. AI changes scale, not accountability.
Banks should expect core platforms to assume supplier failure and design controls that limit impact when something upstream goes wrong.
Basics done brilliantly
None of this is new.
Most major incidents still come down to the same root causes: shared environments, excessive privilege, slow patching, unrestricted connectivity, and untested recovery. AI doesn’t introduce these problems. It removes the chance that they remain hidden.
That is why I often come back to the same phrase: basics done brilliantly.
If you built your core banking platform with designed isolation in from the beginning, removed standing access, restricted connectivity by default, updated continuously, and tested recovery regularly, AI increases pressure but not risk.
If you relied on legacy architecture, shared components, and infrequent upgrade cycles, Claude makes that visible very quickly.
For banks evaluating core banking platforms, these questions are not about predicting the future of AI. They are about understanding whether the fundamentals were done properly in the first place. If they were not, no amount of AI tooling will fix that after the fact.
