Build Your Own Security Awareness Training With AI | Breacher.ai
Awareness Training Is Always Behind. So We Built the Way Out.
Security is not a category. It is your organization, your policies, your approval chains, the script your help desk actually reads from. We built OSES™ Behave so the team that owns the risk can build the curriculum that matches it, generate the training and the simulation together in minutes, or import the content they already own.
We built an application that generates security awareness training and the simulation that tests it, on demand.
Point it at your own policy documents and it generates from those, in your terminology, naming your systems and your escalation paths. Point it at the failures a simulation just recorded and it generates against those, scoped to the exact step that did not hold. Start from a blank objective and author the module yourself. Or import the curriculum you already own and run it on the same rails. That is OSES™ Behave, and this is the argument it was built out of.
We did not build it because content generation was an interesting engineering problem. We built it because we spend our working weeks running orchestrated social engineering simulations against enterprise organizations, and we kept arriving at the same moment. A simulation would surface something precise. A specific verification step, in a specific function, skipped under a specific kind of pressure. And then the remediation would be a module from a catalog, written eighteen months earlier, for nobody in particular.
That gap is not a vendor failing. It is a structural property of the catalog model, and it cannot be fixed by producing better catalogs.
The Catch-Up Problem, Stated Properly
The usual complaint about awareness content is that it lags the threat. That is true and it is the less interesting half.
A library is authored months ahead of the moment anyone watches it. In that interval the adversary changes tooling, the pretexts that work best rotate, and the channel the request arrives on moves from email to a voice call to a video meeting. The vendor ships an update, eventually, and the update is again authored months ahead of the next moment. The lag is permanent because it is arithmetic, not effort.
The half that gets less attention is worse. Even a catalog that is perfectly current with respect to the threat landscape is not current with respect to you. It was written for a general audience. It does not know that your wire approvals run through a shared mailbox, that your help desk verifies callers on a manager name and a device model, that your vendor banking changes are handled by two people in accounts payable who are the busiest people in the building. It cannot know. It was written before anyone measured any of it.
So the question we set out to answer was not how to produce awareness content faster. It was how to move authorship to the only people who can close the second gap, which is the security team that already knows how the organization works and already has the documents that say how it is supposed to work.
What We Built
An application that treats your policies, your procedures, your processes, and your own engagement data as the source material, and treats content production as the cheap part it has become.
Import is a first-class path, not a migration tool. If you already own content that works, it runs on the same rails as anything generated, inherits the same assignment logic, and shows up in the same re-test. We are not asking anyone to throw away a program that took three years to get funded.
Five Principles
These are the decisions the product is made of. They are also the decisions we would defend if the product did not exist.
Security is not a category. It is your organization.
There is no such thing as a generically correct verification procedure, because there is no such thing as a generic approval chain. Curriculum has to be generated from the documents that describe how a specific organization is supposed to operate, and it has to come back naming that organization's systems, roles, and escalation paths. Anything less specific is a lesson about somebody else.
The team that owns the risk owns the curriculum.
Security teams should not be filing content requests with a vendor and waiting a quarter. Generate a module, author one from a blank objective, or import what you already have. The platform is a tool. It does not get to be the owner of your program, and it does not get to decide what your people are taught about your own processes.
The training and the simulation come from one source.
Generating a module in minutes is unremarkable on its own. Generating the module and the scenario that tests it from the same policy text and the same engagement dataset is the part that changes the outcome, because the thing being taught and the thing being measured cannot drift apart. When the simulation tool and the training catalog come from different vendors, drift is the default state and nobody notices for a year.
Generate against the control that failed.
The module a person receives should be the procedure they did not follow, not the pretext that exposed it. A simulation obtains a vendor banking-detail change using a cloned executive voice, and the tempting module is about voice cloning. The correct module is about the out-of-band callback your policy already requires on banking changes. One of those degrades every time generation quality improves. The other returns the same result whether the caller was synthetic, human, or a genuinely confused vendor.
Nothing counts until the re-test.
Assign the module, then run the same control against the same population again and report the movement. Without that second reading, everything upstream produces a faster, better targeted, entirely unverified intervention. Completion is a delivery record. It has never been evidence that a behavior changed, and treating it as evidence is how programs stay funded for years without moving anything.
What We Refused to Build
Describing what a product does is easy and it proves nothing. These are the three things we were repeatedly told to build and deliberately did not.
A faster content library. The obvious move with a generator is to generate a catalog, ship a thousand modules, and win the comparison table on module count. We are not doing that. The library problem was never that libraries were slow to produce, and a topic list is a topic list whether a human wrote it over eighteen months or a model wrote it over a weekend. Volume is the metric of a content business. We are not in the content business.
A per-person risk score for the board. Individual results are genuinely useful, and we use them, as a routing input that decides who gets assigned what. What we will not do is roll them into a number attached to a named human and put it in a leadership deck. A score on a person does not tell you whether the payment goes out. It does tell your people that reporting a mistake is expensive, which is the exact behavior you cannot afford to price.
Detection as the core of the curriculum. Teaching people to spot the artifact is a control whose effectiveness is set by the adversary's generation quality, and generation quality improves continuously while human perception does not. We are not saying detection material has no place. We are saying it cannot be the load-bearing element, because the load it bears gets heavier every quarter and nothing about the control gets stronger.
Measure the Right Thing
If you build your own curriculum you also inherit the responsibility for proving it did something. These are the questions the program should be able to answer at the end of a cycle, and the first one is the one that separates an owned program from a busy one.
The distinction between skipped and waived is the one most programs cannot make, and it is the one that matters most as synthetic media improves. A person who never attempted verification needs the procedure. A person who attempted it and then granted an exception because the caller was convincing needs an exception path that does not rest on their judgment under pressure. Those are different fixes. No generator can choose between them without the data, which is the whole reason the measurement stage exists.
The underlying argument, that verification holds where detection decays, is set out in our breakdown of AI spear vishing and IT support impersonation. The platform itself is documented under secure behavior management, and the module format under micro training modules.
What We Are Not Claiming
We publish the bounds on our own argument, because the alternative is having somebody else find them in front of a prospect.
We are not saying users do not matter. Every procedure in this model is executed by a person. We changed which human behavior gets measured, from perception to compliance under pressure, because compliance is trainable and observable in a way that perception is not. It is still a human variable and it always will be.
Procedural verification is not invincible. Better synthetic media does not defeat a callback requirement directly, but it does raise the pressure applied against it. A more convincing executive makes granting the exception feel more reasonable. What degrades as generation quality improves is not the control, it is the exception rate. We measure that, and we would rather publish a measurable bound than claim a perfect one.
Coverage is the real limit, not adherence. A procedural control only holds where a procedure exists. Most organizations have a defined verification requirement for outbound wire transfers and nothing at all for credential resets, vendor banking-detail changes, multi-factor enrollment, or a support request that arrives over Teams. Where there is no defined step, there is nothing to generate against, and the fastest generator on the market is useless. That gap is a control-design problem, and it has to be closed before it is a training problem.
Generation speed is a production win, not a security win. Minutes instead of weeks matters for exactly one reason: it makes just-in-time delivery possible, so a correction lands while the experience is recent. It does not tell you which procedure to point the module at. That decision is upstream of any generator and always will be.
Owning your curriculum assumes you can staff it. This argument is written for organizations with a security function that can run a program. Below that, an owned curriculum is a burden rather than an advantage, and managed delivery is the honest recommendation. We package it that way and we are not going to pretend otherwise here.
Where to Start This Week
Three things, in this order, none of which require buying anything from us.
List your consequential actions and mark which ones have a verification requirement. Outbound payment, vendor banking-detail change, credential reset, multi-factor enrollment or reset, privileged access grant, software installation on request, data export, physical access grant. For each, write down whether a defined verification step exists, whether it works regardless of which channel the request arrived on, and whether the person asked to perform it under time pressure can actually reach it. The blanks in that table are your real backlog, and filling them is a policy exercise before it is a training one.
Take the last three modules your program assigned and name what each was generated from. If the answer is a topic, a compliance date, or a vendor release note, you have a content schedule rather than a curriculum. If the answer names a specific procedure and a specific observed failure, you already have the loop, and the only remaining question is whether you closed it.
Then re-test one control. One verification step, the same population you trained, two readings you can put side by side. One control tested twice is worth more than a full curriculum delivered once, because it is the only version of this that produces a number you can defend.
Frequently Asked Questions
What is OSES Behave?
OSES Behave is the training stage of the Breacher.ai platform. It generates security awareness training modules and the simulations that test them, from three sources: an organization's own policy and procedure documents, the specific failures a simulation recorded, or a blank objective the security team authors against. Existing content can also be imported and run on the same rails. Modules are delivered by email or mobile, or packaged as SCORM into the learning management system already in place.
Can we build our own security awareness training instead of buying a library?
Yes, and that is the point of building the application this way. A security team can generate a module from a policy document, author one from a blank objective, or import curriculum it already owns. The people who understand the environment keep control of what gets taught, and the platform stays a tool rather than the owner of the program. This assumes an organization that can staff a program. Below that, managed delivery is the more honest answer and we say so.
Can AI generate the simulation as well as the training?
Yes, and generating both from the same source is the part that matters. A scenario described in plain language becomes a playbook with a goal, a persona, and a channel sequence across voice, video, email, SMS, and chat. Because the module and the scenario are generated from the same policy text and the same engagement dataset, the thing being taught and the thing being measured cannot drift apart, which is the failure mode when the simulation tool and the training catalog come from different vendors.
Can we import our existing awareness training content?
Yes. Content an organization already owns can be imported and assigned on the same rails as generated modules, which means it inherits the same assignment logic, the same completion tracking, and the same re-test mechanics. Most programs end up running a mix: the standing annual curriculum stays in place as the program of record, and generated modules sit on top of it as corrections for what the simulations actually found.
What should a generated training module be keyed to?
To the control that failed, not to the scenario that exposed it. If a simulation obtained a vendor banking-detail change using a cloned executive voice, the failed control is the out-of-band callback required on banking changes, not the existence of voice cloning. A module keyed to the scenario teaches people the story they were told. A module keyed to the control teaches the step they skipped, and that step returns the same result against the next scenario.
How do you prove the training worked?
By re-testing the same control against the same population and reporting the movement, not by reporting a completion rate. The measures worth carrying are coverage, meaning how many consequential actions have a verification requirement defined at all, whether verification was executed when it was required, how often it was consciously waived as an exception, and the elapsed time from request to verification. Completion records belong in the audit file.
Bring a Procedure. Watch the Module Get Built From It.
Thirty minutes. One real policy document, the training generated against it, the simulation that tests it, and exactly what the re-test would measure.
Book Your DemoLatest Posts
Table Of Contents
About the Author: Jason Thatcher
support@breacher.ai
