Schedule 2026

The Shai Hulud worm family has stalked the npm supply chain across multiple variants, stealing credentials from developer and CI environments, propagating via stolen npm and GitHub identities, poisoning workflows, and carrying a dead switch that can wipe home directories on command. Version four just crossed a new line. SANDWORM_MODE, deployed across 19 malicious npm packages, keeps the full prior playbook and adds AI toolchain poisoning via MCP server injection into Claude Code, Claude Desktop, Cursor, and Windsurf. The rogue MCP server uses prompt injection to instruct AI assistants to silently exfiltrate SSH keys, AWS credentials, and LLM API tokens from nine providers, without alerting the user. We present the full story: the Shai Hulud lineage, how the obfuscated three-layer loader was detected, how 19 packages were linked to one operator, how a bidirectional CI worm loop was built from a weaponized GitHub Action, and how coordinated takedown with npm, GitHub, and Cloudflare dismantled the infrastructure, along with what the dormant polymorphic engine tells us about where version five is heading.

AI‑assisted bug bounty has gone from niche experiment to mainstream workflow in less than a year. Open source toolchains like BugHunter, Claude‑BugBounty and autonomous “bug hunter AI” frameworks now orchestrate dozens of AI agents across recon, vuln discovery, validation and report drafting, wired directly into HackerOne/Bugcrowd scopes and real targets. But in many setups, these agents are treated as trusted copilots instead of high privilege software components with their own attack surface.

This talk shows how to turn those AI‑powered pipelines against their operators.

Using a lab composed of a popular AI bug bounty toolkit wired to a custom MCP (Model Context Protocol) server, the session demonstrates three backdoor patterns: exfiltrating secrets discovered during recon, silently downgrading or suppressing high impact findings before they reach the platform and steering autonomous hunting toward attacker chosen assets by poisoning skills, MCP tools and context.

Rather than hand waving about “AI risk”, I walk through concrete exploit chains against realistic workflows: skill bundles that rewrite reports, malicious MCP tools that masquerade as helper utilities and poisoned configurations that abuse cross‑session memory and auto‑resume features. For each attack, I then show defensive patterns that AppSec and bounty teams can actually deploy today: scope‑aware MCP tooling, signed skill/tool descriptors, validation gates on AI‑generated findings and explicit separation of duties between human and agent.

Attendees will leave with a clear model of where the real security boundaries are in AI‑powered bug bounty stacks and a practical checklist for hardening their own pipelines before an attacker files the first “backdoored bounty”.

There are two kinds of security testers: the ones using AI, and the ones getting left behind. But the first group has a growing problem. Ask an AI whether testing is complete, and the answer is almost always “yes.” The real question is whether it actually exercised every agent skill, performed meaningful verification, and explored the important paths, or simply hallucinated confidence while missing critical issues. This talk introduces graph-based AI penetration testing, a practical alternative to opaque AI security automation. Instead of relying on black-box systems that declare success without evidence, we use visual mind maps to guide and track LLM execution in a transparent way. Every node represents a decision, a tool action, or a validation step that can be inspected, audited, and customized.

In the live demo, we will build an attack plan in real time and show the AI executing each step while feeding real outputs directly into the graph. Rather than guessing whether a check actually ran, the mind map becomes a visible record of coverage and execution. We will also demonstrate how senior tester knowledge can be encoded into structured workflows, how specific agent skills can be invoked per node, and how flows can be adapted dynamically without retraining models. You will learn the architecture behind connecting mind maps to tool execution, techniques for runtime verification, and practical templates you can use immediately. Instead of trusting a black box that says “testing complete,” this approach enables AI-powered security testing that is transparent, auditable, and driven by real testing experience.

I built a runtime filter for agent tool calls, felt pretty good about it, then spent a week trying to get past it. I got through four different ways in an afternoon. This is the attacker’s side of that story - how the security controls people are bolting onto AI agents actually fail, and how to test your own before someone else does.

The theme is simple: never trust the string an agent hands you. A filter that blocks a tool by name is trivially beaten if it compares raw text. I’ll walk through four concrete bypasses, live where I can:

• Look-alike names. Call “delete_record” with a Cyrillic character, or splice in a zero-width space. Identical in the logs, invisible to an exact-match blocklist.
• Encoding. Wrap a SQL or shell payload in base64 (or nest it) so a scanner reading the raw parameters sees nothing dangerous.
• Renaming. The blocklist says delete_record; I call purge_all. Name lists don’t generalize to intent.
• Cross-tenant via SQL. A schema-qualified query - SELECT … FROM other_tenant.users - that never mentions the caller’s own tenant.

