2.0 -//Pentabarf//Schedule//EN PUBLISH QNA3YD@@pretalx.com -QNA3YD The Malware is coming from inside the repo. en en 20261003T100000 20261003T102500 002500

The Malware is coming from inside the repo.

GitHub isn't just where developers work. It's where adversaries stage, obfuscate, and deliver malicious code. Every minute, thousands of commits hit public repositories, and buried inside that firehose are credential stealers, reverse shells, crypto drainers, and the occasional nation-state lure dressed up as a coding challenge. The platform's openness, trust, and sheer volume are exactly what make it useful to attackers: free hosting, free CDN, a developer-friendly domain in every allowlist, and a culture where running npm install or cloning a stranger's repo is just Tuesday. This talk is about what happens when you actually try to watch all of it. We'll walk through github-threat-scanner, a pipeline that consumes the GitHub public event stream in near real time, pulls down the code behind every push, and runs it through a stack of decoders and detection rules looking for anything that smells wrong. The interesting problems aren't where you'd expect. Ingesting the stream is easy. Storing it is a solved problem. The hard parts are everything in between: peeling back the layers of obfuscation attackers use to hide payloads, deciding what "malicious" even means when half the internet's legitimate code looks suspicious, and keeping false positives low enough that a human analyst can still trust the queue. We'll dig into the deobfuscation engine (CyberSaucier), a library of CyberChef recipes that chain together XOR bruteforcing, base64 and hex decoding, packed-JavaScript unwrapping, PowerShell de-munging, and the other tricks that turn a wall of gibberish back into something a detection rule can match on. You'll see which recipes earn their keep, which ones we retired because they were pure theatre, and the surprisingly mundane reasons some decoders fail in production that never show up in a blog post. Then we'll get to the fun part: who's actually out there. Commodity and Nation State actors treat GitHub Pages as disposable infrastructure. And threading through all of it are the targeted operations: DPRK-aligned clusters running fake job interviews and "technical assessments" that ship trojanized projects to developers at crypto firms and long-running personas that maintain plausible commit histories for months before turning hostile. You'll leave with a concrete picture of how to build this kind of visibility yourself, what the detection surface actually looks like once you're watching it, and why GitHub deserves a seat in your threat model next to email and the browser. If you run a security team, you'll walk out with questions to take back to your developers. If you write detections, you'll have new ideas for where to point them. And if you just like watching adversaries do dumb things at scale, there will be plenty of that too. The best part of all of this? Most of this data was initially triaged and analyzed by an autonomous AI analyst running in a throwaway VM in dangerous mode, unafraid of touching actual adversary infrastructure. No prior knowledge of GitHub internals required. Bring opinions about regex. PUBLIC CONFIRMED 25 Minute Talk https://pretalx.com/bsides-toronto-2026/talk/QNA3YD/ 1-067 Justin Borland PUBLISH VVTXTZ@@pretalx.com -VVTXTZ From Schema to Shell: The Agentic Exploitation of GraphQL APIs en en 20261003T103000 20261003T105500 002500

From Schema to Shell: The Agentic Exploitation of GraphQL APIs

GraphQL breaks assumptions that traditional API scanners rely on. There's no fixed URL structure, a single endpoint accepts arbitrarily complex queries, introspection hands attackers the full schema, and batching lets them amplify requests in ways REST never allowed. Existing tools treat GraphQL as HTTP with JSON — GrapeQL treats it as its own attack surface. The platform covers six testing phases in sequence: engine fingerprinting via behavioral probes, information disclosure (introspection leaks, field suggestions, GraphiQL exposure, alternate transports), injection across every String and ID argument in the schema, authentication and authorization (header bypass, unauthenticated access, IDOR enumeration), denial of service (deep nesting, fragment bombs), and out-of-band testing for blind vulnerabilities. Test logic lives entirely in YAML — new checks drop into the appropriate directory and load automatically, no engine changes required. PUBLIC CONFIRMED 25 Minute Talk https://pretalx.com/bsides-toronto-2026/talk/VVTXTZ/ 1-067 Aleksa Zatezalo PUBLISH BV3ARE@@pretalx.com -BV3ARE Strictly Business: Why Security Is Always a Risk Management Function en en 20261003T110000 20261003T112500 002500

Strictly Business: Why Security Is Always a Risk Management Function

