Financial services firms have quietly become the heaviest institutional users of AI coding assistants — and the least prepared to audit what those assistants are actually producing. Internal surveys from major banks now put AI-assisted code at 30-40% of new commits in some engineering organizations, up from single digits just two years ago. At the same time, security teams inside those same institutions report that dependency and provenance reviews have not scaled to match. The gap between how fast AI writes code and how fast humans can verify it is where the hidden cost lives.
This is not a story about AI writing buggy logic, though that happens too. It is a story about what AI code drags in behind it: unvetted packages, invented dependencies, inconsistent SBOMs, and a review process built for a world where a human wrote every line and had to justify each import. In a sector governed by DORA, FFIEC guidance, PCI DSS 4.0, and SOC 2 attestations, that gap is no longer just a security problem — it is a compliance and balance-sheet problem.
The Adoption Curve Outpaced the Controls
Financial services adopted AI coding tools faster than almost any other regulated industry, driven by intense pressure to modernize legacy cores, ship digital products, and compete with fintech challengers on release velocity. Engineering leaders at several top-20 US banks have described internal mandates requiring teams to demonstrate AI-tool usage in sprint planning. Copilot-style assistants, AI-native IDEs, and agentic coding tools are now standard issue for application teams touching payments, lending, and trading infrastructure.
The controls did not move at the same speed. Most application security programs in banking were built around a threat model where a developer chose a dependency deliberately, usually from a small internal allowlist, and a security review happened before merge. AI code generation breaks that model in three ways that matter for cost accounting:
- Suggestion volume outstrips review capacity. A single engineer using an AI assistant can generate the dependency footprint of an entire sprint's worth of manual coding in an afternoon. Manual security review, threat modeling, and SBOM reconciliation processes calibrated for pre-AI velocity simply cannot keep pace, and backlogs accumulate silently rather than blocking releases.
- Package hallucination introduces a novel attack surface. Multiple academic and industry studies through 2024 and 2025 found that large language models used for code generation recommend non-existent package names at meaningful rates — in some tested models, north of 20% of suggested third-party packages in certain languages did not exist on the registry at the time of suggestion. Attackers have responded with "slopsquatting": pre-registering the plausible-sounding package names LLMs are statistically likely to hallucinate, then waiting for a developer's assistant to suggest it and a build pipeline to pull it down.
- Provenance gets flattened. When a human copies a snippet from Stack Overflow, there is usually a comment, a link, or institutional memory of where it came from. AI-suggested code and AI-selected dependencies frequently ship without any trace of provenance, making SBOM accuracy and license compliance — both material to a bank's audit posture — much harder to maintain after the fact.
What the Regulators Are Already Signaling
Financial regulators have not written AI-specific supply chain rules yet, but the direction of travel is unambiguous. The EU's Digital Operational Resilience Act (DORA), which became enforceable in January 2025, explicitly extends ICT risk management obligations to third-party and dependency risk, with examiners expected to ask financial entities to demonstrate they know what is running in production and where it came from. In the US, the OCC and FFIEC have both issued guidance in the past two years emphasizing third-party risk management and software integrity as supervisory priorities, and several 2025 exam cycles reportedly included pointed questions about AI-assisted development practices and dependency provenance.
The subtext is consistent across jurisdictions: regulators are not waiting for a named "AI code" rule before treating an AI-introduced vulnerability the same as any other unpatched, unreviewed dependency. A compromised or vulnerable package is a compromised or vulnerable package regardless of whether a human or a model chose it, and existing operational resilience, vendor risk, and incident disclosure obligations already apply.
Where the Cost Actually Shows Up
"Hidden cost" is the right framing because very little of this shows up on a single line item. It surfaces in five places, each of which compounds the others:
1. Remediation debt. Security teams at mid-size and large financial institutions report that AI-introduced dependencies now account for a disproportionate share of newly discovered vulnerabilities in quarterly scans — not because AI code is inherently less secure, but because it introduces more total dependencies, more often, with less individual scrutiny per package. Each one becomes a ticket, a triage decision, and often a production deploy to remediate.
2. False-positive fatigue. Traditional SCA (software composition analysis) tools flag every vulnerable package in the dependency tree regardless of whether the vulnerable function is ever called. When AI assistants pull in larger, more generic dependencies to satisfy a narrow task, the number of flagged-but-unreachable CVEs grows disproportionately. Teams either burn analyst hours chasing non-exploitable findings or, worse, start ignoring the queue altogether — a well-documented precursor to missing the one finding that does matter.
3. SBOM drift. Audit-grade SBOMs are now a baseline expectation for financial services vendors and, increasingly, for internal platform teams under DORA-style scrutiny. AI-generated code that introduces dependencies outside the normal PR-and-approval workflow creates drift between what the SBOM says is running and what actually is, which turns every audit cycle into a reconciliation project rather than a report-generation exercise.
4. Incident response cost. When a vulnerable or malicious package is confirmed in production, financial services incident response is materially more expensive than in other sectors because of mandatory regulatory notification timelines, customer disclosure obligations, and the forensic requirement to prove exactly which systems and data were exposed. A dependency nobody remembers choosing is much harder to trace quickly.
5. Velocity tax. Ironically, the productivity gains AI coding tools promise get partially clawed back by the review overhead needed to compensate for lower per-dependency scrutiny. Several engineering organizations have reported that security review cycle time increased even as raw code output increased, because reviewers now have to do more provenance verification per pull request.
The Pattern Behind Recent Incidents
The slopsquatting and hallucinated-dependency research from 2024-2025 was not theoretical — proof-of-concept and real-world package registrations exploiting the pattern have already been documented across both PyPI and npm ecosystems, targeting package names that multiple popular coding models independently hallucinated across repeated queries. The attack is cheap to execute and scales with AI adoption: the more organizations lean on AI code generation, the more predictable and reproducible the hallucinated names become, and the more valuable it is for an attacker to squat on them in advance. For a financial services firm with hundreds of repositories and thousands of weekly AI-assisted commits, the exposure window is not hypothetical — it is a function of how many times a model gets asked a similar question.
How Safeguard Helps
Safeguard is built for exactly this gap between AI-assisted development velocity and the provenance, exploitability, and compliance rigor financial services teams are accountable for. Our reachability analysis cuts through SCA noise by determining which flagged vulnerabilities in AI-introduced dependencies are actually callable from your code paths, so security teams triage the handful of exploitable findings instead of drowning in theoretical ones. Griffin AI continuously monitors code and dependency changes — including those introduced by AI coding assistants — to flag suspicious or hallucinated package patterns before they reach production. Safeguard's SBOM generation and ingest capabilities keep your audit-grade bill of materials synchronized with what AI tooling actually pulls into your build, closing the drift that turns DORA and FFIEC exam prep into a scramble. And when a fix is needed, Safeguard can open auto-fix pull requests that remediate the vulnerable or unverified dependency directly, giving engineering teams a review-ready patch instead of another item in an ever-growing backlog.