- The Meeple Problem - controls by action, not role
Quick recap. Stryker presented "The Meeple Problem," a talk on building security controls around what people actually do rather than around the role they hold. A meeple is the single-color wooden playing piece from board games like Carcassonne: one shape, one move, one thing it can ever do. That is a useful abstraction for a board game and a poor one for people, yet security programs routinely reduce an employee to a single variable, usually job title or seniority, and then treat that first draft as final. Drawing on the first volume of her AI Behavior Index at Fable Security, an older executive survey, and her own in-house phishing analysis, Stryker showed how often that variable fails to predict behavior: AI-enabled employees held their technical controls better and their volitional ones worse, role buckets varied so widely that the reported average concealed most of the signal, and seniority showed no correlation at all with who clicked a phishing link. The group pushed back throughout on what the data could and could not support, which was largely the point of the talk.
Show 11 discussion topics
The meeple problem
Stryker, Director of Threat Analysis at Fable Security, opened by defining the term for a room where only two people had played Carcassonne. Meeples are single-variable pieces: you see the color and the shape, and you assume that is everything the piece can do. Security teams reduce people the same way, whether the variable is what someone can access, how long they have been there, or how much friction they will generate if asked to do the secure thing. Role is a reasonable first draft when designing access controls. The problem, she argued, is that the first draft almost always becomes the final one. Assumptions and experience are genuinely valuable as a starting hypothesis, but acting on an untested hypothesis is arrogance.
Why role becomes the only variable
Stryker gave three reasons the shortcut persists. The first is organizational logic: in principle access follows function and controls follow access, so a role-level generalization looks defensible, as in "all developers handle production data, therefore all developers need the sensitive-data reminder." In practice they do not all have that access. The second is regulatory framing. NIST, GDPR, NYDFS and the state regimes in New York, Texas and California all describe role-based controls and role-based training, which quietly makes role the primary variable whenever something has to clear a compliance checkbox. The frameworks use role as a proxy for risk. The third is historical: for much of this field's short life, a list of people and their job titles was close to the only data available. That made role a sensible starting point then, and better telemetry exists now.
Four biases that keep the shortcut in place
She then walked through the biases she sees when consulting. Satisficing is doing just enough to clear the bar, which leaves the harder work permanently unstarted and turns a minimum viable program into a final one. Probability neglect is conflating impact with likelihood: CEO impersonation and fraudulent wire transfers feel most probable because they would be most devastating, when the marketer holding a ten thousand dollar corporate card is a likelier target. Shiny object syndrome is the appetite for a new control over an old fight, from practitioners and executives alike, when MFA, credential rotation and session token handling would address much of the exposure. Overconfidence bias is the one she tied most directly to the meeple problem: many practitioners came up through an IT help desk, saw the worst of one department at one company, and carry that microcosm forward as a general truth about the role.
AI enablement as a single variable
To test her own thesis, Stryker picked a single variable she expected to be predictive and looked at what it actually predicted. The data came from the first volume of Fable's AI Behavior Index, published that week, covering roughly 92 days from March 1 to May 30, 2026 across 32 customer environments and a starting population of about 290,000 people. She used each customer's own tuned telemetry rather than tuning detections herself, so the findings represent commonality across environments; populations shrink as more variables are applied, and she does not report on cohorts under 100. She asked the room to guess what share of employees were AI-enabled, meaning a license granted through the IDP or a detected model, browser extension or app on the endpoint. Guesses ran from 10 to 100 percent. The answer was 34 percent, which she found genuinely surprising.
The shadow AI gap
That 34 percent sits well below the roughly 50 percent of employees who tell surveys they use AI at work, and Stryker distrusts both numbers: executives inflate their answers even anonymously because they want the company to look further along than it is, and employees have their own reasons to under-report. Her explanation for the 16-point gap is AI features switched on inside software that already exists. About 91 percent of employees had at least one application advertising an AI feature; excluding workplace suites like Google Workspace and Microsoft 365 brought that to about 55 percent, almost exactly where the surveys land. Her prediction for the next nine to twelve months is that AI spend will increasingly hide inside already-approved vendors, because nobody wants to repeat procurement and a price increase draws no attention. Someone using Excel and someone using Excel with Copilot look identical unless you detect for it.
What changes inside the AI-enabled cohort
Comparing AI-enabled employees against the general baseline produced a pattern Stryker was careful to call correlation rather than causation. The harder technical controls looked better in that cohort, with fewer DLP alerts and better MFA enrollment; the volitional behaviors looked worse, including unsafe browsing and overdue compliance training. Tyler flagged the compliance training correlation as odd, and Stryker agreed it was strange rather than explaining it away. Micah asked how unsafe browsing was defined and whether the higher web traffic AI users generate was accounted for in the denominator. Stryker answered that unsafe browsing is whatever each customer's EDR is tuned to flag, that she cannot detect AI use directly and uses AI file upload rates as her proxy, and that she shares Micah's hypothesis but cannot confirm it. Her operational takeaway: a population with both high unsafe browsing and high AI file upload rates is exposed to indirect prompt injection, and those two signals usually live in separate platforms that nobody correlates.
Role buckets and the spread the average hides
Several attendees suggested the technical-control result was really about AI-forward people being more technical, so Stryker split the cohort into role buckets grouped by shared environmental pressure. Administration and governance were grouped together, for instance, because those people field unprompted external communication from regulators and carry paper and liability risk rather than cyber risk, an accumulation of assumptions she narrated out loud as she made them. The buckets also reached enough statistical mass to report on and obscured which customer any result came from. The spread across buckets around the same mean everyone had already been shown was very wide. Some roles did materially worse and some, finance among them, did notably better. Brian suggested finance were simply better at hiding it. Stryker called that a hypothesis rather than a finding and offered a competing one: finance is regulated, invested in, and required to take extended leave while the work is inspected. The grass is greener where we water it.
What executives admit to in surveys
Stryker also showed a large survey she ran at a previous employer a few years ago, with the standing caveat that a survey captures what people say rather than what they do. In the same instrument where 98 percent of executives said they supported security mandates, meaningful shares went on to admit accessing files they did not need for their job, clicking phishing links, and sending money in response to one. She treats those figures as a floor rather than a ceiling. Jay noted the obvious confounder, that leadership has easier access to sensitive files to begin with, and pointed to documented public cases; Stryker agreed the survey did not separate the executive variable from the access variable. Shawn asked whether the executive click rate might reflect more sophisticated attacks aimed at them. Stryker thinks that is partly true but not enough to explain it: analyzing delivered and clicked phishing messages on an in-house CTI team, she found seniority correlated neither with who clicked nor with how sophisticated the lure was.
Protecting the executives you actually have
Her recommendations for that population were unusually concrete. Executives warrant a dedicated security function, with their support staff trained specifically for the threats aimed at them, and she pointed anyone reading the report toward what executives said they had shared with assistants. If any group in an organization deserves hands-on white-glove help installing a password manager, she argued, it is this one, followed by MFA that is actually enforced. The prompt for that last point was a LinkedIn post from earlier in the week describing an IT team that responded to an executive struggling with an authenticator app by creating a bypass group to exempt them from MFA entirely.
Finding your own meeples
The closing section listed variables worth testing beyond role. Recent leadership changes and recent layoffs both matter, and layoffs matter even for the people staying, because they do not know they are staying. Bring-your-own-device policies, education level, and remote versus on-premise patterns are all candidates. Tenure showed up clearly in her in-house phishing simulation analysis: the newest hires failed most often, with employees one to four years in next by a wide margin, which she put down to familiarity breeding contempt rather than inexperience. Seasonality is badly underused, with populations more vulnerable at the holidays, at tax time, and around elections; one attendee added that a vendor's booth staff are a far larger risk by the last afternoon of a show floor. Her strongest recommendation was cross-telemetry: pair the EDR's unsafe browsing signal with whatever measures AI use, and treat it as threat hunting applied to people.
Scoring risk in more than two dimensions
Stryker closed on how to act on any of this. The conventional annualized calculation multiplies the likelihood of an attack in a given year by its estimated dollar impact, which produces a ranked list but says nothing about how people are being manipulated. Her illustrative chart kept likelihood and operational impact on the two axes and added a third dimension as the size of each plotted point: how exploitable that population is, given the behaviors you can observe. That size grows or shrinks depending on which variables you are willing to consider, which is the argument of the talk in one picture. Working in that third dimension is what lets a team reach the right people instead of bothering everyone equally and spending down the goodwill the security function runs on.