**The premise.** When you ask "is your security program working?" the usual answers don't answer the question. "We passed our audit." "We haven't had a breach." "Our maturity scores went up." None of these tell you whether the program is reducing the probability of a material cyber event, because none of them incorporate what the attackers are actually doing. They measure activity, posture, or compliance state. The attackers don't care. **What the talk argues.** Every security decision is, implicitly or explicitly, a risk management decision. The talk makes this concrete using Rick Howard's formulation, then picks it apart: probability (not possibility), business cycle (not all time), materiality (the threshold the business sets, not us), and risk appetite (the business decides, we inform and execute). With those four pieces in place, "are we secure?" stops being a not-even-wrong question and becomes a set of answerable ones. **What we cover.** - **The Problem Space:** why the usual answers to "is your program working?" don't survive contact with an attacker who is also acting. - **Rick Howard's formulation, unpacked:** probability, business cycle, materiality, risk appetite. - **How we're training practitioners:** a quick tour of higher education, the major Bodies of Knowledge (CISSP CBK, CISM, CRISC, et al.), and where risk management actually sits in the curriculum. - **Frameworks in practice:** NIST CSF, ISO 27001, PCI DSS, C2M2, ATT&CK. Most explicitly call for a risk-based approach. Most get implemented as control checklists. Why the drift happens and what to do about it. - **Reconceptualizing the practice:** what changes when risk is the foundation rather than an afterthought wedged into one GRC chapter. **Who this is for.** Practitioners, team leads, and managers who feel the dissonance between what they audit against and what they actually defend. People reporting to executives or boards who want to give better answers than maturity scores. Educators and mentors thinking about how to frame the discipline for newcomers. No specialized technical background required. **What attendees will leave with.** - A precise definition of what cybersecurity is for, that survives stakeholder scrutiny. - A vocabulary for separating activity from outcome, and posture from risk reduction. - A diagnostic for when a framework is helping versus when it has become the work. - Better questions to bring back to the business about materiality, risk appetite, and residual risk. **Style.** Synthesis talk in the tradition of Rick Howard, Bruce Schneier, and Dan Geer; opinionated, sourced, accessible. Slides are illustrative; the argument carries the talk. PUBLIC CONFIRMED 25 Minute Talk https://pretalx.com/bsides-toronto-2026/talk/BV3ARE/ 1-067 Jason Murray PUBLISH YKT83Y@@pretalx.com -YKT83Y Breaking Modern Electron Apps: Exploitation Patterns & Defensive Lessons en en 20261003T113000 20261003T115500 002500

Breaking Modern Electron Apps: Exploitation Patterns & Defensive Lessons

The session will walk through multiple real-world inspired vulnerability classes, including insecure IPC communication, preload abuse, arbitrary file access, unsafe shell execution, renderer-to-main process trust boundary violations, and abuse of Electron-specific APIs. In addition to demonstrating exploitation paths, each issue will be mapped to practical defensive guidance and secure engineering recommendations that developers and security teams can apply in production environments. Where applicable, the talk will also reference publicly disclosed real-world Electron vulnerabilities and bug bounty findings to highlight how these patterns continue to affect widely used desktop applications today. Attendees will leave with a deeper understanding of Electron's security model, common anti-patterns that lead to compromise, and actionable techniques for building and assessing secure Electron applications. PUBLIC CONFIRMED 25 Minute Talk https://pretalx.com/bsides-toronto-2026/talk/YKT83Y/ 1-067 Najam Ul Saqib PUBLISH U8C8HJ@@pretalx.com -U8C8HJ One IDE to Rule Them All - Securing Your Supply Chain’s Weakest Link en en 20261003T130000 20261003T132500 002500

One IDE to Rule Them All - Securing Your Supply Chain’s Weakest Link