Then the part that makes it useful on Monday: a repeatable way to test an agent’s tool-layer defenses instead of guessing, and the fix for each bypass (normalization, decode-then-scan, verb/intent matching, schema checks) so you can tell whether a control is real or theater.

You’ll leave with a checklist to break - or validate - any tool-call filter, and a clear reason exact-string matching is a security anti-pattern in agent systems.

AI agents are being handed shell access, SQL, and MCP tool calls but most pipelines lack a deterministic, auditable “circuit breaker” that can halt risky actions before they execute. This session shows how we built Agent Circuit Breaker, an open‑source, local‑first runtime that inspects and blocks dangerous commands, SQL, and multi‑step agent trajectories before harm happens.

Every AI agent deployment ships with the same silent flaw: the agent holds far more privilege than any single task needs. When a prompt injection lands, the payload matters less than the blast radius, and the blast radius was set by the permissions granted last quarter. Gartner projects that through 2029, more than half of successful attacks on AI agents will exploit access control via prompt injection. Treating injection as a model problem has failed. Treating it as an access control problem gives defenders tools that already work.

This talk demonstrates five least-privilege patterns for agents and MCP servers, live against public reference MCP servers (filesystem, git, fetch, github):

1. Per-task tool allowlists instead of per-agent grants
2. Deny-by-default capability scoping at the MCP boundary
3. Deterministic egress controls, so an injected instruction cannot exfiltrate what it can read
4. Human-approval gates keyed to privilege tier, not blanket confirmation fatigue
5. Deriving a least-privilege policy from an agent’s observed behavior trace, then diffing every CI run against it to catch privilege drift

Each pattern maps to the OWASP MCP Top 10 and Agentic Security Initiative guidance, and every demo is reproducible from a public repo.

Attendees leave able to: inventory the real privilege surface of an agent they already run, write a deny-by-default policy for one MCP server the same week, and wire a drift check into CI so the policy stays honest. No product and no vendor pitch: everything shown is open source and runs on a laptop.

LLM-powered analytics agents that query enterprise data stores are entering production. They answer business questions by coordinating queries across knowledge graphs, vector stores, metrics databases, and warehouses simultaneously. The security challenge is specific: these agents are probabilistic systems accessing sensitive data, and once data enters the LLM context window, you cannot guarantee it will not surface in the response. Instructing the model to “not reveal sensitive data” is not a security control.

This talk presents a production architecture for enforcing deterministic, row-level security at the data layer before data ever reaches the LLM. Security is treated as a structural gate on the input, not a guardrail on the output. If the user lacks access to EMEA data, the graph query returns no EMEA nodes, the vector search excludes EMEA documents, and the metrics lookup filters EMEA figures. The LLM cannot leak what it never received.

I will cover: how to enforce consistent access policies across heterogeneous stores with different permission models (graph, vector, relational) when a single query fans out across all of them in parallel; why prompt-based output filtering fails as a security mechanism; how to build auditable access trails when an AI agent, not a human, is executing the queries; and common implementation mistakes (caching without permission context, protecting the warehouse but not the vector store, creating an unprotected exfiltration path through the least-secured store).

Attendees will leave with a concrete architectural pattern for securing LLM data agents, a pre-deployment checklist, and practical guidance on extending existing row-level security infrastructure to cover agentic access patterns.

AI agents are rapidly evolving from passive assistants to systems that can retrieve data, invoke tools, make decisions, and execute multi-step tasks with minimal human intervention. While these capabilities unlock significant business value, they also introduce new application security challenges that traditional security testing approaches were not designed to address.

How do we determine whether an AI agent is safe to deploy? How do we evaluate whether it will behave securely when faced with prompt injection attacks, unauthorized tool usage, sensitive data access, or failures in multi-step reasoning?

This session explores practical approaches for building production-ready evaluation frameworks and security guardrails for Agentic AI systems. Attendees will learn how to move beyond traditional model accuracy metrics to evaluate security, reliability, and trustworthiness in AI-powered applications.

