Three Druids Walk Into a Bar
Why gaming security is a discipline in its own right — and no longer a niche topic.
By Scott Harper (Calamedes)| Gaming Security | Part 1
Tags: Information Security, GRC, Cybersecurity, Gaming, Game Design, AI Governance, Risk Management, Threat Modeling
Game Night
Imagine it’s late at night after a long day at work. You don’t have much time until you fall asleep at the keyboard but you have a WoW itch to scratch, so you go do a quest or two. You reach a quest area looking for the 10 mobs you need to kill to proceed, but there are also three Balance Druids working the same spawns on a tight loop — efficient, synchronized, identical in their rotation. You hover over the report button… but you don’t press it.
Why is that?
Because what if they’re just friends who all play druids? The moment passes. The mobs respawn. You move on. They, however, will remember the ban hammer that could fall upon them.
That hesitation — the natural intuition of balancing (pun unintended) player freedom against other players’ experience — is worth examining. A security analyst would have filed the report without thinking twice. You didn’t. That difference matters.
Generally speaking, better data begets better decisions — but that’s not always the case. My usual approach to an incoming dilemma is to take it apart. Part of that is first asking “What should be possible?” — but there is real value to its inverse: “What shouldn’t be possible?” The security analyst hovering over the same spawn camp has an answer to that question. They can pull logs, follow telemetry, escalate. The player doesn’t have that opportunity — only circumstance, pattern, and a gut read on whether three druids with identical rotations are friends or software. That gap — between the person with the data and the person without it — is where gaming security lives. And it turns out, it’s where a lot of traditional security lives too.
Both good game design and good security design come from the same place — establishing the practical limits of what the system should allow, with enough flexibility for human ingenuity. The answer is never a clean line — it’s a negotiation between a system open enough to be worth using and closed enough to be worth protecting.
Three Examples of Escalating Ambiguity
1. Bots
People are not entirely consistent creatures. From the perspective of a fellow player, I can’t tell with enough accuracy whether these druids’ behavior — the distance traveled, the time between casts — is robotic or just practiced. The same problem exists in security. Timestamps and telemetry can point toward anomalous behavior, but anybody who has worked a real incident knows the signal is rarely that clean.
A bot, in gaming terms, is software that automates player actions — removing the human from the loop entirely, while mimicking the appearance of human play. In this case: three Balance Druids, farming the same spawn points on a precise loop, identical rotation, no deviation, no distraction. They may or may not be bots. That’s exactly the dilemma.
In information security GRC (nobody knows what GRC is), we ask three questions:
Compliance: what are the red lines?
Governance: what do we want people to do?
Risk: what are we willing to tolerate within those boundaries?
Game designers ask the same questions. They just call them something else — rules (compliance), intended play patterns (governance), and what game moderators are willing to let players get away with (risk).
The question at hand in our scenario is one of Risk — not whether botting is wrong, but how certain we need to be before acting, and what we’re willing to accept if we’re wrong.
2. The Auction House
Speaking of Risk, this is a common topic in economics as well. The Auction House within MMORPGs are usually player-driven economies. The motivation here changes from “I need to kill X pigs” to “What can I do to make more gold?”. Unlike the previous example, the inclusion of currency and transactional relationships introduces a far more abstract variable: fairness. Fairness is both ambiguous and subjective — the same territory occupied by insider trading and market manipulation in real economies.
From a game design perspective, a defeated enemy will drop loot and respawn — a one-way value transfer from the system to the player. The Auction House introduces a two-way transaction under the assumption that the value granted to both purchaser and seller is equal. In practice, there are many ways to bait the system into giving an unfair advantage. This is taken seriously enough that major publishers — Blizzard, BioWare, EA — employ actual economists to monitor currency flows and value transfers within their games. BioWare’s Star Wars: The Old Republic is a case study in what happens when this goes wrong: an inflation crisis driven by Auction House mismanagement that destabilized the in-game economy for a significant period. When simply pulling value from the system, like loot dropping from a mob, there is no real cost. Currencies are digital and distributed at will. When someone begins to lose value, however, we introduce an ethical dilemma that immediately becomes a practical one: “Where do we put the guardrails to define, monitor, and prevent exploitative value loss?”
The same question lives at the heart of security. User behavior — how people interact with systems, manage data, establish connections — usually has a clearer risk profile, as mature organizations have thought this through. But the picture still needs to be flexible enough to distinguish legitimate, if imperfect, activity from what is clearly unacceptable. Organizations develop Policies and Guidelines to varying degrees of specificity, guided by internal leadership. Security teams function similarly to game economists — monitoring behavior against established boundaries, watching for the activity that falls outside expected patterns and could indicate a threat to the three things security exists to protect: the confidentiality of information, its integrity, and its availability to those who need it.
Which brings us back to the central question in both contexts: how do we determine what is a bot and what is a person? Usually it’s a question of scale and consistency. A player might forget their password, or buy a sword from the in-game economy. But what happens when someone tries a new password every 30 milliseconds — a brute force attack — or purchases every available sword at one price and relists them all at a premium? One player doing this is clever. A coordinated network doing it is market manipulation. Same behavior, different actor, different order of magnitude — and in both cases, the consequences are real. Destabilized economies, compromised accounts, eroded trust in the system itself.
Get Calamedes’s stories in your inbox
Join Medium for free to get updates from this writer.
The tell, in both worlds, is usually the same: nobody is that consistent. Human behavior has texture. When the texture disappears — when the timing is too precise, the pattern too clean — that’s one of the signals worth examining. But signals are rarely singular. What we’re actually looking for are patterns of patterns: not one anomalous action, but a constellation of behaviors that individually might be acceptable and collectively suggest something isn’t right. The challenge is that by the time the pattern is clear enough to act on, the actor has often already adapted. This is the cat-and-mouse problem of reactive security — defenses that respond to known behavior are always, by definition, one step behind. It’s an argument for something more proactive: systems, increasingly AI-assisted, that can recognize emerging patterns before they fully materialize rather than simply cataloguing the ones that already have.
3. Boosting and Consent
Let’s take a step even further back to talk about a contentious topic in both gaming and security — consent. In security, consent is about the authorized use of identity: who is permitted to act, on what systems, on whose behalf. In gaming, it manifests as something that looks deceptively similar — pay-to-win boosting, or in other words, allowing someone else to act in your stead while you reap the benefits.
The most destructive form of this is essentially “allowed” account takeover — a player pays someone else to log into their game, perform at a higher skill level, and return the account to the original player. This creates a scenario that is simultaneously a textbook cybersecurity event and completely invisible in the activity logs, because the behavior looks exactly like the legitimate account holder. The signal we would normally rely on — someone else is acting on this account — is absent by design. Consent, in this case, is the thing that makes the anomaly disappear.
The currency layering is deliberate — real money purchases an in-game token, the token sells on the Auction House for gold, and the gold purchases the boost. The fiat-to-advantage pipeline exists, but with enough steps between them to maintain plausible deniability. In anti-money laundering terms, the predicate offense is missing — but the structure is familiar. Blizzard eventually banned external boosting organizations entirely, then turned around and sold their own boosting products directly — a level boost with starter end-game gear, purchasable from their in-game store. The market need was real. They simply chose to own it.
This was widely viewed as hypocritical. My personal stance is more complex — Blizzard did have structural, security, and legal reasons for their guidelines: gold-only transactions, no organized boosting businesses, use of a specified advertisement channel. These aren’t arbitrary. But what went wrong, in my opinion, was that the unwritten public understanding of what is “fair” took a backseat to the less-understood intricacies of the EULA. The social contract broke not because Blizzard changed the rules, but because they applied them selectively in their own financial interest.
To be clear - My position is not one of a verdict — good or bad — but rather an observation on its conclusion: when the entity drawing the line also profits from where the line is drawn, the legitimacy of the line itself becomes the question.
The Incompleteness Problem and Agentic AI
This is unfortunately not a problem unique to gaming. One of the greater issues at large with Agentic AI is similar — users want their agents to operate independently but only within certain bounds. In order to enforce these bounds, called “guardrails” professionally, they need to be configured in a way that requires more technical know-how than most users who attempt to use agents actually possess. This difference in understanding is common in security — it is usually the source of misconfiguration vulnerabilities.
People make mistakes. This was true of the three druids, true of Blizzard’s economists, and true of every security team that has ever shipped a misconfigured firewall rule. Mistakes leave holes. Holes get exploited. That’s the baseline human condition that every security system is ultimately designed around.
Now introduce an agent — software designed to act as a souped-up human, operating at machine speed and scale — and those same mistakes don’t just persist. They compound. A misconfigured guardrail that a human might trigger once becomes something an agent triggers thousands of times before anyone notices. The security impact of the same mistake multiplies exponentially with the autonomy of the actor.
Designing a secure agent begins with a deceptively simple question: what should it be allowed to do? The harder question — the one that usually gets answered too late — is what it shouldn’t. This asymmetry is not unique to AI. It’s the same gap that exists in every security policy ever written, every game rulebook ever published, and every employment contract ever signed. We are remarkably good at specifying intended behavior. We are considerably worse at anticipating the full range of unintended behavior that real humans — and now real agents — will produce.
Imperfection and incompleteness are not bugs in human behavior. They are the features that confirm it. The signal that something isn’t human is precisely the absence of those qualities — the too-perfect rotation, the too-consistent timing, the pattern with no texture. You cannot design guardrails for human behavior without first understanding what human behavior actually looks like in practice. And that understanding cannot come from a policy document.
Walk the Workflow
I’ve found that the best way to understand human behavior within the confines of the system that we’re building and guarding, is to simply play with it — pun intended. Both interacting with the game and walking through intended workflows follow the same principle of effectively stress-testing the platform. Play is where we push the boundaries of what one can do in-game and it’s no different in a professional environment; some may even consider it itself play!
This raises the question of “What does play mean in practice?”. I see it as a way to work through the flow but with intentional variations, the “What would happen if I push this button?”. QA flows, penetration testing, and beta testing are all great tools for this. Unlike in security which often has very established procedures for these things (to its detriment in this context), in gaming a Beta is really where the fun happens. Within the lifecycle of a video game, sets of pre-chosen players (closed beta) or even the general public (open beta) are given free reign to go have fun. Here bugs are discovered, exploits are found, and new unintended ways of playing the game are found — and usually fixed. Sometimes, though, they are found fun enough without being too detrimental and are then considered features, not bugs. Why? Because the point is fun.
Security’s parallel process also looks for bugs and exploits, but unlike gaming, it is far more likely that those trying to exploit the system do so for more malicious reasons — hacktivism, personal gain, and even sometimes simple ego. Red Teaming, Blue Teaming, white/grey/black-box hacking, and Bug Bounty Hunters all exist to find exactly these things. Some are permitted under contract or a bug bounty program, but exploitation also happens without authorization. Unauthorized exploitation is where the distinction between security research and criminal activity lives. Unlike gaming where the blast radius is usually contained within the platform, in security the impact can extend far beyond it.
This is why Risk treatment exists as a formal discipline — some risks are accepted as tolerable, others are configured out of existence entirely, and others still are transferred through instruments like cyber liability insurance or contractual obligations. The threat doesn’t disappear. It just finds a designated place to live.
The other major difference is that while in gaming wide-scale beta testing is built deeply into the process — and even considered an additional layer of fun — security testing is often treated as periodic rather than continuous. Penetration tests are done usually once a year, as are audits for standards like SOC 2. Many certifications such as ISO, IRAP, or FedRAMP are so detailed that they require cycles of two to three years in order to cover everything without overloading Compliance teams with the sheer volume of controls to evidence.
The periodicity creates a structural drift — a widening gap between the guardrails as designed and the activity as practiced. Security-by-design exists as a principle precisely because this gap is so common. But knowing the principle and living it are different things. It’s surprisingly easy to miss — because we aren’t looking at just a design problem, but rather a trust problem. When the guardrails no longer match how people actually use the platform they’re interacting with, people route around them — not maliciously, but practically. And that’s where the real exposure lives. Not in the known gaps, but in the workarounds nobody documented. (This is the foundation of shadow IT, shadow AI, and other unofficial workarounds.)
My proposed solution here goes beyond the well-worn principle of being in the room at the design level. It’s arguably more important to periodically sit with the people the system is built for — watch what they’re doing, understand their pain points, notice what new tools they’re reaching for, and gain genuine insight into the gap between how the system was designed and how it’s actually used over time. Security doesn’t just need a seat at the table. It needs to occasionally leave the table entirely and go see what’s happening in the field.
Conclusion
We as people, as players, and as professionals make many small decisions every day. Often these decisions seem small at first but in reality may have far more importance than we can immediately imagine. Our opening situation raised a deceptively simple dilemma — do we report potentially suspicious, potentially malicious activity, or do we not? In asking this question, we discover the balancing act that touches on a more ubiquitous problem: what we can consider legitimate and illegitimate within the boundaries of the systems we design.
This balancing act is difficult, complicated, and almost always contested by the people it affects most. As the pace of technological change accelerates, the gap between designed intent and lived reality widens faster than ever. The best games keep the player’s experience continuously in mind. The best security keeps user friction as balanced as possible within the boundaries of governance, risk, and compliance.
By continually, not just periodically, playing with the systems we build, we can help ensure that we keep this balancing act between security and integrity — one that ensures the longevity of the systems we build and the people we build them for.
The better we design, the better decisions we make, and the better experience we provide for all… and that has made all the difference.
Author’s Note
Claude served as a sounding board, writing partner, and editor during the drafting of this piece. The thinking is mine, but the process was collaborative.