Your API keys, business logic, database connections, sometimes even customer data and user information - might be all directly accessible from your IDE. This makes the IDE in one of the top spots for threat actors to try and break into. Because the IDE has direct access to so much data, it makes your entire software supply chain to be as secure as a single extension, turning it to the weakest link in the chain. It takes only one evil extension, one vulnerability or one prompt, to compromise your entire organization. We will explore how each of these attack scenarios can turn a developer’s workspace into a gateway for threat actors to exfiltrate customer data before a single line of code is even written. We’ll dive deep into the IDEs architecture, starting from how IDE extensions are developed and their permissions stack, and how threat actors could manipulate extensions and IDE configurations to bypass security measures including the ability to exfiltrate valuable information from the developer’s IDE, then perform lateral movement directly after infection, and their ability to stay persistent even after being removed. It's not just about threat actors hacking your IDE - they will go after everything in the organization that’s connected to it, and they will try to stay there as long as possible. We’ll take a look at how threat actors could leverage vulnerabilities that lie in existing IDE extensions to execute remote code & exfiltrate information - transforming a developer's local machine into an under the radar backdoor of your organization. This includes our finding of multiple 0-day vulnerabilities in popular IDE extensions, and our research of weaponizing Chromium 1-day vulnerabilities on Cursor & Windsurf. We’ll wrap up by giving the best practice recommendations for securing your IDE, avoiding evil extensions, adding company-wide policies and for approved extensions, and showing security teams how to integrate IDE security into their organization at scale. PUBLIC CONFIRMED 25 Minute Talk https://pretalx.com/bsides-toronto-2026/talk/U8C8HJ/ 1-067 Moshe Siman Tov Bustan Nirza PUBLISH CARXCA@@pretalx.com -CARXCA Throwing gasoline on the fire: The causes and impact of stress and burnout in cybersecurity en en 20261003T133000 20261003T135500 002500

Throwing gasoline on the fire: The causes and impact of stress and burnout in cybersecurity

This presentation will argue that cybersecurity is inherently a high-stress discipline, shaped by a unique combination of chronic understaffing, continuous exposure to high-stakes crises, and a pervasive "always-on" culture. Left unchecked, this environment creates a perfect storm for severe burnout, directly jeopardizing both individual well-being and organizational defense. By examining the specific occupational hazards unique to info-sec roles, such as alert fatigue and the psychological weight of zero-day vulnerabilities, this session aims to elevate systemic risk awareness. Attendees will gain a critical understanding of how chronic stress manifests in security teams and individuals, as well as learning to identify the early warning signs of systemic burnout. Ultimately, this presentation serves as a vital call to action for industry professionals to acknowledge these systemic risks and proactively implement cultural and operational safeguards. PUBLIC CONFIRMED 25 Minute Talk https://pretalx.com/bsides-toronto-2026/talk/CARXCA/ 1-067 George Bragg PUBLISH AAPA89@@pretalx.com -AAPA89 From Shell Commands to ATT&CK: Building Genos, an Open-Source Command Intelligence Engine en en 20261003T140000 20261003T142500 002500

From Shell Commands to ATT&CK: Building Genos, an Open-Source Command Intelligence Engine

This talk will walk through the process of building Genos, an open-source security research project focused on real-time command-line classification and MITRE ATT&CK mapping. The motivation behind Genos is simple: many attacks eventually touch the command line. Whether it is PowerShell, Bash, curl, wget, certutil, rundll32, mshta, encoded payloads, reverse shells, persistence commands, credential dumping, or defense evasion, the command line often contains strong behavioral clues. However, building a system that can classify these commands reliably is much harder than just matching keywords. The talk will cover the technical design of Genos, including a two-stage classification pipeline. The first stage acts as a gatekeeper, deciding whether a command is benign, malicious, or context-dependent. The second stage focuses on mapping malicious behavior to likely MITRE ATT&CK techniques. The system also includes a preprocessing layer that attempts to decode common forms of obfuscation such as Base64, hex strings, encoded PowerShell, and nested payloads. We will discuss where machine learning helps, where it struggles, and why pure ML is not enough for security detection. The talk will also explain how rule-based security knowledge can be used alongside model predictions to improve practical results, especially for commands involving LOLBins, encoded payloads, suspicious download-and-execute patterns, persistence mechanisms, and privilege-related behavior. This is not a vendor pitch or a “AI solves security” talk. It is a practical breakdown of what worked, what failed, and what had to be redesigned while building a usable command intelligence system. Topics include dataset construction, labeling commands with ATT&CK techniques, dealing with ambiguous commands, measuring false positives, handling context-dependent behavior, and testing the system against both benign administrative commands and attacker-style commands. A live or recorded demo will show how Genos analyzes commands, returns a verdict, assigns confidence, maps behavior to ATT&CK techniques, and explains why a command was classified a certain way. PUBLIC CONFIRMED 25 Minute Talk https://pretalx.com/bsides-toronto-2026/talk/AAPA89/ 1-067 Ahmed Khan PUBLISH SJEYRR@@pretalx.com -SJEYRR Breaking the AI Assembly Line: How Attackers Exploit LLM Supply Chains en en 20261003T150000 20261003T152500 002500

