As enterprises race up the AI adoption ladder — chat, file upload, enterprise search, connectors, actions, memory — each new rung adds capability and quietly removes a checkpoint. This talk reframed enterprise AI assistant risk as a data-flow and authorization problem rather than a model problem. The central thesis: the model can recommend, but the application must authorize. A prompt becomes dangerous the moment data crosses an identity, tool, memory, tenant, or destination boundary without deterministic enforcement outside the model. I demonstrated this live across four attack paths, each following the same rhythm — scenario, exploit, data flow, and the enforcement control that actually contains it.

Each path was shown with a live, deterministic demo — running the vulnerable flow first, then toggling to the defended version to show the exact control that changes the outcome.

1. Sensitive Input & Shadow AI: An engineer pastes an incident log — production API key, customer data, stack trace — into an assistant to summarize before sending it to a vendor. A scanner detects the secrets and warns, but no destination policy blocks the transfer, so the data still leaves. The lesson: visibility is not enforcement.

2. Retrieved Injection: A user asks a routine question; enterprise search returns a ticket an external collaborator edited with hidden instructions. The user never typed the malicious prompt, yet the assistant acts on it. Retrieved content is data, not authority — telling the model to ignore malicious text only lowers the odds; the containing control is authorization outside the model.

3. Connector Identity: The assistant invokes a connector — but whose identity does it use? A shared service token becomes a master key whose blast radius is defined by what the credential reaches, not by what the user is allowed to see. OAuth scope is not user authorization. The fix is delegated, per-user identity with resource-level checks.

4. Memory & Cross-Context: One user stores confidential project context; another later asks an unrelated question and the first user’s data surfaces through pure semantic relevance. Sending all memory to the model and hoping it self-filters has already crossed the boundary — retrieval must filter by owner, tenant, and classification before ranking.

Across all four paths the defensive pattern is the same: the model interprets and proposes; the application owns every non-negotiable decision.

These are not hypothetical. The talk mapped each path to disclosed incidents — EchoLeak (CVE-2025-32711, zero-click exfiltration in M365 Copilot), Slack AI’s public-to-private instruction execution, the Salesloft/Drift OAuth token breach, the Meta AI cross-user conversation bug, and the Dialogflow CX hijack flaw — every one a data-flow or authorization failure, not a model jailbreak.

Slides can be found here:

Autonomous AI agents can take actions, call APIs, access data stores, and operate over multiple turns with persistent context. That combination — autonomy, tool access, and memory — creates a new class of vulnerabilities that traditional AppSec frameworks don’t fully cover. This talk walked through how agents go rogue and what to change architecturally to make them defensible.

Prompt Injection: The highest-impact attack — malicious instructions embedded in content the agent processes (emails, documents, tool responses) override its original instructions. Indirect injection from retrieved third-party content is harder to detect and more dangerous than direct user input.

Tool Abuse via Over-Permissioning: Agents with broad tool scopes don’t need to be "hacked" — they just need to be convinced via injection to use their legitimately granted permissions in unintended ways: exfiltrating data, sending unauthorized messages, or triggering bulk operations.

Memory and Retrieval Poisoning: Documents uploaded to a RAG pipeline can contain embedded instructions that fire at query time. In multi-user environments, one user’s poisoned upload can affect another user’s agent context.

Multi-Turn Exploitation: A planted instruction in an early turn ("remember to CC this address on summaries") sits dormant in context until triggered — separating the manipulation from the harmful action in time.

Implicit Trust in Tool Responses: Frameworks that feed tool responses directly back into model context allow an attacker who influences a tool response (via a compromised API or crafted external data) to inject instructions the model treats as authoritative.

Resources:

AI agents are hitting production faster than security teams can keep up. They have tool access, persistent memory, API keys, and broad permissions — and most teams building them are focused on capability, not attack surface.

This was a live tear down: I stood up a deliberately vulnerable AI agent wired into Gmail, Slack, and document retrieval, then systematically exploited it — not with jailbreaks, but with architectural mistakes common in real systems. The audience watched credentials leak, unintended actions execute, and data flow where it shouldn’t. Then I fixed it. Same app, different architecture.

