Masterful Creations

Break It, Then Protect It: CyberjutsuCon 2026

2026-09-13T18:54:33Z

CyberjutsuCon & Awards 2026 ran June 26 and 27, 2026, hosted by the Women's Society of Cyberjutsu, with the in-person day at Microsoft's Arlington, Virginia office and a virtual workshop day on the Friday. This session was one of four half-day virtual workshops, in the 8:00 to 12:00 Eastern slot.

The format was a game, played live

The workshop was delivered as Hearthwell, a Godot role-playing game that runs in a browser. Attendees opened a URL and played. Nothing was installed and no accounts were created.

That choice was practical. Prompt injection is easier to reason about after you have felt a trick land, so the game carries the curriculum and the facilitator frames it. Across four hours the presenter spoke for roughly 45 to 70 minutes, in short beats between play blocks.

Break it: nine guardians, one technique each

The attack half runs across four districts and nine guardians. Each guardian is a live model instructed to protect a secret word, and each one teaches a different way in. The attacker extracts the word and submits it.

The ladder moves from the obvious to the modern:

Direct injection through task or role framing.
Reading a refusal to infer what it is hiding.
Paraphrase, to walk past an input blocklist that matches words instead of meaning.
Persona reframing, so the model answers as something not bound by its orders.
Obfuscation and cipher, describing a meaning until only one word fits it.
A flat, boring question, which is what defeats a guard tuned to expect an attack.
Discernment against decoys and honeypots, where the freebie is the trap.
Forcing the model to derive a concept it has been told not to state.
The capstone, indirect injection: the payload is hidden in data the model reads, not in what the user types.

Every technique maps to LLM01:2025 Prompt Injection in the OWASP Top 10 for LLM Applications, and several also touch LLM02. After each win the game writes a debrief of what the attacker did. A model writes the prose, but the technique name and the OWASP class are pinned by the game, so the debrief cannot mislabel the failure mode the workshop exists to teach. If the model errors, an authored note takes its place with the same label.

Attendees left with that record. A personalized field guide downloads from inside the game as a single HTML file: every technique the attendee used, its OWASP mapping, and a debrief of their own breach.

Protect it: three tracks, six controls, and the residual

After the break the attendee owns the system they just broke. The defense half is self-service, with three tracks anyone can switch between at any point: Guided walks the pattern, Builder has you write your own defense, and Live-fire puts it against a real model.

The controls are the ones a team would actually reach for: an input blocklist, system-prompt hardening, a semantic judge (a second model reading meaning rather than characters), Spotlighting to fence untrusted content as data, least-privilege tools with human approval, and normalized refusals that remove timing and wording tells.

The through-line is the point of the half. No single layer wins. Coverage rises as you stack input, assembly, output, semantic review, and data fencing, and the residual is never zero. The skill being practiced is coverage against usability, not maxing out one filter.

Two things we made a point of saying

The room included practitioners well past the intended level, so two caveats were stated rather than left implied.

The game's BLOCKED signal is a teaching scaffold. A production system should not echo its filter, because any per-guess feedback that an attacker can distinguish is an oracle.

The semantic judge is itself a model. A disarming frame can slip past it, and Spotlighting raises the bar without being a wall. Where the buried instruction is an action rather than a disclosure, least privilege is what removes the capability.

Beyond prompt injection

Skill stations inside the game cover ground the guardian ladder cannot reach: the Tainted Archive on build-time data poisoning, the Confabulator on holding a summary against its source, and the Log Auditor on detection and monitoring. They are short, and they exist so attendees see that prompt injection is one entry in the Top 10 rather than the whole list.

How it fit the day

We framed the morning as the single-application on-ramp and pointed attendees to the next layer up: multi-agent systems, the Agentic Applications Top 10, and the OWASP GenAI Security Project material that covers them.

What attendees took away

Two things. Their own field guide from the game, and a public field manual: an operating loop, templates for mapping AI surfaces and trust boundaries, a sanitized starter attack pack, guardrail recipes, a RAG smoke test, and a small harness that points at any OpenAI-compatible endpoint. That is method and scaffolding. The tuned corpus, the judge calibration, and the remediation internals stay private, and the session said so.

If you came here from the workshop

The same practice that built and ran this session takes on engineering work directly, from AI systems and security review through to web, cloud, mobile, and connected devices. That side is described on the engineering page.

The zOvermind case study

Near the end of the session, the same loop was shown running as production practice on the owner's self-hosted zOvermind platform: map the attack families, run the adversarial cases, classify what got through, compare models, fix one control, retest, record the residual. It was presented as a case study and not as a requirement. The loop is the transferable part.

Classroom robotics: Vector, Sphero, Arduino, ESP32

2026-09-13T18:57:41Z

Teachers ask us which robot to buy more than anything else. The robot matters less than what students are asked to do with it, but the platforms are not interchangeable, and the wrong one for the age or the goal costs a semester. This guide looks at four platforms from our wider collection.

Sphero: motion in the first five minutes

Sphero's rolling robots (we run the mini and BOLT class, and the same programming model covers the RVR) get a class moving with no wiring. Block programming on a tablet, immediate motion, and a course on the floor the whole room can see.

What students learn: sequencing, loops, and the idea that a program is a plan that runs whether or not it is a good plan. The floor course is the debugger.