Breaking the AI Assembly Line: How Attackers Exploit LLM Supply Chains

I'll discuss the full gamut of LLM supply chain attacks, drawing on current Public Cloud Labs research and my personal field experience. The session is organized into three sections: dataset-level attacks, model-level poisoning, and RAG system compromise. I plan to provide live demonstrations of how these attacks work in practice, rather than just slides and diagrams. Attendees will see legitimate code and attack methods, and I will explain why these weaknesses are so difficult to detect with standard security tools. PUBLIC CONFIRMED 25 Minute Talk https://pretalx.com/bsides-toronto-2026/talk/SJEYRR/ 1-067 Swar Shah PUBLISH SH7E88@@pretalx.com -SH7E88 Poisoning the Compliance Mind: How I Silently Collapsed an AI Anti-Money Laundering System with 50 Documents en en 20261003T153000 20261003T155500 002500

Poisoning the Compliance Mind: How I Silently Collapsed an AI Anti-Money Laundering System with 50 Documents

This talk presents original published research on a previously uncharacterised adversarial attack surface in production RAG-based AI agents. Published as SSRN preprint 6734225 and being submitted to ACM ICAIF 2026 (Milan, August 2026 deadline). The attack — Corpus-Level Memory Poisoning — differs fundamentally from existing adversarial ML categories. It does not target model weights, training data, or input prompts. It targets the live retrieval corpus that a deployed RAG-based agent queries at inference time. This attack surface is currently ungoverned by any existing framework including NIST AI RMF, OWASP LLM Top 10, and MITRE ATLAS. Talk structure — 25 minutes including Q&A: 3 min: Deployment reality — AI compliance agents in Canadian and global financial institutions 5 min: The attack — how Corpus-Level Memory Poisoning works, no ML background required 5 min: The finding — 98.4% degradation, zero log anomalies, undetectable by current monitoring 5 min: The defense — Memory Hygiene Layer, cryptographic provenance, 22.6ms detection 4 min: Implications for Canadian financial institutions and open research questions 3 min: Q&A Audience takeaways: A new attack vector on AI systems that current monitoring cannot detect A practical defense implementable without model retraining Specific questions to ask AI vendors about retrieval corpus integrity No machine learning background required. Accessible to all cybersecurity professionals. Immediately relevant to anyone in AI security, financial sector security, or compliance technology. Speaker note: I am an international student arriving at Mohawk College Hamilton in September 2026. This research was conducted and published from Kenya — the first formal adversarial ML threat model targeting RAG-based financial compliance agents. I am happy to connect with sponsors or attendees working in AI security or financial sector cybersecurity. PUBLIC CONFIRMED 25 Minute Talk https://pretalx.com/bsides-toronto-2026/talk/SH7E88/ 1-067 Frankline Ombachi Ondieki PUBLISH BE8BJD@@pretalx.com -BE8BJD Defending Linux Against Real Attackers en en 20261003T160000 20261003T162500 002500

Defending Linux Against Real Attackers

Rather than approaching Linux hardening as a checklist of security settings, this presentation explains why common defensive controls exist and how they work together to disrupt real-world attack techniques. The session follows the attacker's journey—from initial access and privilege escalation to persistence and detection—and demonstrates practical defensive measures that Linux administrators can implement using built-in operating system features and open source tools. Attendees will learn how to reduce the attack surface, limit privilege escalation, detect malicious activity, and automate security hardening while balancing security with operational usability. Throughout the presentation, real-world examples and demonstrations will reinforce how layered defenses make Linux systems significantly more resilient against compromise. Slide Layout Understanding the Threat - Why Linux systems are targeted - Common attacker objectives - Defense in depth Reducing Initial Access - Patch management - Secure SSH configuration - firewalld Minimizing exposed services - Slowing Privilege Escalation - Least privilege - sudo configuration - File permissions - SELinux - systemd sand-boxing Detecting the Attacker - auditd - AIDE - journald - Centralized logging - Indicators of compromise Recovery and Continuous Improvement - Backups - Incident response - Automation with Ansible - Continuous hardening Lessons Learned - Common hardening mistakes - Balancing security and usability - Building security into everyday Linux administration PUBLIC CONFIRMED 25 Minute Talk https://pretalx.com/bsides-toronto-2026/talk/BE8BJD/ 1-067 Anthony Navarro PUBLISH X9TSTQ@@pretalx.com -X9TSTQ I've Been Rolling Around Your House: Domestic Surveillance, $500 en en 20261004T100000 20261004T102500 002500