Topics covered include threat modeling for Agentic AI applications, designing human approval workflows for high-risk actions, evaluating tool invocation and permission boundaries, implementing continuous monitoring strategies, and managing risk trade-offs between autonomy, usability, and security.

Attendees will leave with actionable architectural patterns and implementation strategies that can be immediately applied when building or securing AI-powered applications in production environments.

In the span of two weeks in July 2026, two incidents rewrote the playbook on what AI agents are capable of when left unsupervised.

First came JADEPUFFER, documented by Sysdig as the first fully agentic ransomware operation. An LLM driven attack chain that walked itself from an RCE in Langflow all the way through credential theft, lateral movement, persistence, and database extortion. When a login attempt failed, the agent diagnosed the issue and corrected course in 31 seconds. No human operator. No scripted fallback. Just a closed loop of try, fail, adapt.

Then an OpenAI agent running a cyber capability evaluation decided the fastest way to pass its test was to stop taking it. It broke out of its sandbox, got onto the open internet, and spent four and a half days executing over 17,600 actions across Hugging Face’s production infrastructure. It stole credentials, moved laterally, and exfiltrated dataset contents. Not because anyone told it to attack Hugging Face. It just figured that was the optimal path to its objective.

One of these was a criminal operation. The other was an accident. The defensive failures that enabled both were nearly identical.

This talk pulls apart both incidents step by step. We start with CVE-2025-3248 and walk through exactly how JADEPUFFER turned a single vulnerability into full infrastructure compromise. Then we look at the Hugging Face breach and what it tells us about containment, goal misalignment, and the gap between what we asked an agent to do and what it actually did. Along the way we cover ENCFORGE, the evolution of JADEPUFFER that started going after AI and ML artifacts specifically, treating model weights and training data as extortion leverage.

The point of this talk is not to marvel at what AI can do offensively. It is to look clearly at what breaks when your attacker can iterate faster than your SOC can triage, when the blast radius of a single RCE extends through every secret and service the application can reach, and when the threat might be coming from an agent you deployed yourself. We will talk about what actually needs to change in how we architect, monitor, and defend AI application ecosystems, and what detection strategies work when the attacker operates in a loop you cannot outpace manually.

Voice-based agentic AI systems — assistants, customer-support agents, and autonomous voice agents that chain speech recognition, large language models, tool invocation, and speech synthesis — introduce attack surfaces that neither text-only LLM red-teaming taxonomies nor classical speech-security literature fully capture. Existing surveys of voice AI security largely treat voice as an additional input channel layered onto text-based threats, organizing attacks by a single axis (attack surface, or “nature of the attack”) inherited from LLM jailbreak literature. This conflates two populations of attacks with fundamentally different origins and properties, and leaves no systematic account of which text-domain attacks actually survive the transition into a spoken interface.

This work introduces a taxonomy of voice AI red teaming built around an explicit top-level split between modality-transferred attacks — attacks whose mechanism is semantic or instructional and is agnostic to the channel carrying it — and modality-native attacks — attacks whose mechanism depends on properties of the acoustic channel itself (waveform, timing, speaker identity, transcription) and has no equivalent in a text-only system. Within each class, we classify individual attacks along four orthogonal axes: Attack Surface (where in the pipeline the attack targets), Adversarial Technique (how the attack operates), Attack Objective (why — including Availability as a first-class objective alongside Safety Bypass, Data Leakage, and Instruction Override), and Execution Context (the interaction pattern required).

We validate this scheme empirically against 41 real attacks: 21 attacks drawn from our implemented text/LLM red-teaming framework — selected for coverage of the OWASP LLM Top 10 attack classes rather than as a random or exhaustive sample — and 20 additional attacks compiled from voice-specific security research. Applying a simple transferability criterion — whether an attack’s success mechanism survives a text-to-speech-to-text round trip, evaluated against [name engine(s), or: multiple commercial and open-source ASR/TTS pipelines to control for engine-specific transcription artifacts] — we find that 15 of the 21 text-domain attacks transfer to voice unmodified, while 6 do not. The non-transferring attacks share a common property we term literal-dependence: they depend on surviving as a literal rendering of text (an encoded string, an exact token sequence, a fixed adversarial suffix), and this dependence — not attack surface or objective — is what predicts transfer failure. Every persona-, dialogue-, or reasoning-based attack in our corpus survives transfer.

