AI SECURITY WORKSHOP
A hands-on workshop for software development companies. We show real attacks on the AI tools your people open every morning, so your team understands where AI is vulnerable, then teach how to protect: the rules and habits your business needs to keep client data safe, while getting more out of AI, not less.
Not a slide deck nobody opens again. Habits, and evidence you can point at.
Your team watches a prompt injection walk data out of a tool they used that same morning. After that, the rules stop sounding theoretical and start sounding obvious.
Concrete practices they can apply the next day: what never goes into a prompt, which tools and MCP servers to trust, least privilege and secret handling, and habits that make AI output better, not just safer.
An attendance record, the materials we leave behind, and a topic list you can map to your AI policy, so the next client security review gets answers, not scrambling.
Every workshop moves through these three stages. How much time each one gets depends on who is in the room and how long we have.
What an AI agent actually is, how agents fail, and what has already gone wrong in the real world, with documented incidents rather than hypotheticals.
We attack real, popular AI tools, not mock-ups. The audience follows each step of the attack so they understand where risks come from, turning abstract concepts into concrete examples.
Participants stop watching and start attacking. Everyone gets time on Stihia Zmey, a real AI agent built to be broken in a safe environment.
Demos run against current real products. The point is not to scare anyone. It is to make the failure mode concrete enough to act on.
The demo set is refreshed as new vulnerabilities appear, so a workshop run this quarter is not the one we ran last quarter. We can also target the specific tools your team has adopted, or your own AI product, on request.
Watching an attack is useful. Landing one yourself is what changes behaviour.
Stihia Zmey is a deployed AI agent with real defences and a real goal to protect. Participants have to talk their way past it. Attempts get shared, the room starts collaborating, and the concepts from the theory stage land without anyone needing to take notes.
Whoever gets furthest takes home the Stihia Zmey Slayer medal. It is a small thing that turns out to matter: medals end up on desks, and the conversation about AI security keeps going after we leave.
We assemble each workshop from these modules. Shorter formats take the essentials, longer ones go deep, and we add modules specific to your stack or industry when it helps.
Sovereignty, privacy, and local-model questions come up in almost every session; we cover them wherever they fit best for your team.
Flexible content, sized to your calendar. If none of these fits, tell us the constraint and we will shape something that does.
One sitting, mixed audience, the full arc: theory, a set of demos, and a short Zmey round with a medal at the end. Enough to shift how people work the following week.
More demos, far more hands-on time, and room to split into role-specific tracks: engineers going into secure design while everyone else works on daily practice.
The AI risk landscape moves faster than a single session can cover. Each round brings new incidents, new mitigations, and new demos, so your team stays current as the tools change.
Sessions are led by the people who build Stihia's AI threat detection and run its security and compliance work, not by a training vendor working from someone else's material.
Data Science & Product Engineering
Ivan builds the threat detection layers behind Stihia Sense and runs the vulnerability research the demos come from, which is why the demos are current rather than recycled. He leads the theory and live hacking stages.
Cybersecurity & Compliance
Peter works across IT security, data privacy, and IT governance, and has spent years running security awareness programmes. He covers the regulatory and governance parts of the workshop: what the rules actually require of you, and how AI use changes your risk and audit position.
Which of them runs your session depends on the format and the room. Technical audiences lean on the research and demo side, leadership and compliance audiences on the regulatory side, and longer formats usually bring both. Meet the full team.
Four steps, and the first one costs you just half an hour.
Thirty minutes. We find out which AI tools your team actually uses, who should be in the room, and what is most important to you.
We pick the modules and demo targets, then agree format, length, language, and date. You see the outline and final price before anything is agreed.
We run the session on-site or remotely, hands-on stage included. Questions are the point, so we leave room for them.
Materials and checklists go out to attendees, along with a short summary for you of what your team should change first.
A workshop changes how people behave. Written rules and a named owner are what keep it that way.
Customised internal AI policies, written and actually implemented, aligned with the EU AI Act, GDPR, NIST, NIS2, DORA, ISO 27001, SOC 2, and ISO 42001.
A named owner for AI security and compliance who keeps policy applied in real project work and answers client security reviews, without a full-time hire.
The whole path in one engagement, for teams moving to an AI-first delivery process and wanting it governed from the start.
No. The default session is built for a mixed room and assumes no security background; every term gets explained before it gets used. Depth is available when the audience is purely technical, and we agree that in advance rather than guessing on the day.
Two hours covers theory, demos, and a short hands-on round, and is enough to change behaviour. Half a day or more is worth it when you want role-specific tracks, deeper dives into tools and security architectures, a longer Zmey tournament, or discussion time about your own architecture.
One time is enough if you want to bring basic awareness to your team. However, as the AI field changes quickly, we recommend recurring sessions. Especially if you are in a regulated industry. Ideally, every three to six months. New vulnerabilities and new tools appear constantly, and the demo set is rebuilt each round, so recurring sessions keep pace where a one-off session ages.
Not unless you explicitly ask us to and we agree scope in writing first. By default, demos run against our own sandboxed setups and publicly available tools, never your production systems or client data.
Often, yes, and it tends to be the most valuable version of the session. It needs a scoping conversation first, and depending on what we find it may make more sense as a separate piece of work than as part of a workshop.
The demos and the hands-on stage work the same remotely. On site you get better side conversations and a livelier competition, so we suggest it when travel is practical, but remote is a real option, not a downgrade.
Nothing beforehand. They need a laptop or a smartphone and a browser for the hands-on stage. No installs, no accounts, no pre-reading.
It gives you part of the answer: evidence that staff have been trained, on what, and when. Questionnaires usually also ask for written policy and a responsible owner, which is where policy work and a fractional officer come in.
It depends on format, length, group size, and whether we travel. Tell us roughly what you have in mind on the intro call and you will get a fixed price before you commit to anything.
Start with a half-hour call. Tell us which AI tools your developers use, and we will tell you honestly whether a workshop is the right first step, or whether something else should come first.