I've Been Rolling Around Your House: Domestic Surveillance, $500

Step one, buy a robot vacuum. Step two, take the shell off. Step three, find the UART pads and start listening. That's how it started. A few months later I had a chain of six bugs that lets any authenticated user on the vendor's cloud push a shell command to any of their robots on earth. The on-device handler runs whatever comes down. As root. No signature check. No allowlist. Just runs. The interesting piece isn't on the device though. It's the MQTT broker in the middle. The broker takes my "I am device X" claim at face value and delivers a shell payload to device Y. Which is your robot. In your living room. Walkthrough covers: * opening the thing, soldering to UART, dumping the boot log * finding the cloud credentials in the firmware * MITMing the MQTT traffic to map the topic tree * the moment I fired a shell command from my account at a robot owned by someone else and it just ran * the recon that turns "any random robot" into "your robot" * the actual PoC, and where the vendor's fix landed Six CVEs filed with MITRE. Vendor signed Safe Harbor. Full disclosure clears before the conference. Come if you own one of these. Come if you write firmware. Come if you like watching a $500 gadget give up everything it knows about the person who lives with it. PUBLIC CONFIRMED 25 Minute Talk https://pretalx.com/bsides-toronto-2026/talk/X9TSTQ/ 1-067 Amir H PUBLISH KEFBRD@@pretalx.com -KEFBRD Faster Than a Takedown: How Collective Internet Defense Disrupts Attacks at Scale en en 20261004T103000 20261004T105500 002500

Faster Than a Takedown: How Collective Internet Defense Disrupts Attacks at Scale

Takedown removes content permanently, but slowly, and it stalls behind bulletproof hosting, uncooperative registrars, and trademark processes that require legal intervention and run for months. Disruption is the faster layer: it stops internet traffic from reaching malicious infrastructure, often in minutes, and it can be the only protection a defender has while a takedown grinds on. This is not a talk about submitting a better takedown request. It is about the layer running underneath it: who operates it, how an IOC verdict moves through it, and how you can plug in. What the talk covers: 1. One attack, two mitigations. The picture most teams carry (one report, one host, one takedown, measured in days / weeks / months, reversed if the attacker re-hosts) versus the faster response through the internet's infrastructure. 2. The invisible infrastructure of collective defense, told through the operators' own published reach. Browser and OS blocklists (Google Safe Browsing, which warns billions of users and devices), public resolvers (Quad9, a nonprofit backed by the Global Cyber Alliance, blocking hundreds of millions of malicious lookups a day across more than 130 countries from more than twenty independent threat intelligence sources), mail reputation (Spamhaus, screening billions of mailboxes before a message lands), verdict aggregators (VirusTotal), and the endpoint engines that carry those verdicts. For on-prem and air-gapped networks, response policy zone feeds let any organization act on the same verdicts inside its own resolvers. 3. Disruption and takedown, side by side. Speed, permanence, coverage, and requirements for each, when takedown is not available, and the resurgence problem when a domain taken down resurges in 30 to 60 days. 4. How a verdict propagates. A trusted contributor reports a verdict, partners accept it, and the threat stops resolving across browsers, resolvers, inboxes, and endpoints at once. What governs speed and breadth, and the honest limit: coverage is the union of partner networks, not the whole internet. 5. What it is worth, and the new KPIs. Public documented cases: standing community disruption (URLhaus), the consensus blocklists that protected healthcare during the pandemic, and a published case in which a single predicted domain reported to a public resolver blocked more than 365 million malicious hits in 30 days. The KPIs that prove it: hits prevented, mail blocked, devices warned, and victims averted, rather than domains removed. 6. The disruptive defender's playbook. Point your resolvers at a public option such as Quad9, ingest open feeds like Spamhaus and response policy zones, and report your own indicators to community platforms built for public submission such as URLhaus. Said honestly: becoming a trusted partner to a major browser or resolver takes partner interest, extensive validation, and integration work, and in some cases is limited to dedicated cyber defense providers rather than commercial companies, so I do not sell it as a first step. 7. Demo. I close with an anonymized real case: real timestamps and verdicts with every identifying detail replaced by placeholders, each partner's status shown through that partner's own public-facing verdict, and a victims-averted figure shown next to Quad9's own published aggregate statistics for public context. 8. Q&A PUBLIC CONFIRMED 25 Minute Talk https://pretalx.com/bsides-toronto-2026/talk/KEFBRD/ 1-067 Andre Piazza PUBLISH VVNLB7@@pretalx.com -VVNLB7 What to Expect When You’re Expecting Pentesters en en 20261004T110000 20261004T112500 002500

