We accept 20-minute technical talks only. No panels, no fireside chats, no "state of the industry" keynotes. Twenty minutes is enough to show something real, and short enough that you can't hide behind filler.

Every accepted talk must include original work. That means: a live demo, a proof of concept, a novel tool, original research findings, or a technical post-mortem. If your talk could be delivered by someone who read the blog post instead of doing the work, it won't make the cut. Show, don't tell.

Topics

We're interested in talks that advance the practice of AI security. Priority areas include, but aren't limited to:

• Adversarial ML: new attack vectors, novel defenses, and real-world exploitation of production AI systems
• AI red teaming: methodology, tooling, and findings from systematic adversarial testing
• LLM security: prompt injection, jailbreaking, data extraction, and defenses that actually work at scale
• Model integrity and supply chain security: weight poisoning, fine-tuning risks, trust boundaries for shared and open models
• Secure AI development: architectures, patterns, and tooling for building security into AI systems from day one
• AI in regulated environments: making compliance auditable and engineering-friendly -- EU AI Act, sector-specific frameworks, and the tooling that bridges policy and practice
• Defensive tooling: open-source or commercial tools that practitioners can put to work immediately
• Failure stories: what went wrong, what you learned, and what you changed -- these are some of our most valued talks

If you're working on something at the bleeding edge that doesn't fit neatly into these categories, submit it anyway. We leave room for the unexpected.

What we don't want

• Product pitches or vendor demos disguised as technical talks
• High-level overviews of the AI threat landscape (the audience already knows)
• Talks without a demo, proof of concept, or original findings
• Content that has already been presented at other conferences without significant new material
• Speculative talks about theoretical risks without concrete, technical substance

Level of expertise

Talks should target a technically experienced audience. Assume attendees have working knowledge of machine learning, software security, and current AI deployment patterns. You don't need to explain what an LLM is... Get to the interesting part.

Target audience

The Practitioner Track audience includes: security engineers, ML engineers, AI red teamers, application security leads, DevSecOps engineers, and security researchers actively working on AI systems. These are people who build, break, and defend AI in production. They're here to learn something they can apply.

Selection criteria

Proposals are evaluated on:

• Originality: Is this new work, a new perspective, or a new finding?
• Technical depth: Does the talk go beyond surface-level discussion?
• Demonstrability: Can you show it, not just describe it?
• Practical value: Will an attendee leave with something they can use?
• Clarity: Is the proposal well-written and specific about what the audience will learn?

We reject more proposals than we accept. A strong proposal is specific: it tells us exactly what you'll demo, what the audience will learn, and why it matters now.