Details
How to operationalize AI security for faster development, real risk reduction, and sustained governance in regulated environments
AI-generated code, autonomous tools, and agentic workflows introduce risks faster than traditional security processes can review them. Attackers are also using AI to find, combine, and exploit vulnerabilities more quickly.
Financial services organizations therefore need continuous controls that can keep pace with changing systems and threats—not only periodic reviews of static assets.
The session describes a growing mismatch: AI can increase code generation by 10x while compliance reviews continue at 1x speed.
Manual reviews, periodic scans, and post-development gates cannot support that volume. FinServ teams need to embed security testing, policy enforcement, and evidence capture directly into development workflows.
Shift-left security remains important, but controls must now reach IDEs and AI coding assistants.
Developers should receive security feedback while code is being written, supported by pull request and CI/CD checks that stop policy-breaking issues before they reach production.
AI-generated code can produce more findings than security teams can manually review. Severity-only triage can create noise and delay meaningful remediation.
Teams should prioritize issues based on exploitability, reachability, business impact, policy requirements, and exposure to sensitive data. AI can then help accelerate validated fixes.
Agent risk begins before deployment. Toxic skills, prompt injection, excessive access, and unsafe tool-data-action chains can become embedded in applications.
In production, those weaknesses interact with real users, systems, and sensitive data. Security controls must therefore follow agents across their full lifecycle.
The session recommends a practical maturity path:
Stabilize: Establish visibility and implement preventative guardrails.
Optimize: Prioritize real exposure and accelerate remediation.
Scale: Prove outcomes with evidence and introduce agentic orchestration.
The objective is not to generate more findings. It is to prevent issues earlier, reduce material risk faster, and maintain audit-ready governance.
Practical implication: Use continuous controls across development and runtime instead of relying on periodic reviews.
Practical implication: Build automated policy checks and evidence capture into developer workflows.
Practical implication: Assess AI assistants, skills, models, toolkits, and MCP servers before deployment.
Practical implication: Prioritize exploitable, reachable, and business-critical issues, then use AI to accelerate remediation.
Practical implication: Track prevention, remediation speed, security coverage, and audit-ready evidence—not just vulnerability counts.
AI increases the speed and volume of code, while many security programs still depend on periodic scans, manual triage, and post-development reviews. This creates delays or allows risks to bypass governance.
Embed preventative security testing in IDEs and AI coding assistants. Reinforce it with pull request and CI/CD checks so developers can address issues before deployment.
Severity-only queues can create large backlogs without identifying which issues pose real risk. Teams should also consider exploitability, reachability, business context, policy, and data sensitivity.
Key risks include vulnerable skills, prompt injection, excessive access, unsafe tool and data flows, destructive agent behavior, access-control failures, hallucination, model drift, and unapproved AI components.
Start by establishing visibility and preventative guardrails. Then prioritize and remediate meaningful risks. Finally, use evidence and orchestration to scale governance across development and production.
Ken Underhill: Hello everyone and welcome to today’s DZone webinar, “Why Traditional Security Fails the FinServ Speed Test.” I’m Ken Underhill and I’ll be your host for today’s session. Financial services organizations are moving quickly to adopt AI-assisted development, but many security programs are still built around processes designed for a much slower pace. As AI accelerates software delivery, security teams are being asked to keep pace. The challenge is reducing risk without slowing development. Today’s discussion will explore what that shift means in practice and how organizations can modernize their approach to application security.
Now, before we get started, just a few housekeeping items. Today’s session is being recorded and the on-demand recording will be shared with all registrants after the event. Also, if you have any questions during the session, please submit those through the Q&A panel and we’ll try to answer as many as possible at the end.
Now, I’m pleased to introduce today’s speaker, Kate Burke. She’s Senior Product Marketing Manager at Snyk. Kate works closely with organizations navigating modern application security challenges and helps teams adopt developer-first security practices that scale with today’s software delivery environments. So Kate, thanks for joining us today and I’m going to hand it over to you.
Kate Burke: All right, hello everyone and welcome to our session today, “Why Traditional Security Fails the FinServ Speed Test.” We’ll be talking about how to operationalize AI security for faster development, real risk reduction, and sustained governance in regulated environments.
I’m really excited to chat on this topic with you. Before we jump into it, I want to thank you for joining us today. My name is Kate Burke. I’ve been working in product here at Snyk for several years, where I’ve had the opportunity to see firsthand the collaborative nature that development and security teams can have with the right tools in place.
It’s been an exceptionally exciting time in the last year or two, in which we’ve seen AI become more accessible and pervasive in our day-to-day lives. You know, there’s a huge amount of change going on, and I’m sure none of us on the call are impervious to it.
So, we’ll start out our session by exploring how AI has impacted development. Then, we’ll jump into the prescriptive path that Snyk has introduced for operationalizing AI security, including an overview of our agent security platform. So, lots to get to today in our short session.
So as we talk about how AI has impacted development, I won’t backtrack all the way to waterfall development. Instead, we’ll do a little bit of oversimplification and break the DevOps infinity loop into four stages, and it starts with developers writing code. Then an application gets built and deployed to production.
DevSecOps and shift-left approaches are really about embracing security within those stages. As developers are writing code, integrating preventative security testing into the IDE allows them to find and fix issues early.
Teams with more mature security development practices may use the pull request as a point of enforcement—checking the pull request itself for security issues, blocking it from being merged if a policy-breaking issue is found.
Once an app is deployment-ready, runtime assessments like DAST may be used to find more issues. And then once it’s deployed to production, teams have to use monitoring and detection and response tools.
I want to be clear, I’m not saying that doing these things is not important or that this approach is outdated, but AI is having a dramatic impact on every single one of these stages.
So, the CEO of Anthropic recognizes this and made a prediction in March of 2025. At the time, it seemed like a pretty incredible claim, betting that by the end of last year, AI would be writing the vast majority of code, and that soon enough it’ll be writing nearly all of it.
The stats you see on this can vary. I’m not sure we’re at the nearly all code stage quite yet. But we’ve heard of vibe coding. We’ve all heard of it. We’ve done it. Maybe our teams are doing it, or other teams at the business.
Developers are orchestrating many coding agents at once. Think of the example of CloudCowork, which was built in 10 days entirely by Claude Code. These types of innovations come with real threats that we have to be aware of working in regulated environments.
So let’s talk about those threats. As organizations move up the AI maturity curve, they are adopting a completely new system that doesn’t just expand their attack surface; it evolves it at machine speed.
There are entirely new threat vectors that we’re introducing that are still being discovered. Attackers are adopting AI systems too, which means getting from issue to exploit faster and chaining them together autonomously. It is happening while we’re sleeping. We’ve seen this in a number of zero-days that have occurred in the last few weeks alone.
A few stats to look at when we think about the compounding risk problem flashed up on the screen. These AI systems are doing incredible things for a company’s velocity, dramatically increasing the speed and volume at which code is being delivered, but they’re also introducing traditional issues and novel attack vectors with it. As I mentioned, AI is being used to accelerate the time from issue to exploit as well.
The most recent example would be the risks in the agent skills used by OpenClaude. At the time of this session, there are actually even more recent ones now that I think about it.
All this is happening before we get into the world of fully agentic AI. If you haven’t been caught in the Cloudbot or Multibot or OpenClaude evolution, it’s a self-hosted AI agent that people are using as a proactive personal assistant connected to LLMs to manage local files, use messaging apps, autonomously execute real-world tasks like managing emails or scheduling meetings, and even running shell commands.
It’s also widely recognized as the fastest-growing repo in GitHub’s history. It surged from roughly 9,000 to over 200,000 stars in only 60 days. So, it’s unbelievable productivity that’s being unlocked. But some spectacular researchers from Snyk dove into the skills and the plugins that give AI agents real execution power and found that 37% contain at least one security issue and 13% have a critical security issue.
In financial services, we are not just fighting hackers. We are fighting the clock. AI has made code generation 10 times faster, but our compliance reviews are still running at 1x speed. This gap is really where the most dangerous risks live.
While AI accelerates code, we in FinServ organizations are bound by regulations like DORA, PCI, and SOC 2. Traditional security slows down the speed test because compliance is often a manual post-development gate, without necessarily the checks and balances or reporting built into your system to allow you to complete that check faster.
In regulated environments, the concept of “move fast and break things”—we have to face the reality that it isn’t an option.
Legacy security is the bottleneck to an AI-driven market. AI is accelerating code delivery to machine speed, while security remains fragmented and manual. Periodic scans and manual triage can’t scale as fast as we need them to.
Finally, there’s a risk choice that has to be made between slowing the time to market for customer deliverables and services, or accepting the shadow risks that bypass governance.
The cost of failure associated with retaining legacy security in today’s AI-driven world is very real. Breach exposure and business auditability are top security executive concerns that we hear here at Snyk, and rightfully so given that these issues are exacerbated by the presence of AI in your own code and in the tools that threat actors are using.
So circling back to our simplified DevSecOps steps, AI raises questions across every single stage of this process.
At the code level, when coding assistants are generating code faster than ever, how do you prevent issues? At the build stage, when the volume of issues in that code balloons, how do you effectively prioritize them? Can you use AI to remediate them?
At deployment, as we progress through the process, how do you maintain a developer-friendly workflow? And finally at production, how are you avoiding a purely reactive program where issues are found in production and then get thrown over the wall back to development later on for fixing?
Today, Snyk is delivering on this vision through our AI security platform. We are no longer just a developer security company; we’re securing code models and intelligent systems in the AI era.
Jensen Huang’s famous five-layer cake describes the modern tech AI stack, but security is missing from it entirely and we are filling that gap. Our new mission says it clearly: to unleash AI innovators securely.
We operationalize this vision through core areas of competency based on three critical problem areas we see in the market today, which are exacerbated when we’re in highly scrutinized, regulated environments dealing with incredibly sensitive, protected customer data.
So the first is automated AI attacks and accelerated risk. With machine-speed threats occurring today, it’s eliminating the luxury of a backlog; AppSec must operate at AI speed.
We also see untrusted agentic development: AI agents writing insecure code, using unvetted tools, and operating with excessive access, really.
Finally, ungoverned AI applications: this is enterprises deploying AI agents with no inventory, no policy management, and no audit trail. All three are great threats in today’s world.
The foundation of our platform is our security engines, providing deep and accurate visibility into vulnerabilities. On top of that sits our AI workflows, and this is where security becomes part of how software itself is actually built.
Looking here at the center of the screen, we embed—as you very well may know already, Snyk’s history is that our core value brings the workflow into the developer’s lifecycle.
Today we embed directly into the developer tools, the CI/CD, and now in AI coding assistants. So issues are prevented, prioritized, and fixed in flow.
Then there’s a third layer, which is agentic orchestration. This is where the platform starts to operate at machine speed. We observe patterns, coordinate actions, and close the loop across prevention, remediation, and policy.
But having a powerful platform isn’t enough on its own, and that is why we’ve also developed a path—a framework in which you operationalize the platform itself to guide through this new era of security.
The prescriptive path is how we’re doing so. It starts with stabilizing your environment. You have to have a solid foundation of visibility into your application estate and then stop the bleed by implementing those preventative guardrails—step one and step two.
Next, you can start to optimize by reducing risk effectively. Strategically prioritize what to spend your focus and energy on where you’ve got the resources allocated, and then use AI to help accelerate the remediation component.
Finally, you can scale: prove the impact of your program with evidence and branch into orchestration through agents.
What we also have invested in greatly over this last year is the agentic security side of things. So I want to call out a challenge focused on this topic, and where we see that is governing the full agent lifecycle.
This is incredibly pervasive today. It’s a two-front situation or two categories, right? There’s untrusted agentic development that’s happening with coding assistants and with the tools that are being used to actually create code. And then there’s ungoverned AI-based applications.
With this whole slew of problems, there’s shadow AI everywhere. We’ve got models, agent toolkits, and MCP servers introduced into repos and dev endpoints without oversight.
There’s no system of record for AI risk. There are no CVEs for poisoned models, unsafe prompt frameworks, or risky agent behaviors embedded into code.
Manual governance that developers are bypassing is another issue. More static tools that have been approved—these lists and ticket-based approaches or requirements that require approvals slow teams down and they can get ignored.
Finally, we’re seeing late detection and expensive remediation. The risks with AI are often discovered only after deployment, when architectural mistakes are harder and much more costly to reverse.
So securing the full agent lifecycle and providing governance and enforcement that protect builders, protect the agents, and protect AI-native applications at scale is what’s required.
What we’re seeing in the field is that agent risk shows up in these two places that I delineated: untrusted agentic development and ungoverned AI applications. The key point being, these risks are connected.
It starts in the developer environment where teams are rapidly adopting agentic tools. Inside that environment, we see things like toxic skills, prompt injection in development workflows, and unsafe, toxic flows where agents chain together tools, data, and actions.
In some cases, agents even exhibit hammer behavior—repeatedly executing unintended or destructive actions. The challenge is that this is all happening before production, so insecure behavior is getting built directly into apps.
Then those same issues show up in production, and now they’re exposed to real users and real data. Now we see prompt injection from external users, BOLA-style access issues, the same toxic flows across live systems, and model risks like hallucinations or drift.
What we’re seeing is that at this point, agents aren’t just generating code; they’re making decisions and interacting with sensitive systems, which raises the impact significantly.
So the core problem is these risks originate in development and are exploited in production, and most tools only see one side.
What teams actually need is visibility into agent usage, the ability to prioritize risk, and then controls that span both dev workflows and runtime. That is the gap we’re solving with agent security.
So, as we wrap up, I want to put a lens on this and talk about why a mature platform is the prerequisite for AI innovation. We want you to be achieving positive business outcomes.
Our customers who follow the prescriptive path and embrace the platform actually unlock AI innovation, and they move from fragmented visibility to unified awareness.
Instead of a gap between the velocity of development and security, they get AI fortifying prevention at speed, and alert fatigue is cured with prioritization thanks to the context.
There’s a customer success story on this homepage that’s a real-life example of this in action. Yellow—not only did they see a 90% reduction in noise, they also embraced the full Snyk platform, covering their complete risk landscape.
As they lean into AI, they know that Snyk will partner with them to secure it, and this is the kind of story that we want you all to have as well.
So as we wrap, I have one quick plug before we close out the session. If you’re using AI coding assistants today—whether it’s Cursor, Windsurf, Claude Code, or something else—Snyk Studio is available to help you secure the code that those tools generate at inception.
Just scan this QR code and get started with just a few clicks. You can also get access to a live demo and see more of Snyk in action than we were able to show in today’s session.
But I just want to thank you all so much for joining. It’s been a pleasure and we look forward to seeing you at the next one.
Ken Underhill: Well, thank you Kate for sharing such valuable insights and thank you to everyone that joined us today. We appreciate you spending part of your day with us.
Again, keep your eye out on the inbox for the on-demand recording and we hope to see you again at a future DZone webinar.
Presenters:
Kate Burke
Senior Product Marketing Manager, Snyk
Join Now for More Content & Events
For event and sponsorship inquiries, please email: [email protected]