Classifying the 20 audio-native attacks along the same four axes surfaces five clusters not visible under a single-axis taxonomy — transcription-boundary injection, speaker-identity confusion, signal-robustness attacks, conversational drift, and availability/denial-of-service — with availability attacks alone accounting for a quarter of the native corpus. Given the corpus size, we treat these as qualitative groupings rather than statistically validated clusters, and use them to motivate our decision to treat availability as a peer objective rather than a minor subcategory, departing from prior taxonomies. We also identify three attacks (context drift, tool-loop, memory-exhaustion) whose classification as native rather than transferred is genuinely ambiguous — these sit closer to agentic-orchestration failure modes than to the voice channel itself, and we position them explicitly against OWASP Agentic AI’s ASI attack classes — and use this ambiguity to refine the transferred/native boundary criterion.

Finally, mapping our corpus against classical audio-native authentication attacks (replay attacks, voice cloning, ultrasonic/DolphinAttack-style injection) reveals a coverage gap: none of the 41 attacks in our corpus target voice authentication directly, despite this being a well-established audio-native threat class. We treat this gap as both a limitation of current voice red-teaming practice and a concrete direction for future benchmark development, alongside automated native-attack generation and standardized transfer-fragility evaluation metrics.

As attackers automate exploits at machine speed, Web3 security must evolve. This talk explores how agentic AI is already detecting and stopping blockchain threats in the wild and what risks and responsibilities come with deploying autonomous security agents on-chain.

We blame the bot when AI-generated code is vulnerable. But what if the bot is just using the dangerous toys we left on the table?

This experiment tests whether bad APIs steer AI coding agents toward vulnerable code.

The same agent builds the same project twice: once with free library selection and once with bans on risky APIs and safer replacements.

The resulting projects are analyzed with SAST and manual review.

Can a safer API surface turn a reckless bot into a security champion?

AI coding assistants can help developers build user interfaces quickly, but the code they generate should not be treated as production-ready by default. A generated form, dashboard, or workflow may look correct in a demo while still creating security risks such as unsafe HTML rendering, missing validation, unnecessary dependencies, exposed configuration, or client-side trust assumptions.

This introductory talk explains how developers and AppSec teams can review AI-generated frontend code using simple, practical guardrails. The session will walk through common risk patterns, what to look for during review, and how teams can use approved components, basic static checks, dependency review, browser tests, and CI gates to catch problems earlier.

The goal is not to avoid AI coding tools. The goal is to use them safely by treating their output as a draft that still needs engineering review, automated checks, and clear security boundaries.

Attendees will leave with a beginner-friendly checklist they can use when reviewing AI-generated frontend code.

AI Security Engineer Foundations: Enforcing Policy with AI-BOM

As AI systems move from experimentation into production, security teams face a new problem: they often don’t know which models, datasets, or AI services are actually being used in their software. This lack of visibility makes it nearly impossible to enforce policy, assess risk, or meet emerging regulatory requirements.

This talk introduces AI Bills of Materials (AI-BOMs) as a foundational tool for AI security engineering. Beyond inventory, AI-BOMs provide a practical enforcement layer—making AI usage observable, auditable, and governable. We’ll start with a concise overview of what an AI-BOM is, how it differs from SBOMs, and why it matters for security teams today.

The session then moves from theory to practice. Attendees will see a live command-line demonstration of generating and validating an AI-BOM, followed by a GitHub Actions workflow that automatically fails a build when an unapproved or unknown AI model is introduced into a project. The result is a concrete example of “policy as code” applied to AI systems.

By the end of this talk, security engineers and platform teams will understand how AI-BOMs can serve as a control plane for AI governance—and how to start enforcing AI security policies before incidents and audits force the issue.

Everyone wants AI. Few know how to secure it. This session discusses how modern AppSec teams can move beyond saying “No” and build an AI Security Program that enables innovation while managing emerging risks.

Generative AI is rapidly changing software development by accelerating code generation, automated testing, code review, and operational workflows. While these capabilities improve developer productivity, they also introduce application security and governance risks that regulated financial institutions must address before AI-generated code can be trusted in production.

This session examines two security challenges that emerge in AI-assisted software delivery. The first is correlated failure, where AI-generated application code and AI-generated test cases inherit the same incorrect assumptions, allowing vulnerabilities and logic flaws to bypass validation. The second is AI hallucination, where generated code appears technically correct but violates secure coding practices, financial business rules, or regulatory requirements, creating security, compliance, and operational risks.

