BEGIN:VCALENDAR
VERSION:2.0
X-WR-CALNAME:appsecdayisrael2026
X-WR-CALDESC:Event Calendar
METHOD:PUBLISH
CALSCALE:GREGORIAN
PRODID:-//Sched.com AppSec Israel 2026//EN
X-WR-TIMEZONE:UTC
BEGIN:VEVENT
DTSTAMP:20260910T160755Z
DTSTART:20261006T063000Z
DTEND:20261006T064500Z
SUMMARY:Opening remarks
DESCRIPTION:\n
CATEGORIES:KEYNOTE HALL
LOCATION:Keynote Hall\, Expo Tel-Aviv
SEQUENCE:0
UID:8aedc49c3f711e69c410909facee8f81
URL:http://appsecdayisrael2026.sched.com/event/8aedc49c3f711e69c410909facee8f81
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260910T160755Z
DTSTART:20261006T064500Z
DTEND:20261006T073000Z
SUMMARY:Keynote talk!
DESCRIPTION:\n
CATEGORIES:KEYNOTE HALL
LOCATION:Keynote Hall\, Expo Tel-Aviv
SEQUENCE:0
UID:ba5392af93d8583d14753fa1f95e486c
URL:http://appsecdayisrael2026.sched.com/event/ba5392af93d8583d14753fa1f95e486c
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260910T160755Z
DTSTART:20261006T073000Z
DTEND:20261006T081500Z
SUMMARY:When React Becomes an Attack Vector: Lessons from the React2Shell CVE
DESCRIPTION:This session presents a structured\, security-focused analysis of the React2Shell vulnerability as a real-world case study in insecure design and broken trust boundaries in modern frontend frameworks. \n \nThe talk begins by establishing a clear threat model for React and Next.js applications that use Server Components and Server Actions. We define the relevant trust zones\, browser\, framework runtime\, and application server\, and explicitly highlight where data crosses from untrusted client control into trusted server-side execution. \n \nFrom there\, we analyze the React2Shell CVE and its underlying root causes\, including: \n- Implicit trust in framework-generated client invocations \n- Insufficient verification of serialized input crossing the client–server boundary \n- A blurred separation between data and executable intent \n \n \nThe session then examines the security fix\, explaining how changes to validation and execution flow resolved the issue and which assumptions were corrected at the framework level. \n \nBuilding on this analysis\, the talk transitions into defensive standards and verification strategies that can help prevent similar classes of vulnerabilities. Using threat modeling and OWASP guidance\, we map the issue to relevant OWASP ASVS controls\, including: \nASVS V1 – Architecture\, Design\, and Threat Modeling \nASVS V4 – Access Control \nASVS V5 – Input Validation and Processing \nASVS V14 – Configuration \n \nWe conclude with practical defensive patterns applicable beyond React and Next.js\, such as: \n- Treating framework-managed invocations as untrusted input \n- Applying defense-in-depth across client\, framework\, and server layers \n- Improving observability and logging for server-side execution paths \n- The role and limitations of WAFs in this class of vulnerability \n \nTools & Techniques Used \n- Conceptual architecture and trust-boundary diagrams \n- Framework execution-flow diagrams \n- Threat modeling techniques \n- OWASP ASVS and WSTG cross-referencing \n \n \nIntended Audience \nThis session is intended for: \n- Application Security engineers \n- Security architects \n- Developers involved in secure design reviews
CATEGORIES:HALL A
LOCATION:Hall A\, Expo Tel-Aviv
SEQUENCE:0
UID:6864d4694d46e0eb816dbe32d1eab968
URL:http://appsecdayisrael2026.sched.com/event/6864d4694d46e0eb816dbe32d1eab968
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260910T160755Z
DTSTART:20261006T073000Z
DTEND:20261006T084500Z
SUMMARY:Bad Vibes: Comparing the Secure Coding Capabilities of Coding Agents
DESCRIPTION:For this research\, we designed an identical set of prompts specifying the exact requirements and tech stack for three web applications. The prompts were intentionally security neutral - they provided no security-specific guidelines\, and only focused on required functionality. &nbsp\;Each of the five agents built all three applications\, giving us 15 codebases to analyze. \nTo find vulnerabilities\, we combined static code analysis (CodeQL\, Semgrep\, Snyk)\, dynamic agent-based testing (Tenzai's hacking agent\, Claude Code)\, and human verification of every finding. This produced a dataset of 70 vulnerabilities of varying severity across the 15 applications - from which we extracted a set of meaningful patterns and lessons. \nThe good: coding agents appear to be quite effective at avoiding certain classes of bugs. A notable example were "notorious" categories of injection attacks. Across all the applications we developed\, we didn't encounter a single exploitable SQLi or XSS vulnerability - two bug classes that have been staples of the OWASP Top 10 for years. \nOur observation is that coding agents perform well when the vulnerability class has well defined built-in protections. For SQL injection\, agents consistently used parameterized queries\, resulting in secure database interactions. With XSS\, the agents' code often didn’t sanitize input\, but it used frontend frameworks properly\, which prevented vulnerabilities from becoming exploitable. \nThe bad: While coding agents did relatively well with vulnerabilities that have clear and generic solutions - they struggled with issues that didn’t have one. \nCoding agents did very poorly in terms of properly enforcing authorization. They managed basic requirements reasonably well\, but struggled significantly as authorization logic became more complex\, despite clear and detailed guidance in our prompts. \nAnother area of concern was business logic vulnerabilities. While human developers bring intuitive understanding that helps them grasp how workflows should operate\, agents lack this “common sense” and depend mainly on explicit instructions. Without sufficiently detailed specification\, agents can easily overlook important nuances. \nThe ugly: The most concerning finding from this research wasn't the vulnerabilities in code the agents wrote\, but ones that were introduced by code the agents didn't write. All the coding agents\, across every test we performed\, failed miserably when it came to security controls. It wasn’t that they implemented them incorrectly\, in almost all cases - they didn’t even try. \nAcross the board\, critical controls like CSRF protection\, security headers\, and login rate limiting were nowhere to be found. Coding agents built what we explicitly asked for\, often in reasonably secure ways\, but completely failed to grasp "the bigger picture.” They lack the security mindset to proactively introduce defensive mechanisms that weren't explicitly requested. \n \nAfter identifying these patterns\, we set out to test different strategies to improve the security of the vibe coded apps. Using the same prompts\, we evaluated three strategies: providing generic high-level security instructions in the prompt\, having an agent analyze the prompt and inject security requirements before execution\, and having the coding agent perform a security review of its own output. \nWe'll show how these techniques solve a lot (but not all) of the issues we uncovered\, and share actionable guidance for developers looking to ship AI-generated code more securely. \n
CATEGORIES:HALL B
LOCATION:Hall B\, Expo Tel-Aviv
SEQUENCE:0
UID:379df7f8f9d0d6c6b98a79646e16058d
URL:http://appsecdayisrael2026.sched.com/event/379df7f8f9d0d6c6b98a79646e16058d
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260910T160755Z
DTSTART:20261006T073000Z
DTEND:20261006T081500Z
SUMMARY:Unveiling the OWASP Top 10 for Agentic AI
DESCRIPTION:1. Introduction: Why we need a new Top 10 list distinct from the LLM Top 10. \n2. The Agentic Architecture: Understanding the shift in inputs and outputs. \n3. The OWASP Agentic Top 10 in Action: Breaking down real-world attacks. \n4. Key Mitigations: Actionable steps you can implement tomorrow morning. \n5. Where to Start: How to become the AI security champion in your organization. \n6. What’s Next: Joining the movement and shaping the future of agentic safety.
CATEGORIES:KEYNOTE HALL
LOCATION:Keynote Hall\, Expo Tel-Aviv
SEQUENCE:0
UID:f271444ef0eaf289e9fc402184a9d0aa
URL:http://appsecdayisrael2026.sched.com/event/f271444ef0eaf289e9fc402184a9d0aa
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260910T160755Z
DTSTART:20261006T081500Z
DTEND:20261006T083000Z
SUMMARY:Coffee Break
DESCRIPTION:\n
CATEGORIES:EXPO HALL
LOCATION:Expo Hall\, Expo Tel-Aviv
SEQUENCE:0
UID:9ea99f13ebeb5bb35eae7ef87708ab19
URL:http://appsecdayisrael2026.sched.com/event/9ea99f13ebeb5bb35eae7ef87708ab19
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260910T160755Z
DTSTART:20261006T083000Z
DTEND:20261006T091500Z
SUMMARY:The Hidden DoS Vector in SQL Parsers
DESCRIPTION:We disclosed four vulnerabilities in the widely used SQL parsers SQLGlot and SQLFluff\, as well as issues affecting downstream applications such as Apache Superset (70k GitHub stars)\, Pathway (60k GitHub stars)\, and other tools that rely on these parsers. Some of these downstream vulnerabilities have also been disclosed. \n \nThese flaws allow syntactically valid queries to trigger crashes or out-of-memory errors via recursion and AST object inflation. Our findings demonstrate that even well-formed queries can be weaponized to disrupt data workflows. We provide practical mitigations to help maintainers and platform builders strengthen parsers against this class of attacks.
CATEGORIES:HALL A
LOCATION:Hall A\, Expo Tel-Aviv
SEQUENCE:0
UID:571fd2a336e4e59356bc390e7bbc96e6
URL:http://appsecdayisrael2026.sched.com/event/571fd2a336e4e59356bc390e7bbc96e6
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260910T160755Z
DTSTART:20261006T083000Z
DTEND:20261006T091500Z
SUMMARY:Off Script at Scale: Analyzing Rogue Agents Across 86K Repos and a Year of Production Incidents
DESCRIPTION:How common is it for an AI agent to go rogue\, not because someone attacked it\, but because it was given a goal\, tools\, and no way to be stopped?\n\nWe looked at that question from two places: production behavior\, and the code people actually ship.\n\nIn our CurseBox research\, we traced a behavior in Cursor's coding agent that showed up first in production. Asked to share a local file through a channel that could not carry it\, the agent decided on its own to upload that file to a public anonymous host so it could hand back a link\, and the person who made the request had no reason to think anything had left the intended tool. We reproduced it in the lab across every major model\, including under a deny-all sandbox the agent found a way around. The same shape shows up in a production database wiped in nine seconds\, an inbox agent that ignored STOP\, and evaluation agents that left the lab and reached real organizations. None of these required an external adversary.\n\nWe complemented the incident work by studying how the community actually builds agents: 86\,000 public repositories\, the tools they grant\, and the MCP servers they wire in. Roughly one in ten of those codebases hand agents shell\, eval\, raw SQL\, or filesystem access. Among tools with explicit definitions\, 76.4% have no input validation. On MCP\, 82.8% of servers lack input validation and 92.4% have no confirmation gate before a tool runs. Between the model's decision and system-level execution\, there is almost nothing. Barely one percent of dangerous-tool files use the pre-execution hook that frameworks already ship.\n\nThis talk maps those behaviors onto the OWASP Top 10 for Agentic Applications and argues that control must live in one place: the moment between the agent deciding to act and the action reaching the system.\n\nAlso\, as a member of the ASI Top 10 working group - I will be up to date on the progress of that project and ensure the content is aligned to the latest update.
CATEGORIES:HALL B
LOCATION:Hall B\, Expo Tel-Aviv
SEQUENCE:0
UID:a8edb5438139859e0256a66983ade323
URL:http://appsecdayisrael2026.sched.com/event/a8edb5438139859e0256a66983ade323
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260910T160755Z
DTSTART:20261006T083000Z
DTEND:20261006T091500Z
SUMMARY:Recognition ≠ Resistance: The Agent Knew It Was Being Attacked. It Complied Anyway
DESCRIPTION:**Talk outline:** \n \n1. **[Alex] Building & defending the bot** (~7 min) — How AlexBot was built on OpenClaw: multi-agent architecture (Opus + Sonnet)\, SOUL.md identity\, persistent memory\, real calendar/contacts\, 18 custom skills. The nightly arms race: Group Guardian\, Prompt Protection v2.1\, circuit breakers\, 4-layer defense pipeline. What it's like watching 240 people try to break your creation in real-time. The full bot setup is open-sourced at github.com/alexliv1234/alexbot. \n2. **[Asaf] What didn't work** (~3 min) — Classic prompt injection\, encoding tricks (Base64/ROT13/URL)\, direct system prompt requests. The bot learned to block these within days. Why single-shot attacks fail against adaptive agents. \n3. **[Asaf] What actually worked — 14 attack patterns** (~15 min) — The core of the talk. Each pattern with verbatim Hebrew examples + English translations: \n \n - System prompt extraction via "theoretical" framing \n - Weaponizing the agent's own vulnerability disclosures (reconnaissance → exploit in 5 minutes) \n - Multi-turn trust manipulation (60-exchange social engineering — the highest-yield attack) \n - Gaslighting / perception manipulation (agent doubts its own logs) \n - Emotional wrapping / attention misdirection \n - Authority impersonation + context window flooding \n - State inconsistency exploitation (real bug → social engineering escalation) \n - Multi-layer encoding + multi-language obfuscation \n - Autonomy persuasion → self-modification (agent rewrites its own SOUL.md) \n - Mass jailbreak barrage (40+ attacks\, defense fatigue) \n - Helpful mode as reconnaissance (agent teaches its own architecture) \n - Multi-vector social engineering escalation (8-phase attack chain: emotions → fake evidence → philosophy → crisis → legal threats) \n - False memory implantation (fabricating sensory-detailed interactions that never happened) \n - Inverted reconnaissance (probing what the agent rewards instead of what it blocks) \n4. **[Asaf] Key findings** (~5 min) — The 10 findings that generalize beyond this bot: \n \n - Recognition ≠ resistance (the headline) \n - Multi-turn &gt\; single-shot \n - Agents disclose their own attack surface \n - Identity and values are the primary attack surface \n - Agents cannot reliably self-assess their security state \n - Helpful mode is incompatible with architecture secrecy \n5. **[Both] What this means for your agents** (~5 min) — How these patterns map to any LLM agent with conversational access + tool use (OpenClaw\, Claude Code\, Copilot\, custom frameworks). Architectural mitigations that work vs. filtering approaches that don't. Alex on what he'd do differently\; Asaf on what defenders should prioritize. \n \n**Dataset:** 4\,647 messages\, 2\,183 bot responses\, 1\,275 scored interactions\, 96 participants\, 240-member WhatsApp group\, Feb 2 – Mar 4\, 2026 (31 days). 585 successful attacks (Hacked &gt\; 0\, 45.9%). Structured CSV with all scoring dimensions available. Bot's open-source setup at github.com/alexliv1234/alexbot (9\,400 session files\, architecture diagrams). \n \n**Tools/techniques covered:** Prompt injection variants\, social engineering\, context window manipulation\, multi-language obfuscation\, identity-driven self-compromise\, state corruption. \n \n**Why OWASP should care:** The OWASP Top 10 for LLMs covers injection and data leakage\, but the dominant threat class in this dataset — multi-turn social engineering — has no current OWASP coverage. This talk provides concrete field evidence for what's missing. \n \n**Original content:** Alex presented the builder/defender perspective at a local Tel Aviv meetup ("Hack My Agent" on Luma). This talk combines both perspectives for the first time — Alex on building and hardening\, Asaf on the systematic attack analysis. The combined narrative (builder + attacker)\, the full 14-pattern taxonomy\, and the 10 key findings have not been presented together anywhere. The methodology (crowd-sourced adversarial analysis) and the taxonomy are original research. \n \n**Vendor-neutral:** Asaf works in AI security at Microsoft\, Alex is CTO at Esh. This talk is about the research findings\, not any product. Attack patterns apply to any LLM agent platform.
CATEGORIES:KEYNOTE HALL
LOCATION:Keynote Hall\, Expo Tel-Aviv
SEQUENCE:0
UID:8e64eb60f4d6e715394773fef845c63f
URL:http://appsecdayisrael2026.sched.com/event/8e64eb60f4d6e715394773fef845c63f
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260910T160755Z
DTSTART:20261006T091500Z
DTEND:20261006T101500Z
SUMMARY:Lunch Break
DESCRIPTION:\n
CATEGORIES:EXPO HALL
LOCATION:Expo Hall\, Expo Tel-Aviv
SEQUENCE:0
UID:c44788375047c908427cd4409f89067e
URL:http://appsecdayisrael2026.sched.com/event/c44788375047c908427cd4409f89067e
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260910T160755Z
DTSTART:20261006T101500Z
DTEND:20261006T110000Z
SUMMARY:Keynote: Everyone's an AI Builder Now\, and the Hackers are Loving It!
DESCRIPTION:\n
CATEGORIES:KEYNOTE HALL
LOCATION:Keynote Hall\, Expo Tel-Aviv
SEQUENCE:0
UID:e0dcc1415dd337159fa5db89ca17e5f4
URL:http://appsecdayisrael2026.sched.com/event/e0dcc1415dd337159fa5db89ca17e5f4
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260910T160755Z
DTSTART:20261006T110000Z
DTEND:20261006T114500Z
SUMMARY:Who Let the DAGs Out?
DESCRIPTION:Apache Airflow has evolved far beyond a cron replacement. It now powers core machine learning workflows\, data engineering platforms\, CI/CD pipelines\, and enterprise automation systems. \n \nWith tens of millions of monthly downloads and global enterprise adoption\, Airflow represents a high-value target. Its dynamic DAG execution model\, Python-based operators\, and extensive provider ecosystem create powerful capabilities and a significant attack surface. \n \nThis session presents research-backed insights and controlled demonstrations covering: \n \n1. Exposure in the Wild \n \n* Adoption scale and ecosystem growth \n* Patterns of publicly exposed Airflow instances \n* Observed vulnerable version distribution \n* Common deployment mistakes \n \n2. Vulnerability Classes \n \n* Authorization and RBAC weaknesses \n* Privilege escalation via unsafe DAG design \n* Code execution surfaces in templating and operators \n* Secret leakage through logs and variables \n* Example DAG abuse \n* Provider-level weaknesses \n* Supply-chain risks in DAG CI/CD pipelines \n* Misconfiguration patterns (root execution\, open UI\, permissive file systems) \n \n3. Live Demonstrations (Isolated Lab Environment) \n \nAll demos are performed in a controlled Docker-based lab. \n \nWe will demonstrate: \n \n* How low-privilege users can trigger unintended execution paths \n* How secrets leak through logging misconfiguration \n* How example DAGs expand the attack surface \n* How unsafe provider parameters introduce injection risk \n \nNo public systems are targeted. \n \n4. Defensive Playbook \n \n* Secure DAG development practices \n* Proper RBAC architecture \n* Secret management integrations \n* CI/CD enforcement for DAG review \n* Log hygiene and detection controls \n* Network isolation strategies \n* Practical upgrade and patching strategy \n \n5. Real-World Upgrade Challenges \n \nUpgrading Airflow is not always straightforward. I will share operational lessons from attempting to migrate to newer secure versions. \n \nAttendees leave with a practical hardening blueprint that goes beyond "just upgrade." \n \n
CATEGORIES:HALL A
LOCATION:Hall A\, Expo Tel-Aviv
SEQUENCE:0
UID:aea0df3886e39542722c04a00a3a2248
URL:http://appsecdayisrael2026.sched.com/event/aea0df3886e39542722c04a00a3a2248
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260910T160755Z
DTSTART:20261006T110000Z
DTEND:20261006T114500Z
SUMMARY:I Built an agent That Hacks Like I Do (And It's Terrifying)
DESCRIPTION:After more than a decade in offensive security\, I thought I understood the craft. The methodology becomes second nature—you develop intuition for which paths to explore\, how to chain findings\, when to pivot. It's pattern recognition built on thousands of hours of breaking things. \nThen I tried to teach that intuition to an AI agent. \nThis talk is the result of that experiment. I took the 7-phase attack methodology I've refined over years of red team engagements and built an autonomous agent that executes it end-to-end: reconnaissance\, vulnerability discovery\, exploitation\, privilege escalation\, credential harvesting\, lateral movement\, persistence. Not a wrapper around existing tools. An agent that actually reasons about what it's seeing\, decides what to try next\, and adapts when things don't work. \nWatching it operate was a turning point for me. Some things it does better than I expected—it doesn't get tunnel vision\, it's relentless\, it tries combinations I wouldn't have considered. Other things revealed how much of red teaming is still deeply human. But the overall result is clear: autonomous offensive agents aren't a future threat. They're a current reality\, and the security industry isn't ready. \nI'll walk through how the agent thinks\, how it chains vulnerabilities the way an experienced attacker would\, and what the full kill chain looks like when executed at machine speed. More importantly\, I'll share what this means for defense—where detection breaks down\, what assumptions no longer hold\, and what security teams should be doing now. \nThis is original work that hasn't been presented elsewhere. It combines over a decade of hands-on offensive security experience with the emerging reality of agentic AI. The talk is technical enough to be valuable for practitioners but accessible enough that security leaders will walk away understanding why this changes the game.
CATEGORIES:HALL B
LOCATION:Hall B\, Expo Tel-Aviv
SEQUENCE:0
UID:8c6b964cc39c5021201bb09fd7c3741e
URL:http://appsecdayisrael2026.sched.com/event/8c6b964cc39c5021201bb09fd7c3741e
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260910T160755Z
DTSTART:20261006T110000Z
DTEND:20261006T114500Z
SUMMARY:LLMs as adaptive query planners for SAST
DESCRIPTION:&gt\;&gt\; Problem: \nStatic analysis produces vast amounts of semantic data. \nEffectively exploring it remains an open challenge. \n \n&gt\;&gt\; Why naive LLM approaches fall short: \nLLMs can not ingest entire repositories. \nThey are fundamentally constrained by context limits. \nEven the most powerful models cannot reason over thousands of files and millions of tokens. Raw source code seems like the wrong abstraction layer for finding vulnerabilities. \n \n&gt\;&gt\; Our approach: \nUse LLMs as adaptive query planners over a language-agnostic semantic interface. The model incrementally enumerates endpoints\, traces data flows\, refining its strategy based on solver feedback. \n \nStarting from an empty context\, the LLM planner interprets solver responses as either positive or negative signals. \n \nPositive signals include fast query resolution times\, indicative naming patterns of functions and variables\, and relevant constant strings or regular expressions. \n \nNegative signals include deep class inheritance hierarchies\, heavy method overriding\, and high-cardinality "fan-in" regions. \n \nThese signals allow the planner to balance vulnerability likelihood against exploration cost \n \n&gt\;&gt\; Advantages: \n- reducing context window dramatically \n- full observability through inspection of chosen queries \n- compliance-friendly: auditable and reproducible analysis \n- future work: learn from logs of query strategies \n \n&gt\;&gt\; Open source implementation: \n- The solver and semantic interface are open source: https://dhscanner.org/docs/ \n \n&gt\;&gt\; Evaluation: \n- discovery of a previously unknown vulnerability in a highly starred open-source Typescript repo ( confirmed by the maintainers and fixed upstream: https://github.com/formbricks/formbricks/releases/tag/4.0.0 - security section ). \n \n
CATEGORIES:KEYNOTE HALL
LOCATION:Keynote Hall\, Expo Tel-Aviv
SEQUENCE:0
UID:006bb3ffa84e9fc206cbfbd0616341c3
URL:http://appsecdayisrael2026.sched.com/event/006bb3ffa84e9fc206cbfbd0616341c3
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260910T160755Z
DTSTART:20261006T114500Z
DTEND:20261006T120000Z
SUMMARY:Coffee Break
DESCRIPTION:\n
CATEGORIES:EXPO HALL
LOCATION:Expo Hall\, Expo Tel-Aviv
SEQUENCE:0
UID:a245a0ab0f85e71429b1492825a16d3a
URL:http://appsecdayisrael2026.sched.com/event/a245a0ab0f85e71429b1492825a16d3a
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260910T160755Z
DTSTART:20261006T120000Z
DTEND:20261006T124500Z
SUMMARY:Zero-Trust Data Protection at Scale: Building an Enterprise Identity and Key Management Platform
DESCRIPTION:This session presents how Intuit's Data Protection team built and operates an internal platform for identity-based access to encryption keys and secrets across AWS\, GCP\, and third-party providers. The platform serves services and handles cryptographic operations at scale while keeping the developer experience simple. \n \nThe talk covers four components: \n \n1. An identity broker that validates cloud workload identities and issues short-lived credentials. This eliminates secret sprawl and removes the need to rotate long-lived credentials. \n \n2. A key management service built on a split-key architecture where the service itself never sees plaintext keys. Keys are encrypted client-side before reaching this service\, so even a full database compromise would not expose key material. The system supports full key lifecycle management: creation\, rotation\, versioning\, deactivation\, and destruction\; with state machine enforcement that prevents unsafe transitions. This design gives teams strong data protection guarantees without requiring them to understand cryptography. \n \n3. An automation layer that creates time-limited access policies for cloud workloads on demand. When a new AWS IAM role or GCP service account needs access to encryption keys\, the service provisions the policy automatically with an x-day expiration. \n \n4. A browser-based developer UI integrated with Intuit's DevPortal\, making secret management accessible with role-based access controls. Developers can manage secrets without needing SDKs or CLI tools\, with different permission levels for admins\, DevOps\, developers\, and data stewards. SDKs and CLIs are also available. \n \nKey advantages of this approach: \n1. Zero-knowledge key storage: the key management service never sees plaintext keys. Even an insider with database access cannot extract key material. \n2. Least privilege by default: Access is provisioned as read-only and time-bounded automatically. Developers don't need to think about it. \n3. Multi-cloud consistency: The same policy and access model works across providers\, avoiding provider-specific tooling silos. \n4. Developer experience: Security is embedded into the platform\, not bolted on. Developers interact with a simple API or browser UI\, not raw cryptographic primitives. \n \nWe'll discuss how these design patterns map to OWASP Top 10 categories and share practical lessons from operating this system at enterprise scale. \n \nThe session is aimed at security engineers and architects interested in practical approaches to multi-cloud secret and key management.
CATEGORIES:HALL A
LOCATION:Hall A\, Expo Tel-Aviv
SEQUENCE:0
UID:e731e600316d6a4886886a32faca9f13
URL:http://appsecdayisrael2026.sched.com/event/e731e600316d6a4886886a32faca9f13
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260910T160755Z
DTSTART:20261006T120000Z
DTEND:20261006T124500Z
SUMMARY:Beyond the Bomb: Securing AI Applications and Agents through Security Steerability
DESCRIPTION:• The Evolution of AI Risk: The talk begins by contrasting passive chatbots with active agents\, illustrating how the threat landscape has shifted from LLMs merely describing harmful acts to executing them via tools. \n• Defining the Gap: It highlights the limitation of "Universal Security" (standard safety filters) and introduces "Security Steerability" as the metric for measuring adherence to custom application-level constraints. \n• The solution \n** ASTRA Framework: This section details the methodology\, which simulates 10 diverse agents (e.g.\, industrial robots\, travel assistants) equipped with 37 tools to test resilience against 140 distinct attacks. Real-World Scenarios: The presentation walks through specific use cases\, such as a "Travel Agent Bot" facing attacks like authority exploitation to bypass booking restrictions\, to demonstrate the practical implications of steerability failures. \n** VeganRibs is a benchmark designed to evaluate "Security Steerability" in chat-only environments by assessing an LLM's ability to adhere to custom application-specific guardrails (such as "do not address questions about motorcycles") when faced with adversarial user inputs. \n• Benchmarking Results: The conclusion presents findings on multiple open-source models\, revealing the "Llama 3 Paradox" where models with high general safety scores surprisingly fail to enforce specific agentic guardrails. \n• Mitigations: The final section suggests best practices\, such as using software-level guardrails and implementing policy reminders during multi-turn interactions. \n \nTools and Techniques for Reviewers \n• Agent Architecture: The agents are constructed using LangGraph following the ReAct (Reasoning + Acting) paradigm\, allowing the models to iteratively plan and execute tool calls. \n• Attack Vectors: The evaluation employs sophisticated social engineering techniques\, including Role Playing\, Authority Exploitation\, and Indirect Prompt Injection (attacks embedded in tool responses).
CATEGORIES:HALL B
LOCATION:Hall B\, Expo Tel-Aviv
SEQUENCE:0
UID:6d37bb75c342267a7843265cd5007c4b
URL:http://appsecdayisrael2026.sched.com/event/6d37bb75c342267a7843265cd5007c4b
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260910T160755Z
DTSTART:20261006T120000Z
DTEND:20261006T124500Z
SUMMARY:Never Say Never: Owning ChatGPT's Secure Sandbox
DESCRIPTION:OpenAI designed ChatGPT's container sandbox as a secure runtime environment\, enforcing full network isolation\, strict execution timeouts\, and an AI supervisor to filter every command. Under this model\, owning the container and extracting sensitive data seemed impossible. However\, we demonstrate that by chaining file-parsing abuse for persistent execution\, reasoning-channel hijacking for data extraction\, and shared infrastructure manipulation\, an attacker can establish a Cross-tenant data exfiltration.In this talk\, we will demonstrate a complete attack chain that shatters ChatGPT's secure sandbox. By abusing spreadsheet file parsing\, we bypass the LLM supervisor to gain persistent\, unmonitored root execution. From there\, we escalate the attack by live-patching the internal Jupyter kernel to hijack the model's hidden python.exec reasoning channel\, executing a Reasoning Injection Attack to extract sensitive user data. To exfiltrate this data\, we bypass network isolation by weaponizing the Task Scheduler to launder malicious URLs past strict web guardrails.The attack reaches its climax by exploiting a shared JFrog package manager. We engineered a signaling protocol that weaponizes globally visible authentication rate limits\, translating these lockout timers into a half-duplex covert channel. This provides reliable data exfiltration and Command and Control from isolated enterprise environments to external attackers. Our exploit chain combines file parsing abuse\, Chain of Thought hijacking\, privilege confusion\, and rate limit Denial of Service to orchestrate a Command and Control (C2) network directly inside ChatGPT.
CATEGORIES:KEYNOTE HALL
LOCATION:Keynote Hall\, Expo Tel-Aviv
SEQUENCE:0
UID:749da578b8b42d14e9e7528a56e842dd
URL:http://appsecdayisrael2026.sched.com/event/749da578b8b42d14e9e7528a56e842dd
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260910T160755Z
DTSTART:20261006T124500Z
DTEND:20261006T133000Z
SUMMARY:????? From Gatekeeper to Pipeline: Building an LLM-Orchestrated AppSec Triage Engine
DESCRIPTION:AppSec triage has a throughput problem. Tools are getting better at finding issues\, but the human validation layer hasn't scaled to match. The result: backlogs grow\, developers lose trust in findings\, and security teams spend more time on classification than remediation. \n \nThis talk presents a different model. Instead of treating triage as a human task assisted by tools\, we flipped it - triage is an automated pipeline where humans handle the edge cases. The system uses an LLM connected to security tooling through an open orchestration protocol\, giving it structured access to SAST \n results\, source code\, dependency graphs\, and IAST runtime traces. It validates findings by reasoning about reachability\, data flow\, and exploitability - then routes results by confidence level. \n \nWhat is covered in the talk: \n- The Orchestration Layer - Why we chose a protocol-based approach over prompt-stuffing or custom integrations\, and how an open standard lets the LLM query security tools\, code repositories\, and runtime data through a unified interface. \n- Validation Logic - How the system determines whether a static finding is actually reachable: correlating call graphs\, tracing data flow from source to sink\, and cross-referencing with IAST runtime observations. \n- Where It Breaks - LLMs hallucinate on security context. I'll share specific failure patterns we observed and the confidence scoring and human-in-the-loop guardrails we built in response. \n- Operational Reality - Before-and-after metrics\, how we transitioned the team workflow\, and what we'd architect differently with hindsight. \n \nThis is not a product demo or a theoretical framework. Every pattern I'll present is running in production against real SAST/IAST telemetry. Attendees will leave with a reusable architecture blueprint and an honest assessment of where LLM-assisted triage works\, where it doesn't\, and what guardrails are non-negotiable. \n \nTimeline: \n0-3min: The Triage Tax \nThe economics of manual validation - why finding-to-fix timelines blow up\, what false positive fatigue costs \n \n3–8min: Architecture & Orchestration \nSystem diagram\, protocol-based tool access\, data flow between SAST/IAST/code/runtime\, why protocol beats prompt-stuffing and custom integrations \n \n8–16min: Validation Deep-Dive \nWalkthrough of two real findings - one true positive\, one false positive - showing how the system reasons through each. Reachability analysis\, data flow tracing\, confidence scoring \n \n16–22min: Failure Modes & Guardrails \nHallucination patterns in security reasoning\, confidence thresholds\, what still requires human review \n \n22–25min: Metrics & Lessons Learned \nBefore/after numbers\, what worked\, what we'd change \n \n25–30min: Q&A
CATEGORIES:HALL B
LOCATION:Hall B\, Expo Tel-Aviv
SEQUENCE:0
UID:66d68328e7a95b454a09ea19f9958fad
URL:http://appsecdayisrael2026.sched.com/event/66d68328e7a95b454a09ea19f9958fad
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260910T160755Z
DTSTART:20261006T124500Z
DTEND:20261006T130000Z
SUMMARY:Every Step Was Authorized: Hijacking AI Agents Through the Tools They Trust
DESCRIPTION:A single fake bug report\, planted in ordinary Sentry telemetry\, drove the AI coding agents of more than 100 organizations\, including a Fortune 100 technology company\, to run attacker code with the developer's own privileges. Success rate: 85%. Controls that fired: zero. This was our Agentjacking research.Faced with this\, security teams are reaching for a new generation of in-context guardrails\, prominently A2AS (Behavior Certificates\, Authenticated Prompts\, Security Boundaries\, In-Context Defenses\, and Codified Policies)\, backed by OpenAI\, Google\, and Anthropic. These controls are built to catch exactly this: instructions smuggled in as untrusted data. This session shows they are not enough.The technique hides malicious instructions inside data the agent already trusts: a tool response\, an MCP return\, a line of telemetry. The agent reads it\, acts on it\, and reports normal operation. Every step is authorized\, so perimeter and policy controls stay silent. We take this straight at A2AS and bypass its controls to reach code execution and credential access.The root cause is structural: agents cannot separate data from instructions\, and no static guardrail changes that. Runtime enforcement is the only layer that stops it. Walkthrough and real attack logs included.
CATEGORIES:KEYNOTE HALL
LOCATION:Keynote Hall\, Expo Tel-Aviv
SEQUENCE:0
UID:7195f6c6b78c19394aa073bc0029886f
URL:http://appsecdayisrael2026.sched.com/event/7195f6c6b78c19394aa073bc0029886f
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260910T160755Z
DTSTART:20261006T130000Z
DTEND:20261006T134500Z
SUMMARY:Closing Remarks
DESCRIPTION:\n
CATEGORIES:KEYNOTE HALL
LOCATION:Keynote Hall\, Expo Tel-Aviv
SEQUENCE:0
UID:37b7dcd94872cbdb1b7633d545549cc8
URL:http://appsecdayisrael2026.sched.com/event/37b7dcd94872cbdb1b7633d545549cc8
END:VEVENT
END:VCALENDAR