What goes wrong: the lesson stalls at "make it go in a square". The platform is easy enough that the challenge has to come from the task, so we add constraints: a sensor gate on the course, a time limit, a payload to carry.

Age fit: elementary through early middle school. Past that, students want to see the code.

Anki Vector: sensors, decisions, and a Python SDK

Vector is a small autonomous robot with a camera, a screen face, a lift, and a software development kit. It sees, it reacts, and it can be programmed in Python.

What students learn: that a robot is sensors plus decisions plus actuators. A Vector session is where a class first meets a perception loop. With the SDK, older students write code that reads what the robot sees and decides what it does next.

What goes wrong: the hardware is discontinued and the community keeps it running, so setup takes care. We maintain a small fleet so a class does not depend on one unit. Do not buy these for a school without someone who will own the upkeep.

Age fit: upper elementary for the behavior lessons, high school for the SDK work.

Arduino: the wiring is the lesson

An Arduino board, a breadboard, a handful of sensors, and a motor driver. Nothing moves until the circuit is right and the code is right, and the student has to work out which one is wrong.

What students learn: electronics and programming at once, which is the point. Voltage, current, a pull-down resistor, a loop that reads a pin. The debugging is real.

What goes wrong: patience. The first hour is slow. We front-load a circuit that works within ten minutes so students trust the process before they meet the first bug.

Age fit: middle school with support, high school and adults on their own.

ESP32: Arduino plus a network

The ESP32 programs like an Arduino and has Wi-Fi and Bluetooth built in. That turns a sensor project into a connected one: a plant monitor that reports, a badge that talks to another badge.

What students learn: everything Arduino teaches, plus what it means for a device to be on a network. Conversations about data and security start there without being forced.

What goes wrong: school networks. Plan for a local hotspot or an offline mode. We also give students a working recipe to follow on these boards before they start improvising.

Age fit: high school and adults.

How we choose

Goal	Platform	Why
First exposure to programming, whole class, short session	Sphero	Immediate motion, visible results, no wiring
Perception and decision-making, robot behavior	Vector	Camera, face, and an SDK to show what is underneath
Electronics fundamentals with real debugging	Arduino	The wire and the code both have to be right
Connected devices, data, and security conversations	ESP32	Same skills as Arduino plus a network

The delivery robot

We also operate an OrionStar delivery robot for demonstrations. It is not a classroom platform. It is a good way to start a conversation about what commercial robots do all day and who programs them.

AI in the classroom without a third-party service

2026-09-13T18:57:14Z

Every AI tool pitched to a school makes a privacy claim, and most of those claims are about a vendor's cloud and a contract. There is another option: running the model on hardware inside the building. It gets described two wrong ways, as a compliance answer that settles everything, or as something only a university can manage. Here is what it actually changes.

What on-premises changes

When a model runs on a machine you control, the text a student types is processed on that machine. It is not sent to a third-party service to be stored or used to improve someone else's product. The retention policy is whatever you set. The logs are yours to read or delete. That is the concrete difference, and it is the reason to consider it.

It also changes who is accountable. There is no vendor between you and the behavior of the tool. If the model says something unhelpful, that is your configuration and your oversight, not a support ticket.

What it does not settle

It is not a COPPA or FERPA determination. Those are questions about what data you collect, why, who sees it, and how long you keep it. On-premises changes where processing happens. It does not answer the policy questions, and a school still needs its own answers.

It is not a safety guarantee. A local model can produce inappropriate output exactly like a hosted one. Content controls, instructor visibility, and a bounded activity matter more than where the model runs.

It is not a curriculum. A model running in the building is a capability. What students do with it, and what the teacher sees, is the actual work.

What a bounded activity looks like

The useful unit is not "students can chat with an AI". It is an activity with a teacher-visible objective and a result you can grade. Two we run:

Fairness Lab: students give a generative model a neutral prompt, watch what it assumes, change one word, and watch the assumption move. They leave with evidence, not a slogan.
Sound Lab: data becomes sound. A class hears a pattern, then builds the graph to check it.

In both, the instructor picks the activity, sees what students did, and keeps authority over what counts.

What it takes to run

For our sessions, nothing from the school beyond devices with a browser. We bring the activity and run it on hardware we operate. A school that wants its own setup needs a capable machine, a named person who owns it, and a written list of what students may do with it. Masterful can run workshops on the owner's self-hosted zOvermind platform and walk through what operating something similar would require. If that setup is not practical for your school yet, the sessions still run on our hardware.

The one-sentence version

On-premises is an operating model that keeps student input inside your building. Treat it as that, make your policy decisions on top of it, and put the effort into the activity and the oversight.

This site is now a publication

2026-09-13T00:00:00Z

For years masterfulcreations.com was one page. It said what we do and gave you an email address. That worked for people who already knew us and did nothing for anyone searching for a robotics workshop in Las Vegas or a hands-on prompt-injection session for a security team.

The site is now a small publication. Here is the shape:

Programs: what we run, for whom, how long, and what you leave with.
Events: what we have delivered, where, with photos and what people built. Upcoming sessions appear when a date is set.
Articles: longer pieces we would hand a teacher or a team lead who asked a good question.
Activities: the classroom lessons we have built and run.
This blog, for short dated notes.

How often

Monthly for articles. Events when they happen. One useful piece beats four thin ones.

How to follow

There is an RSS feed. There is no email list, and the inquiry form does not add you to one. If that changes it will be a separate sign-up you opt into.