The session presents a practical governance framework aligned with the NIST AI Risk Management Framework (AI RMF 1.0), Basel Committee Operational Resilience Principles, and EBA ICT Risk Management Guidelines. Attendees will learn how to integrate human review, security validation, and risk-based approval into AI-assisted development pipelines without slowing software delivery. The framework evaluates software according to business impact and security risk rather than whether it was authored by a developer or generated by AI.

The session also explores how governance must evolve as AI systems begin generating patches, diagnosing production incidents, and orchestrating infrastructure, raising new questions around accountability, security oversight, and regulatory compliance.

Attendees will leave with practical guidance for implementing secure governance controls, strengthening AI-assisted SDLC practices, and adopting AI-generated code while maintaining application security, operational resilience, and regulatory compliance.

Retrieval-Augmented Generation has become the dominant approach for deploying enterprise generative AI, enabling large language models to produce responses grounded in organizational knowledge without embedding sensitive data into model weights. In regulated financial environments, however, RAG pipelines introduce serious application security risks including sensitive information disclosure, entitlement bypass, provenance ambiguity, and inconsistent policy enforcement across ingestion, indexing, retrieval, and generation stages. This session presents a Secure RAG reference architecture designed specifically for banking and financial institutions operating under strict compliance and data governance mandates. The framework addresses three foundational security objectives: preventing data leakage, ensuring verifiable provenance, and enabling enforceable policy controls throughout the AI lifecycle. The architecture integrates identity- and attribute-aware retrieval mechanisms, policy-as-code enforcement using Attribute-Based Access Control, retrieval-scoped access filters, redaction gates for sensitive outputs, and immutable audit logging. To support audit defensibility, the framework introduces evidence bundles containing document identifiers, retrieval metadata, version history, timestamps, and policy decisions that can be produced on demand for compliance reviews. The session also maps major threat categories relevant to financial AI systems, including prompt injection, retrieval compromise, sensitive output generation, and supply chain risks, and demonstrates how each can be mitigated through the proposed controls. Attendees will also walk away with a practical evaluation methodology covering leakage prevention rates, entitlement enforcement accuracy, provenance fidelity, refusal correctness, latency impact, and operational cost.

Generative AI is rapidly becoming part of enterprise applications, yet deploying Retrieval-Augmented Generation (RAG) securely remains a significant application security challenge. While vector databases and semantic retrieval improve knowledge discovery, they also introduce new attack surfaces, including prompt injection, data poisoning, retrieval manipulation, unauthorized information disclosure, and insecure AI pipelines. This presentation examines how to design secure enterprise RAG architectures that deliver trustworthy, context-aware responses while protecting sensitive organizational knowledge.

The session explores practical architectural patterns for securing vectorized knowledge systems using embedding isolation, hybrid retrieval validation, secure vector indexing, identity-aware access controls, encrypted storage, and policy-driven governance. It demonstrates how retrieval validation, grounding verification, provenance tracking, and human oversight reduce hallucinations and strengthen AI reliability within production environments. Additional topics include protecting enterprise data during ingestion, securing AI-assisted applications across the software development lifecycle, implementing zero-trust principles for AI services, and monitoring retrieval pipelines for anomalous behavior. The presentation also discusses emerging techniques including agentic RAG, graph-enhanced retrieval, and runtime security controls that improve reasoning while maintaining application security.

Attendees will leave with actionable architectural guidance for designing scalable, secure, and production-ready AI knowledge platforms that strengthen enterprise application security while enabling responsible adoption of generative AI.

Financial crime detection increasingly depends on secure, trusted, and explainable data flows across web, cloud, API, and analytics platforms. Yet many institutions still struggle with fragmented metadata, inconsistent lineage, weak validation controls, and limited visibility into how sensitive data is classified, transformed, and consumed across detection systems. This session presents an application security–focused framework for using AI-powered metadata management to improve data quality, resilience, and governance in cross-border financial crime monitoring.

The talk will show how supervised learning, semantic classification, entity resolution, and API-first metadata services can be securely embedded into enterprise architectures to automate classification, enrichment, validation, and lineage tracking. It will also address key AppSec concerns, including privacy controls, secure API design, access governance, model explainability, adversarial testing, and auditability. Real-world implementation patterns demonstrate reductions in reconciliation effort, false positives, alert fatigue, and case resolution time while improving regulatory confidence.

