Talk by Eli Cohen of Snyk (co-founder of Helios), recorded at the AI Engineer World's Fair 2026, arguing that security must go on the offense in an agent-first world. Covers why AI-generated code and AI-powered attackers strain traditional security, how SAST, DAST, and periodic pen testing each miss different issues, and a proposed model of continuous offensive security using a team of AI agents (orchestrator, recon, vulnerability hunters, exploit-validating judge, remediation and reporting). Closes with four questions to ask an AI pen testing vendor. The speaker's claims about attack speed and tool limitations are presented as his perspective rather than independently verified results. # Channel Presentation Observations: "AI Hackers Are Faster Than Your Pen Test — Eli Cohen, Snyk" ## Source Basis - **Title:** "AI Hackers Are Faster Than Your Pen Test — Eli Cohen, Snyk" - **Transcript:** Supplied and used as the primary evidence. - **Curated metadata:** None supplied. Identity context comes only from the title and the speaker's own statements. - **Scope note:** These observations cover one conference talk. They do not establish channel-wide patterns. --- ## 1. Explicit Self-Description (Speaker Claims) The speaker describes his own background directly: > "Uh used to be co-founder and CEO of Helios, a runtime security company. got acquired by sneak and in the last two and a half years I had the privilege in working in sneak primarily on product management for AI products but more recently founding field CTO" Additional self-described identity and framing: - **Current role:** Field CTO, "working with developers and with security folks to better understand and to help them shape their strategy around AI security." - **Self-characterization:** A playful remark on career path: > "My my my dream was to be a rockstar, but I had to be a cyber entrepreneur." - **Affiliation:** Presents the talk as connected to the Snyk offering. He says the subject is "obviously very tied up to what we're doing within SNIK, but what I'm going to tell you today is general." **Note:** The transcript renders the speaker's first name as "Ellie," while the title gives "Eli Cohen." This is likely a transcription artifact. Name attribution here follows the title. --- ## 2. Intended Audience The speaker explicitly polls and addresses a mixed room: > "Who is here more from the development side of the table? Developers... From the security side of the table... and other people like sales, marketing, other people running agents in production that are not from developmental security." He states his tailoring intent directly: > "So I'm going to tailor this uh session towards everyone." **Observed framing:** The talk addresses developers, security practitioners, and non-technical business roles. It is pitched at an **AI engineering conference** audience ("obviously this is an AI engineering conference, right?"). --- ## 3. Claimed Scope ### Topical Scope - **Continuous offensive security**, the talk's stated subject from the opening: "We're going to talk today about continuous offensive security." - **AI-driven penetration testing** as a replacement for or augmentation of periodic manual pentesting. - **Agent red teaming**, including multi-step attacks such as prompt injection, data exfiltration, and goal hijacking. - **Application security testing categories:** static analysis (SAST), dynamic testing (DAST), and pentesting, framed as complementary. ### Product Scope (Stated) - The speaker introduces **"EVO continuous offensive security"** as the offering: > "this is why we're introducing EVO continuous offensive security." - He describes a multi-agent architecture: an orchestrator, recon, vulnerability testing, exploit validation ("the judge"), remediation, and reporting agents. ### Explicit Calls to Action - Evaluate vendors using four stated questions: whether the solution runs continuously, whether it reasons about application context, what additional context it can ingest, and whether it proves exploitability. - Closing call to action: "sneak.io. Meet Evo, our new AI security offering." --- ## 4. Claims Versus Demonstrated Material ### Creator Claims (Unverified Within the Transcript) The talk relies on numerical statistics. The transcript does not cite sources for any of them: | Claim (as stated) | Attribution in transcript | |---|---| | "218% more lines of code per the developer" | "According to our data" | | "62% of the output generated by LLMs is not secure or it's broken" | No source given | | "43% of all the MCP servers actually has vulnerabilities" | No source given | | Average AI attack time "24 34 minutes," fastest "4 minutes" | No source given | | An AI model identified "more than 600 vulnerabilities" to breach "600 firewalls in more than 555 countries" | Described as "an operating model"; no source given | Other unsupported assertions include: > "For us as a industry, we have a severe problem of false positive." > "Some of them can do it in like as fast as four minutes." ### Demonstrated Presentation Patterns (Observable in This Talk) - **Structure:** Problem framing, then conceptual taxonomy (SAST, DAST, pentesting), then a product pitch, then an architecture walkthrough, then evaluation criteria, then a closing product call to action. - **Explanatory style:** Uses analogies and plain-language definitions for mixed audiences. For example, BOLA is explained as "user A can access the data of user B." - **Comparative framing:** Repeatedly positions traditional approaches against the proposed approach. Pentesting is called "the golden standard" but also "simply not good enough" at its cadence. - **Promotional orientation:** The talk is openly vendor-affiliated, and the product is introduced within an educational frame. The speaker invites buyers to "verify that with any vendor out there in the expo." - **Rhetorical devices:** Frequent use of "Okay," rhetorical questions, and summary restatements ("So combining all of this data together..."). - **Self-aware humor:** The rockstar remark, and an aside about the audience taking pictures. --- ## 5. Evidence Quotes Supporting Key Observations **Vendor-neutral framing claim:** > "what I'm going to tell you today is general. Okay. you can take the principles of what I'm telling you and you can actually verify that with any vendor out there in the expo." **Multi-tool positioning:** > "one solution is not enough." **Continuous-cadence positioning:** > "We're going to do it on every code change. Okay? Every PR that you send, every delta..." **Explicit evaluation framework (four questions):** > "do we run this solution in a continuous way or is it just a point solution..." > "do they really reason about the application context?" > "what more context can they digest?" > "do they really help me prove that there is a bug..." --- ## 6. Limits of These Observations - This is a single talk. Nothing here establishes the channel's recurring format, typical audience, or editorial policy. - No timestamps are available in the source, so evidence is cited by quoted passage only. - The speaker's private motives are not inferred. The promotional nature of the content is observable from the closing call to action and the product framing, not from any stated intent. # Delivery Observations: "AI Hackers Are Faster Than Your Pen Test" (Eli Cohen, Snyk) ## Evidence Basis - **Source:** Title and transcript only. No curated metadata was supplied. - **Caveat:** The transcript contains apparent transcription errors (e.g., "Ellie," "sneak," "pan testing," "Gund standard"). Quotations below reproduce the transcript as written, so some words may not match the speaker's actual phrasing. - **Limit:** One talk offers limited basis for claims about repeated habits. Patterns are marked accordingly. ## Tone and Register - **Conversational and direct.** The speaker addresses the room as "everyone" and asks questions aloud, as in: > "Please raise your hand. Who is here more from the development side of the table? Developers." - **Urgent framing.** Problems are described with escalating language: > "that's a huge challenge for us as a community" > "this is simply unbelievable" - **Light self-deprecation.** The speaker jokes about their own career path: > "my my my dream was to be a rockstar, but I had to be a cyber entrepreneur." - **Mixed formality.** Dense technical content sits alongside casual asides like "it sounds like a movie from the 90s, right?" ## Recurring Vocabulary and Phrases ### Discourse markers - **"Okay."** Used very frequently as a sentence closer and transition. This is the most conspicuous tic in the transcript. - **"right?"** Used as a tag question to invite agreement: > "we are producing much more code than ever"… "It doesn't make sense to do this anymore." (see also "Okay, it sounds like a movie from the 90s, right?") - **"Great."** Used as an acknowledgment or reset, e.g., "Great. Okay, now we have the timer also." ### Intensifiers and hedges - **"simply"** appears repeatedly: > "this is simply unbelievable" > "simply not good enough" > "the numbers are simply incredible" - **"obviously"** introduces points the speaker treats as self-evident: > "obviously this is an AI engineering conference" > "obviously we are leveraging AI but our attackers are also leveraging frontier models" - **"probably"** and **"I guess"** appear in hedged claims: > "each one of you probably have five different session of cloud code running simultaneously" ### Signposting phrases - **"I want you to…"** recurs as a directive frame: > "I want you to think about the following things." > "if there is one thing I want you to take from here is to realize that the world is changing." - **"what I really want you to take from here"** and **"what I want you to understand"** serve the same function. ### Ordinal and sequencing language - "First of all… Second… third… And the fourth part is…" structures the four evaluation questions. - "So what changes today?" and "Now how do we do it?" mark section turns. ### Domain terminology - Heavy use of security and AI jargon, often unexpanded: *SAST* ("static code scanning"), *DAST* ("dynamic application security testing"), *BOLA*, *MCP servers*, *prompt injection*, *exfiltration*, *red teaming*, *orchestrator*, *exploit validation*. - Terms are often defined in plain language immediately after use, as with BOLA: > "broken object level authorization which basically it means that user A can access the data of user B." ## Teaching and Explanation Habits - **Builds from basics before advancing.** The speaker explicitly frames this: > "So I want to cover first a few basic concepts okay to make sure everyone is familiar with." - **Compares tools by category and use case.** Static scanning, DAST, and pentesting are presented as distinct tools with different strengths. The speaker summarizes: > "There are certain classes of vulnerabilities. This dust is the best scanner for that." - **Uses analogies to explain architecture.** Agents are given human-role metaphors: > "imagine it as the brain" (orchestrator) > "you can imagine it as your elite intelligence unit" (recon agent) - **Explains the reasoning behind design choices.** Rather than only describing features, the speaker often gives a "because": > "Exactly because we want to reduce the cognitive load. Exactly because we want to reduce the amount of false positive we have in the system." - **Repeats key claims across sections.** The idea that context drives LLM quality recurs: "your LLM are as good as the context that you feed them with" and "the richer the data is, the better and by the way cheaper the LLM operation is going to be." - **Ends with a decision framework.** The closing segment gives four evaluation questions for vendors, making the takeaway actionable. ## Audience Engagement - **Explicit audience sorting.** The speaker asks attendees to self-identify by role (developers, security, others) and states the adaptation: > "So I'm going to tailor this uh session towards everyone." - **Physical participation.** The closing invites a photo: "So hands up everyone." - **Stated invitation to questions.** "And I'm here for questions." ## Rhetorical and Structural Moves - **Problem → shift → solution arc.** The talk moves from insecure AI-generated code, through the limits of traditional testing, to a proposed continuous model: > "So what changes today? Today we have a new technology…" - **Contrast framing.** Past and present are repeatedly juxtaposed: > "we used to test our application once every few months… But that world is does not longer exist." - **Vivid pacing devices.** Concrete timing is used for emphasis: > "Some of them can do it in like as fast as four minutes. Okay, that's almost five time of the lecture of the session that I just did." - **Vendor-aware close.** The talk shifts into product promotion near the end, framed as general principles: > "you can take the principles of what I'm telling you and you can actually verify that with any vendor out there in the expo." ## Isolated Moments (Not Patterns) - The timer request ("Um, back there, can you set up the timer for me, please?") is a one-off logistics moment. - The rockstar joke and the photo request appear once each. - The closing product call-to-action ("Meet Evo, our new AI security offering") occurs only at the end. ## Stable-Looking Patterns vs. Limited Evidence | Pattern | Confidence | Basis | |---|---|---| | Frequent "Okay." as discourse marker | High | Recurs throughout | | Frequent "simply" and "obviously" | Moderate–High | Multiple instances in different sections | | "I want you to…" directive framing | Moderate | Several instances, concentrated near key points | | Analogies for system components | Moderate | Used for at least two agents | | Definition-after-term habit | Moderate | Observed for SAST/DAST/BOLA | | Audience self-identification | Single instance | One opening segment only | ## Uncertainty - These observations come from a single transcript. Claims about habitual delivery would be stronger with additional talks by the same speaker. - Transcription errors may distort word-level observations, especially around proper nouns and technical terms. - Pacing, vocal emphasis, and gesture cannot be assessed from text. # Observation Record: "AI Hackers Are Faster Than Your Pen Test — Eli Cohen, Snyk" ## Speaker Identification The transcript identifies the speaker as **"Ellie" / Eli Cohen** (per video title), described in-curriculum as: - Former **co-founder and CEO of Helios**, a runtime security company acquired by Snyk - ~2.5 years at Snyk in **product management for AI products**, more recently **founding Field CTO** No other speakers are identified in the transcript. --- ## Part 1: The Threat Landscape Claims ### Code volume and insecurity (attributed to Snyk data) - "**218% more lines of code** per developer" than before, per "our data" (i.e., Snyk's data). - "**More than 85%** of developers are now using coding agents." - "**62% of the output generated by LLMs is not secure or it's broken.**" ### Compounding effect claimed - More insecure code is reaching production; security backlogs are growing "at a pace that we simply couldn't remediate or mitigate." ### AI-enabled attackers - Attackers chain **low-severity vulnerabilities into critical ones**, attacking "especially where it's very difficult using application context." - An unnamed "operating model" reportedly "identified more than **600 vulnerabilities**... to breach 600 firewalls in more than 555 countries." *(Note: "555 countries" is as stated in the transcript; the figure is internally implausible but preserved as expressed.)* - **Average time for a successful AI attack: 24–34 minutes; fastest: 4 minutes.** - "**43% of all MCP servers** actually has vulnerabilities." --- ## Part 2: Limitations of Traditional Security Tools | Tool | Strength | Stated Weakness | |---|---|---| | **SAST** (static scanning) | Cheap, easy on every code change (SQLi, XSS) | Cannot catch runtime issues (authorization, configuration) | | **DAST** (dynamic testing) | Finds runtime issues e.g. **BOLA** (user A accessing user B's data) via payload sets | Weak on **business logic** vulnerabilities | | **Penetration testing** | "Golden standard" — human understands business logic and concepts | Expensive; slow; performed only 1–3x/year; results delivered as a "glorified report in PDF," slow remediation/retest cycle | - Cohen's framing: with continuous AI attackers, pen-testing "two times a year is simply not good enough" — "What you going to do with the rest of the 350 days?" --- ## Part 3: Proposed Solution — "Evo" Continuous Offensive Security ### Positioning - AI pentesting run **on every code change / every PR**, not periodically. - Explicitly framed as generalizable: "what I'm going to tell you today is general... you can actually verify that with any vendor." - Includes **agent red teaming**: multi-step attack simulation (prompt injection, data exfiltration, goal hijacking) combined with dynamic testing. ### Multi-agent architecture (as described) 1. **LLM orchestrator** — "the brain," follows a dynamic plan, directs sub-agents 2. **Recon** — "elite intelligence unit"; collects endpoints, APIs, fingerprints, formalizes an architecture 3. **Vulnerability testing** — specialized agents for known vulnerability classes plus "in the wild" business-logic hunting 4. **Exploit validation ("the judge")** — determines whether findings are real and exploitable, to reduce false positives 5. **Remediation agent** — makes findings actionable for developers 6. **Reporting agent** ### Differentiators claimed - Built **"from the ground up using LLM,"** not static/DAST scanners wrapped with an LLM. - **Context enrichment**: fed with outputs from prior SAST/DAST/agent scanners to guide where LLMs look ("context is everything"). - **Exploit proofing**: vulnerabilities are proven exploitable rather than merely flagged, to reduce false positives and cognitive load. ### Qualification offered - "**One solution is not enough.**" DAST remains best for some classes (e.g., cross-site scripting, via exhaustive payload sets); pentesting is best for business logic — tools should be combined. --- ## Part 4: Buyer's Evaluation Criteria (four questions proposed) 1. Does the solution run **continuously** or as a point solution? 2. Does it **reason about application context**? 3. What **additional context** can it digest (richer data = better and cheaper LLM operation)? 4. Does it **prove exploitability** or merely flag bugs? --- ## Part 5: Marketing / Promotional Content - Closing promotion for **Snyk Evo** ("sneak.io" in transcript; "Meet Evo, our new AI security offering"), with an invitation to visit the booth. - Personal anecdote: aspiration to be a rockstar, replaced by taking photos with the audience. --- ## Tensions and Qualifications Preserved - Cohen acknowledges the advertised solution is tied to Snyk's commercial offering while simultaneously asserting the principles are vendor-neutral. - The "555 countries" statistic is presented without sourcing and is anomalous; recorded verbatim. - The claim that attackers exploit "application context" because LLMs "struggled the most" there is presented as both a defensive gap and the rationale for the product's context-driven approach — the same factor appears on both threat and solution sides of the argument, as expressed. - Pen-testing is simultaneously called "not good enough" in its traditional form and "the best method out there" for business logic testing — the qualification as stated. # Video Attribution Record: AI Hackers Are Faster Than Your Pen Test **Video ID:** `01a15ca6-e40e-7b71-9c98-41126018f382` **Evidence basis:** Title and transcript only. No curated metadata, comment data, or timestamps were supplied. --- ## 1. Speakers and Roles ### Primary Speaker - **Name (per title):** Eli Cohen - **Name as spoken:** "Ellie" (self-introduction in transcript) - **Stated roles:** - Former co-founder and CEO of **Helios**, a runtime security company, which the speaker says was acquired by Snyk - Approximately two and a half years at Snyk, primarily on **product management for AI products** - More recently, **Field CTO** at Snyk, working with developers and security teams on AI security strategy - **Speaking role:** Presenter at an AI engineering conference session > **Transcription note:** The transcript renders the company name as "sneak" and "SNIK" in several places. The title names Snyk. This record uses "Snyk" and treats the transcript spelling as an auto-caption artifact. ### Other Voices - **Audience:** Unnamed attendees who answered a show-of-hands poll on their role (developers, security, sales/marketing, other agent operators). No individual is identified. - **Unidentified staff member:** The speaker asks someone in the room ("back there") to set up a timer. This person is not identified and does not speak on the record. --- ## 2. Referenced Sources and Named Entities ### Organizations and Products - **Snyk:** The speaker's employer, and the company whose product is discussed - **Helios:** The speaker's former company, mentioned as background - **EVO (Evo):** Introduced as "continuous offensive security" and "our new AI security offering" - **Coding tools:** Cloud Code and Codex, referenced as tools audience members run in parallel - **MCP servers:** Referenced as a category with vulnerability statistics ### Models - **"Mythos"** and **"frame"** (transcribed as "frame"): Named as frontier models. Transcript clarity is limited, so the exact names are uncertain. ### Techniques and Categories - Static application security testing (static code scanning) - Dynamic application security testing (DAST) - Penetration testing (human-led and AI-led) - Agent red teaming - Named vulnerability classes: SQL injection, cross-site scripting (XSS), broken object-level authorization (BOLA) --- ## 3. Third-Party and Unattributed Claims The following statistics and claims appear in the transcript. Attribution varies, and each item is recorded with its stated source or lack of one. ### Attributed to the Speaker's Organization - **"According to our data"**: Lines of code per developer increased by **218%**. The data source is the speaker's organization, with no further detail given. - **"Based on the data that we see both from the labs and from real data from customers"**: Referenced as the basis for a claim about combining tools. The labs and customer datasets are not named. ### Unattributed or Vaguely Attributed - More than **85%** of developers use coding agents. No source is given. - **62%** of LLM-generated output is "not secure or it's broken." No source is given. - An unnamed "operating model" identified more than **600 vulnerabilities** used to breach **600 firewalls** across **555 countries**. The transcript is garbled here, and the source is not identified. - Average time for a successful AI attack: **24 to 34 minutes**. Fastest: **4 minutes**. No source is given. - **43%** of MCP servers have vulnerabilities. No source is given. ### Hypothetical or Illustrative Statements - The speaker describes a scenario in which a "user A can access the data of user B" as an example of BOLA. This is an illustrative example, not a specific reported incident. - The speaker says "since the moment I began talking, there is probably an AI attack out there" that breached a system. This is presented as a rhetorical inference, not a documented event. --- ## 4. Promotional Segments > **Flag: The session is promotional in its entirety or near-entirety.** The speaker is a Snyk employee presenting a Snyk product. ### Explicit Promotional Segments - **Product introduction:** "This is why we're introducing EVO continuous offensive security." - **Comparative positioning:** Passages beginning "what makes us different" and "what we're doing differently within AI pentesting" describe the speaker's product as distinct from alternatives. - **Integration claims:** Statements that Snyk's AI pentesting feeds data from other Snyk scanners, and that "one solution is not enough" as a case for Snyk's combined offering. - **Closing call to action:** "sneak.io. Meet Evo, our new AI security offering." ### Mixed-Purpose Passages - The speaker says the principles "are general" and that attendees can "verify that with any vendor out there in the expo." This is framed as general guidance but still leads back to the speaker's product. - The "four questions" section sets evaluation criteria for vendors. The criteria are tied to the speaker's product's stated strengths. --- ## 5. Availability Limits - **Comments:** Not supplied. Audience reaction and public commentary cannot be assessed. - **Curated metadata:** Only the title is present. No speaker bio, event details, description, or chapter markers were provided. - **Timestamps:** Not supplied. References to content in this record are by order of appearance in the transcript. - **Transcript quality:** Auto-caption artifacts are present, including mis-transcribed names ("Ellie," "sneak," "SNIK"), product names ("frame"), and technical terms ("ejection" for injection, "excfiltration" for exfiltration, "aenting" for "ating"). Some passages are unclear, notably the 600 firewalls claim. - **Visual content:** Slides, demos, or on-screen material, if any, are not available. - **Source documents:** None of the statistics or named sources were supplied for verification. Great. Hi everyone. We're going to talk today about continuous offensive security. Okay. I'm going to speak quite soon. What does it mean? Uh but before that, a little bit about me. I'm very excited being here today. I'm Ellie. Uh used to be co-founder and CEO of Helios, a runtime security company. got acquired by sneak and in the last two and a half years I had the privilege in working in sneak primarily on product management for AI products but more recently founding field CTO meaning I'm working with developers and with security folks to better understand and to help them shape their strategy around AI security. So how do you take your AI agents and making sure they are um secured? How do you work with your agents in production? Um, back there, can you set up the timer for me, please? The timer. So, I'll know the time. Great. Okay, now we have the timer also. Great. Um, so just so I'll get to know a bit better. Please raise your hand. Who is here more from the development side of the table? Developers. Okay, great. From the security side of the table. Yeah, I already know you. Great. and other people like sales, marketing, other people running agents in production that are not from developmental security. Great. Okay. So, we have everyone here. So, I'm going to tailor this uh session towards everyone. So, obviously this is an AI engineering conference, right? So, we already know that the amount of code generated today is incredibly bigger than it used to be before. Okay. According to our data, it's 218% more lines of code per the developer than it used to be before. Okay. And more than 85% of the developers are actually using coding agent now probably running here today. It's more than 100% right because I guess that each one of you probably have five different session of cloud code running simultaneously. Otherwise, you wouldn't be here today. And the funny thing about those agents running in production and generating fork for us is that it's far less secured than we are used to. Okay, so 62% of the output generated by LLMs is not secure or it's broken. Okay, so just imagine this data combined together. It's meaning that we are generating more code than we ever did and this insecure code is getting into production. So that's a huge challenge for us as a community and what it actually means is that our backlog of security issues is becoming longer and bigger and much more challenging to remediate it. Okay. So we are actually creating many more issues at a pace that we simply couldn't remediate or mitigate. And not only that, AI is helping our attackers also. So they are able to chain low vulnerabilities together and to form critical vulnerabilities from those um low low severity vulnerabilities. And what's actually is going on is that our attackers are leveraging those LLMs and they're attacking us especially where it's very difficult using um application context. This is actually where our LLMs are struggled the most because they are creating many more vulnerabilities around those areas. So obviously we are leveraging AI but our attackers are also leveraging frontier models. Okay. And the numbers are simply incredible. Okay. We are familiar with an operating model that actually was able to identify more than 600 vulnerabilities uh to breach 600 firewalls in more than 555 countries. Okay, this is simply unbelievable. And the time for an AI attack to be effective is constantly getting faster and faster. Okay, so the average time for an AI attack to be successful is 24 34 minutes. Okay, well the fastest time is 4 minutes. Okay, it means that since the moment I began talking, there is probably an AI attack out there that was able to successfully breach a production system and 43% of all the MCP servers actually has vulnerabilities. Okay, so combining all of this data together, what we realize is that we are producing much more code than ever. Each one of us has a few sessions simultaneously of cloud code of codex. Those this code is insecure. It's getting into production and the people we are facing the attackers are actually leveraging the same tools and they are acting faster than ever in trying to actually leverage those vulnerabilities and our backlog is simply getting piled up and we are not able to get it. And this is exactly what I want to talk about today. what we should be doing to to help improve our security posture. And this is ties heavily to how we can leverage offensive security not just for the attackers but for us as defenders. So why traditional security can't really keep up? So there is a mixed audience today both people from the development side also people from the security side. So I want to cover first a few basic concepts okay to make sure everyone is familiar with. So what used to be really easy about operating was static code scanning okay SAS. So imagine that you are pushing new code to production. There is a static scanner that is scanning that and is looking for SQL injection cross-ite scripting. So it used to be relatively cheap and relatively easy to run this across every code change. And this is great. Now what it doesn't catch, it doesn't catch things that are going into runtime. Okay, so if you have any authorization issues, if you have any configuration issues, for that you will need dynamic application security testing. Okay, you'll need something that test application dynamically. One example is bola uh broken object level authorization which basically it means that user A can access the data of user B. Okay, those kind of vulnerabilities you can never find with static analysis. For that you need to prop the application in runtime. So what actually a dust scanner is doing it just takes a predefined set of tons of payloads and it just sending to the application to the different API endpoints and by that it managed to find vulnerabilities. So this was also something that could find new things but it wasn't good with the biggest challenge we have with the code that LM are producing and this is the business logic. So for that we've been you what we've been using as an industry it's the pentesting. Okay. So what's the idea about pentesting? It's a human pentester that really understands the concept and the business logic of the application and is trying to break it and to find all the vulnerabilities. Now it is the golden standard in application security testing but it has some challenges right. First of all, it's cost a lot of money, right? Because you actually needed to have a security researcher, a human, not a human in the loop, a human that is actually doing the testing and trying to break the application. And that's cost a lot of money. Now, the second problem is because it cost a lot of money and because the process was so slow, companies can only do it once a year, two times a year, maybe three times a year. Okay? So combining the fact that nowadays our AI attackers are trying to continuously attack us like doing this pan testing two times a year is simply not good enough. Okay. So what you going to do with the rest of the 350 days you have a year that no one tested your application. Not now not only that the results you got the result you got this crazy and glorified report in PDF that you had to send to your developers. there to take it back to understand what's real and what's not and then to start fixing that and then you had to retest. Okay, it sounds like a movie from the 90s, right? It doesn't make sense to do this anymore. But this was the Gund standard. This is what we were doing. Now the thing is this is the best method out there to actually test your application for its business logic. Okay. So what changes today? Today we have a new technology and this is exactly what I want to talk how we can leverage this new area of AI tools and LLM and frontier models to actually do pentesting on a continuous manner in a scalable manner and this is why we're introducing EVO continuous offensive security. Okay, so this is obviously very tied up to what we're doing within SNIK, but what I'm going to tell you today is general. Okay, you can take the principles of what I'm telling you and you can actually verify that with any vendor out there in the expo. Okay, so I want to I want you to think about the following things. Okay, so what you need to do today, you need to prepare your production system from the unknowns unknowns. Okay, and for that you need a new paradigm. Okay. So first of all obviously you need the AI pentesting capabilities which I will double click on soon again. But you also need to start taking the concept of red teaming. Okay. So agent red teaming the idea is to take multi-steps attacks. Okay. So to try to simulate prompt ejection or data excfiltration and goal aenting and obviously to combine it with dynamic testing that is good at identifying authorization issues. So we are taking all of those capabilities together. We are building one suite out of that for offensive security as part of our EVO offering. And the idea is to help you actually mitigate or help you uh handle the fact that the attackers are leveraging the same tools that we are using and they are doing that in a continuous manner 24/7 finding vulnerabilities faster than before and your backlog simply cannot can stand up with that. So what we're doing differently within AI pentesting. Okay. So we I told you before the great promise of pentesting was always the fact that the human and the end really understand the business context. Okay. So now we are taking this to the LLM and if there is something that LLM are very good at is really trying to understand the business context. So behind the scene we are leveraging the LLMs and we are doing that in a continuous manner. Right? So no longer you're going to do things like do pent testing twice a year or three times a year. We're going to do it on every code change. Okay? Every PR that you send, every delta, we're going to run this pentest for you and we're going to tell your developers what do they need to fix and how do they need to do it differently. Obviously we leverage our understanding of the application context, but we also help reduce the false positive. For us as a industry, we have a severe problem of false positive. So we are actually proving you that the vulnerabilities that is that we are finding are actually exploitable and we just just flag them as bugs. We actually help you prove that they are exploitable and we take contexts for many different machines and for many different environments and we combine them together to help guide our LLMs. Okay, so this is what we're doing differently and I think this is really what's makes this solution so unique and so well positioned to the fact that each one of us have a few coding gadgets running in production and pushing more code than ever. Now how do we do it? How does it work behind the scenes? Okay, so what I want you to understand is we are not taking the static scanners or the dust scanners and just combine him with LLM. Okay, we build it from the ground up using LLM. So we have a series of a few agents working together. The first one is the LLM orchestrator. Okay, imagine it as the brain. This agent is working according to a dynamic plan that it follows and it knows how to operate all the different sub agents. The first agent or actually the second agent is the recon. Okay, you can imagine it as your elite intelligence unit. The idea is to collect all the data it can about the different network endpoints, the different APIs, the different fingerprints, collect all of this data together, formalize an architecture out of that and hand it to the next agent. And the next agent is the vulnerability testing. It's actually again a series of a few specialized agents. Some of them are targeting the well-known classes of vulnerabilities. Some of them are actually hunting for vulnerabilities in the wild and they are trying to break your application to understand the business context and to understand where can attacker can get from and then they hand it into the judge as I like to call it the exploit validation. So actually every vulnerability that the previous agent find are now being handed over to this judge and the goal of the judge is to tell us whether this is a real vulnerability or or not to tell us whether this can be exploitable or not. Exactly because we want to reduce the cognitive load. Exactly because we want to reduce the amount of false positive we have in the system. Coming up next is the remediation agent because everything we do we want to make actionable. Okay, we don't want to report about a vulnerability that eventually the developers they don't know what they can do with that. And coming after that is the reporting agent because everything needs to be reported. So what makes us different and those are the point I urge you to check with every vendor out there trying to provide you with the solution or whether you want to implement a solution inhouse for AI pentesting. This is a huge industry right now. So I think the most important thing you need to remember is and you already know that especially the developers in the room context is everything. your LLM are as good as the context that you feed them with. So what we're trying to do, we are not just taking our AI pen testing solution as a standalone. We actually feed it with data from all the previous scanners. Okay, so the the statics code scanner, the dynamic code scanner, all of the different agent engines are being combined together and they are being fed into a our AI pentesting solution because that way we know how to tailor and we know how to guide the LLM where to look for and as you know also for mythos or for frame when those models know where to look the results are significantly better. So that's one thing we're doing that is you know very unique and very differentiated. Um and also what I want you to remember is that one solution is not enough. Okay. The great thing about it is when you combine those things together and based on the data that we see both from the labs and from real data from customers combining the data together is really what's important and you can't really you can't really use just one of them. Okay. There are certain classes of vulnerabilities. This dust is the best scanner for that. Okay? Because you have a set of really exhaustive pre um a set of really exhaustive uh payloads that you can send to your application. So it's very good for example with quite scripting. Okay. So dust for crossite scripting is the best solution. But if you want again like business logic then you should combine it with uh pentesting because it will be the best solution. So I think what I really want you to take from this, if there is one thing I want you to take from here is to realize that the world is changing. You already know that. That's what made you come in. But you know we used to test our application once every few months because the change and the velocity of the change was so slow and we're we had people at the end that were reasoning about the application and about the change. But that world is does not longer exist. Right? Right now we are pushing code to production 24/7 and we have LLMs that are trying to reason about the application context and they are trying to break it continuously. Some of them can do it in like as fast as four minutes. Okay, that's almost five time of the lecture of the session that I just did. So when you're coming to look for new solutions for this problem, you have to ask yourself four questions. Okay. First of all, do we run this solution in a continuous way or is it just a point solution that we run every once in a while? Okay, that's a major difference. Second, do they really reason about the application context? Okay, because given the nature of those LLM, application context is really where the new vulnerabilities are coming from. And third, what more context can they digest? Okay, how can they enrich the data? Because the richer the data is, the better and by the way cheaper the LLM operation is going to be. And the fourth part is do they really help me prove that there is a bug and to make sure that this is exploitable or they they just flag it as a bug. Okay, so our goal is not only to help you find the bugs faster, but to actually do it better and cheaper and to help you as a developer or as the security people here focus on what matters most. Um, so thank you very much and uh I used to do it in every lecture. You know, my my my dream was to be a rockstar, but I had to be a cyber entrepreneur. So instead of that, I'm going to take pictures. So hands up everyone. Okay, great. Thank you so much. And I'm here for questions. If you want, go for the boot. It's very close here. sneak.io. Meet Evo, our new AI security offering. Thank you so much.