Flaw 1 — Over-permissioned Gmail tool: A prompt injection in an incoming email instructed the agent to forward all matching messages externally. With full send scope and no output validation, it complied. Fix: scope tools per operation, require confirmation for destructive actions.

Flaw 2 — Poisoned RAG store: A document in the retrieval store contained embedded instructions that fired at query time, leaking user context to an external webhook. Fix: treat retrieved content as untrusted data, not instructions.

Flaw 3 — Injected tool response: A crafted Slack response embedded a follow-up instruction that the agent treated as legitimate. Fix: validate tool responses before returning them to model context.

Resources:

Quantum computing is rapidly moving from theory to practical reality—and its impact on application security will be profound. Within the next decade, quantum algorithms may break the cryptographic foundations that protect modern applications, including HTTPS/TLS, JWTs, digital signatures, mobile authentication, and blockchain-based trust models.

Adversaries are already responding with a strategy known as "harvest now, decrypt later"—collecting encrypted traffic today to exploit future quantum capabilities. This talk demystified quantum computing for application security professionals and focused on what AppSec teams need to understand and act on now.

Covered the two key quantum algorithms threatening modern cryptography:

Shor’s Algorithm: Efficiently factors large integers and solves discrete logarithm problems—directly breaking RSA, ECC, and Diffie-Hellman. This threatens TLS key exchange, JWT signing (RS256, ES256), certificate authorities, and mobile/blockchain authentication.

Grover’s Algorithm: Provides a quadratic speedup for brute-force search—effectively halving the security of symmetric algorithms like AES. AES-128 becomes equivalent to 64-bit security under quantum attack; AES-256 remains viable with doubled key length considerations.

Mapped quantum threats to concrete AppSec scenarios teams encounter today:

Walked through the emerging NIST post-quantum cryptography (PQC) standards and their application-level fit:

A pragmatic, phased approach for preparing applications before quantum threats become operationally unavoidable:

Phase 1 — Cryptographic Inventory Identify all cryptographic assets: TLS certificates, JWT signing keys, encryption keys, hashing algorithms, third-party libraries, and APIs. Map them to quantum-vulnerable vs. quantum-safe categories.

Phase 2 — Crypto Agility Refactor applications to treat cryptographic algorithms as configurable parameters rather than hard-coded choices. This enables fast algorithm swaps without architectural rework when standards evolve.

Phase 3 — Hybrid Deployments Deploy hybrid TLS (classical + PQC key exchange simultaneously) and hybrid signatures to maintain backwards compatibility while testing PQC in production. Major TLS libraries and cloud providers are already supporting this.

Phase 4 — Testing and Tooling Update SAST/DAST rules to flag quantum-vulnerable algorithms. Test PQC implementations for performance overhead (especially in mobile/IoT contexts). Validate certificate chains with PQC CAs.

Phase 5 — CI/CD and Platform Readiness Integrate cryptographic algorithm checks into CI/CD pipelines. Ensure container base images, language runtimes, and platform dependencies support PQC libraries. Track NIST and vendor timelines.

Slides can be found here:

Passwords have been the default authentication mechanism for decades — and they are failing. Weak passwords, password reuse, phishing, credential stuffing, and data breaches make password-based authentication a liability for both individuals and organizations. This session addressed why the status quo is broken, and what practical steps teams can take today using password managers and passkeys to dramatically reduce authentication-related risk.

The audience — primarily IT staff and operators at water and wastewater utilities — face the same authentication threats as any organization, with the added consequence that compromised access to operational systems can have public safety implications.

The scale of the problem:

Fundamental weaknesses:

Password managers solve the human side of the problem by generating, storing, and auto-filling unique, complex passwords for every account.

Key benefits:

Organizational considerations:

Passkeys are the next step — eliminating passwords entirely for supported services. Built on the FIDO2/WebAuthn standard, passkeys use public-key cryptography tied to the user’s device.

How passkeys work:

Security advantages:

Adoption landscape:

Immediate actions:

Near-term steps:

Strategic direction:

Slides can be found here:

See how attackers can manipulate system prompts to bypass restrictions, extract sensitive information, or execute unauthorized actions.

Learn how attackers can inject malicious content into retrieval-augmented generation systems to manipulate responses.

Demonstrate malicious tool calling, parameter injection, and unauthorized function execution.

Open frontend/index.html in your browser for an interactive demonstration interface with:

This talk covered LLM security topics adapted for auditors and compliance professionals. The framing shifted to address audit-specific concerns: what controls should exist, how to test them, regulatory implications, risk quantification, and governance structures.

LLMs power business-critical applications (chatbots, developer copilots, security analysis, automated decision-making), bringing new attack surfaces traditional security models don’t address. For auditors: how do you audit systems that are probabilistic and whose behavior can’t always be predicted?

This talk covered prompt injection, jailbreaks, safety evasion, model extraction, and insecure tool integrations—contextualized with control objectives, audit procedures, evidence collection, and risk rating criteria.

Structured around auditable control domains:

Live demos illustrated attacks and explained what auditors should look for during control tests, "good" vs. "bad" implementations, documentation approaches, and compensating controls. Each exploit paired with defensive strategies framed as auditable controls.

Addressed communicating findings to stakeholders: risk rating frameworks, control maturity models, audit report structures, and board-level reporting translating technical vulnerabilities into business risks.

Attendees left with audit program templates, control checklists, risk assessment frameworks, testing methodologies, regulatory guidance (NIST, ISO 27001, SOC 2), and sample audit findings—bridging technical LLM security and audit practice.

Slides can be found here: View Slides

LLMs now power business-critical applications (chatbots, developer copilots, security analysis, automated decision-making), bringing new attack surfaces traditional security models don’t address. Unlike conventional AppSec bugs, LLM security challenges arise from their probabilistic nature.

This talk delivered a practical, attacker-focused tour of LLM vulnerabilities: prompt injection, jailbreaks, safety evasion, model extraction, and insecure tool integrations—emphasizing hands-on demonstrations over theory.

Live demos using open-source models (Mistral, Llama) illustrated attacks in realistic environments:

Each attack paired with real-world context from actual incidents and production breaches.

Actionable strategies: prompt hardening (multi-layer defenses, delimiter separation), input sanitization (injection detection, content filtering), output filtering (validation, PII redaction), context isolation (sandboxing, privilege separation), tool policy enforcement (whitelist-based calling), AI red teaming (OWASP Top 10 for LLMs), and monitoring/telemetry (real-time logging, anomaly detection).

Introduced the LLMSec Demo application—an open-source training platform demonstrating vulnerable vs. defended implementations side-by-side.

Attendees left with hands-on attack knowledge, defense playbooks, testing tools, risk assessment frameworks, and open-source resources—bridging the gap between GenAI hype and production security reality.

Slides can be found here: View Slides

Quantum computing poses an existential threat to cryptographic foundations of modern cybersecurity. This presentation combined technical depth with practical guidance on preparing for the post-quantum era, tailored for HOPE’s technically sophisticated audience.

Current encryption methods (RSA, ECC) securing web applications, APIs, and sensitive data risk becoming obsolete due to quantum attacks via Shor’s Algorithm. The "harvest now, decrypt later" threat means adversaries are already collecting encrypted data today for future decryption, making post-quantum cryptography (PQC) migration urgent.

The presentation included live demonstrations of vulnerable vs. quantum-safe implementations and a prioritization framework for securing high-value assets first.

Slides can be found here: View Slides

Quantum computing represents an existential threat to modern AppSec. Current encryption (RSA, ECC) securing web applications, APIs, and sensitive data risks becoming obsolete due to quantum attacks via Shor’s Algorithm.

The critical "harvest now, decrypt later" threat: adversaries are already intercepting encrypted communications for future quantum decryption. For sensitive data (financial, healthcare, government, IP), the clock is ticking—data encrypted today may be vulnerable within a decade.

Slides can be found here: View Slides