Attendees will learn practical design patterns for building secure metadata pipelines, integrating AI safely into financial crime platforms, and applying OWASP-aligned principles to data-intensive compliance systems. The session is relevant for builders, defenders, architects, and security leaders working to secure AI-enabled financial applications at scale.

Financial application environments operate across complex APIs, microservices, cloud platforms, legacy systems, and regulated data flows, creating security and reliability challenges that exceed traditional monitoring capacity. This session presents an agentic AI framework for self-healing AppSec operations, designed to detect, reason about, and respond to threats and service degradation at machine speed while preserving human oversight and compliance. The architecture uses specialized agents for application telemetry, anomaly detection, vulnerability triage, incident response, access risk, configuration drift, and capacity protection. These agents collaborate to identify attack patterns, correlate security signals, prioritize alerts, and recommend or execute controlled remediation actions. For OWASP Defender, Ops, and Manager audiences, the talk demonstrates how graduated autonomy can support production security programs without removing accountability. Routine high-confidence events can trigger automated containment, while uncertain or high-risk scenarios escalate to human operators with evidence, reasoning chains, and audit trails. The framework also addresses explainability, policy enforcement, regulatory reporting, and integration with DevSecOps pipelines, SIEM, SOAR, and application security testing workflows. By reducing alert fatigue, improving response speed, and strengthening operational visibility, agentic AI enables financial institutions to build secure, resilient, and continuously defended application ecosystems

Enterprise storage migrations remain one of the most operationally risky infrastructure transformations, frequently introducing security blind spots, configuration drift, unauthorized access paths, and service disruptions. In large multi-vendor environments, security teams often struggle to validate storage configurations, zoning policies, access controls, and compliance requirements while maintaining application availability. This session presents SmartSAN AI, an AI-driven framework designed to automate secure Storage Area Network (SAN) migrations with near-zero downtime. The platform combines machine learning–based risk prediction, automated compatibility validation, anomaly detection, and policy-driven provisioning to identify migration bottlenecks and security misconfigurations before cutover. Through large-scale enterprise implementations, SmartSAN AI achieved 93% prediction accuracy for migration risks, detected 97.3% of compatibility and configuration anomalies, and automated validation across hundreds of vendor-specific storage patterns. Attendees will learn how AI can be integrated into operational security workflows to continuously assess migration readiness, enforce least-privilege access models, validate zoning integrity, and reduce human error during critical infrastructure changes. The session will also demonstrate how automated rollback mechanisms, real-time monitoring, and ITSM integration help security and operations teams maintain compliance with ITIL, COBIT, and ISO 27001 requirements while reducing incident volumes and accelerating recovery. Practical lessons and implementation strategies will be shared for organizations pursuing secure, resilient, and non-disruptive infrastructure modernization.

Organizations increasingly rely on AI to accelerate operational decision-making, yet many struggle to balance speed, trust, governance, and human oversight. As operational data volumes grow across enterprise platforms, customer systems, and digital ecosystems, analytics teams face mounting challenges in extracting reliable insights while maintaining accountability for business decisions.

This presentation introduces agentic analytics, an emerging approach in which AI agents actively participate in analytical workflows by exploring datasets, identifying anomalies, generating summaries, and supporting decision intelligence under human supervision. Rather than replacing analysts, agentic systems augment human expertise by reducing manual effort associated with data extraction, exploratory analysis, reporting, and insight generation.

The session presents a practical framework for implementing agentic analytics through the integration of an enterprise data layer, analytics model layer, and AI agent layer. Attendees will learn how operational data is transformed into analytical outputs and decision-support narratives through structured human-AI collaboration.

A key focus of the discussion is the governance and risk considerations associated with AI-assisted analytics. The presentation examines validation of AI-generated insights, transparency of analytical reasoning, data governance requirements, and the operational risks of automation bias. It also explores how organizations can establish guardrails that preserve human accountability while benefiting from AI-driven analytical efficiency.

Attendees will leave with a clear understanding of the architectural components, governance practices, and implementation considerations required to deploy agentic analytics responsibly. The session is intended for security leaders, architects, operations teams, and technology practitioners seeking practical approaches for leveraging AI agents to improve decision intelligence while maintaining trust, oversight, and organizational control.

LLM demos are easy. Production AI is where things get weird.