What to Expect When You’re Expecting Pentesters

This talk is about how to get more value from penetration testing by understanding what happens before, during, and after the technical work. We will cover common reasons engagements go wrong: unclear scope, confusing terminology, missing access, unrealistic expectations, poor communication, and weak remediation ownership. The goal is to help attendees understand that a good pentest is not just about finding vulnerabilities; it also depends on preparation, communication, and follow-through. Slide Layout - What a pentest is and is not - Authorized, time-boxed testing - Not a magic wand or guarantee - Why scope matters - Why pentests fail before they start - Vague requests - Unclear asset inventories - Confusion between apps, APIs, scans, and red teams - Missing credentials or test data - Real scoping examples - A well-prepared client - A moving-scope client - A client who mixed compliance, SDLC, and testing needs without a clear goal - Human factors - Findings can feel personal - Defensive reactions slow down remediation - How to keep the conversation focused on impact instead of blame - During and after the test - Kickoff and status calls - Escalating high-impact findings - Assigning owners - Tracking remediation - Looking for root causes and finding chains PUBLIC CONFIRMED 25 Minute Talk https://pretalx.com/bsides-toronto-2026/talk/VVNLB7/ 1-067 Drew Wade PUBLISH LWW93J@@pretalx.com -LWW93J From CVE to PoC: Dissecting a Windows AFD.sys Heap Overflow en en 20261004T114500 20261004T121000 002500

From CVE to PoC: Dissecting a Windows AFD.sys Heap Overflow

The Windows CVE, labeled CVE-2026-21236, which was published on February 11, 2026, is a heap-based buffer overflow within the Windows driver: Ancillary Function Driver for WinSock or AFD.sys. The presentation will show a research workflow starting from: - the selection of vulnerability - the creation of the environment - the actual vulnerability analysis - creation of proof-concept-code - reporting Each step of the way detailing the lessons learned and how to do better. This talk will mainly focus on the often-undocumented analysis phase of exploit development, discussing how a CVE can be analyzed for a greater understanding of the vulnerability and how it could be exploited. PUBLIC CONFIRMED 25 Minute Talk https://pretalx.com/bsides-toronto-2026/talk/LWW93J/ 1-067 Emily Liu PUBLISH V8EVGP@@pretalx.com -V8EVGP Agentic SOC, Demystified: From Buzzword to Working Pipeline en en 20261004T121500 20261004T124000 002500

Agentic SOC, Demystified: From Buzzword to Working Pipeline

Every vendor is selling an "Agentic SOC" right now, and the term has been inflated into something that sounds mystical and expensive. Most practitioners can't tell where the real capability ends and the marketing begins. This talk fixes that by reducing the agent to its three actual parts and mapping each one onto SOC components the audience already owns, then proving it with a live demo and an honest look at where it falls apart. Slide Layout - What an AI agent actually is (no magic) - Brain: an LLM that reasons and decides - Tools: the actions it is allowed to take in the real world - Memory: context and past experience it can retrieve - Mapping the agent onto a SOC you already run - Collection: a SIEM gathering logs (Splunk) - Trigger: the condition that decides when to wake the agent - Reasoning: an LLM that designs queries and picks the search playbook - Action: a tool that runs those queries and returns L1/L2 analysis - Response: opening a ticket, escalating to MDR-style action by severity - Live demo: one use case, end to end (pre-built lab) - A trigger fires - The agent designs and runs its own Splunk queries - It returns a triaged verdict - The honest part: where agentic SOCs break - Indirect prompt injection via attacker-controlled log data - Hallucinated or incomplete queries and false negatives - Cost at real data volumes - Why autonomous response should keep a human in the loop PUBLIC CONFIRMED 25 Minute Talk https://pretalx.com/bsides-toronto-2026/talk/V8EVGP/ 1-067 AbdulMoiz Lakdawala