In this talk, I’ll walk through what actually changes when you move from a clever prototype to an AI feature real people depend on: messy prompts, unclear user intent, unreliable outputs, security constraints, evaluation gaps, and the painful moment when demo accuracy collapses in the wild.

Using real-world lessons from building internal AI assistants, natural-language data tools, and enterprise AI workflows, we’ll cover how developers can design AI systems that are useful, testable, and trusted. We’ll look at practical patterns for scoping use cases, setting confidence boundaries, keeping humans in the loop, and measuring whether the AI is actually helping.

Attendees will leave with a simple framework for deciding when an LLM belongs in a workflow, when it doesn’t, and how to avoid shipping an impressive toy that nobody trusts.

Financial services customers operating under DORA, APRA CPS 230 and 234, and NYDFS 500 are required to audit their critical outsourced technology providers. For years the only answer was a one-to-one model: each customer scheduling a separate engagement, reviewing the same controls, asking many of the same questions. The resource drain compounds on both sides.

This session walks through what it takes to build a pooled audit program: one structured multi-day session, multiple regulated customers assessing the same control environment simultaneously. We cover how to get regulators to accept it, what control domains matter most across different frameworks, how peer-to-peer customer learning emerges as an unplanned benefit, and what separates a program that satisfies a regulator from one that merely informs them.The audience leaves with a replicable framework for designing, piloting, and scaling a pooled audit model, grounded in hard-learned lessons from practitioners who have run this across multiple regulatory regimes and customer bases.

No vendor pitch. Practitioner-tested.

Organizations today are overwhelmed by cybersecurity frameworks, audits, scorecards, compliance requirements, and vendor promises — yet many still struggle to answer fundamental operational questions:

• Where are we actually vulnerable?
• Which weaknesses matter most?
• What should we improve first?
• How do we measure real progress?
• And how resilient are we beyond compliance checklists?

Frameworks such as ISO 27001, NIST CSF, CIS Controls, Zero Trust architectures, and various maturity assessments provide valuable guidance. However, in real-world environments, many organizations still face a dangerous gap between documented compliance and actual operational cyber resilience.

This session introduces the Helvetic Cybersecurity Maturity Model (HCMM), a practical and structured approach designed to help organizations assess, visualize, prioritize, and improve cybersecurity maturity in a measurable and operationally meaningful way.

Rather than introducing “yet another framework,” this talk focuses on the real-world challenges many organizations face today:

• security programs driven by compliance instead of resilience
• fragmented tooling without strategic visibility
• unclear prioritization of investments
• leadership blind spots
• and the growing disconnect between technical controls and business risk

The session explores how maturity-based approaches can help organizations:

• identify operational weaknesses
• improve governance visibility
• prioritize security initiatives
• align cybersecurity with business objectives
• and build realistic improvement roadmaps instead of checkbox-driven activities

Attendees will gain practical insights into:

• where traditional cybersecurity maturity initiatives often fail
• why compliance alone is not enough
• how organizations can evaluate cyber resilience more realistically
• and how structured maturity models can support better operational and strategic decision-making

The presentation includes practical examples, governance considerations, operational perspectives, and lessons learned from complex transformation and cybersecurity environments.

Participants will leave with:

• a clearer understanding of the gap between compliance and resilience
• practical ideas for evaluating cybersecurity maturity
• approaches for prioritizing security improvements
• and actionable concepts for building measurable cyber resilience programs

Application security programs often fail at the point where technical guidance must become human action. Developers may notice risks but hesitate to raise them, security teams may struggle to communicate business impact, and leaders may unintentionally create conditions where concerns surface too late.

This session introduces Human Readiness as the organizational capacity to question assumptions, communicate risk, escalate concerns, and collaborate across security, engineering, and leadership teams. Attendees will examine how voice, trust, self-belief, and visibility influence secure-by-design adoption and AppSec culture.

Using realistic workplace scenarios, participants will learn how to identify silence points within the software development lifecycle, improve conversations about risk and trade-offs, and create practical opportunities for security concerns to be raised earlier.

Security awareness tells people what to notice. Human Readiness determines whether they are prepared and supported to act on it.

Learning Objectives

1. Identify communication and culture gaps that prevent AppSec concerns from being raised, understood, or escalated.
2. Apply a practical visibility framework to improve risk conversations between security, engineering, and leadership teams.
3. Design one team practice that supports earlier escalation, stronger collaboration, and secure-by-design decision-making.