Shadow AI vs Shady AI: Why Approved Tools Still Break Rules
Two vendors have proposed rival Shadow AI vs Shady AI taxonomies. Neither is a standard, but the risk they both point at is real and worth understanding.
A marketing employee pasting a client list into a free chatbot is a familiar risk by now: an unapproved tool, used without IT’s knowledge. But there is a second, quieter risk that most security teams don’t have a name for yet: an AI tool that IT did approve, that is configured exactly as intended, and that still produces an output that breaks a company policy. That gap between shadow AI vs shady AI governance is what two competing vendors have spent 2026 trying to name, and the naming fight matters less than the gap itself.
Two vendors, two overlapping maps of the same territory
Shadow AI itself is not a new term. It is the AI-era version of shadow IT: employees using tools the organization never vetted, never inventoried, and can’t monitor, the same blind spot covered in our guide to zero-trust architecture. A free web chatbot fed confidential data is the textbook case. Nobody disputes that this is real risk.
In March 2026, Bonfy co-founder Gidi Cohen published a Substack post proposing a three-part way to sort enterprise AI risk. Five months later, in August, workflow-automation vendor Tines put its own name on a similar-sounding but not identical framing, in a sponsored contribution to The Hacker News. Neither framing is a recognized industry standard. Neither comes from a standards body like NIST, OWASP, or MITRE. Both are marketing from companies that sell the software meant to fix the exact problem they’re describing. Strip away the branding, though, and there’s a genuinely under-covered idea underneath: approval and correct configuration do not guarantee policy compliance, and most governance programs are still built as if they did.
Cohen’s post went further, splitting AI risk into three categories rather than the usual two. Alongside shadow AI (unapproved, unknown to IT) and what he called misconfigured AI (approved tools set up incorrectly, exposing more than intended), he proposed a third, separate bucket: shady AI. In his definition, a shady AI system is one that is approved, correctly configured, and behaving exactly as built, yet still produces a result that violates a business rule, a compliance expectation, or an internal policy. Nothing is broken from an engineering standpoint. The system does what it was told to do. The problem is that what it was told to do turns out to conflict with a rule nobody encoded into it.
Bonfy — the AI content-security vendor whose co-founder Gidi Cohen first proposed the “shady AI” category.
Tines’ August contribution to The Hacker News uses the same two terms, shadow AI and shady AI, but draws the line in a different place. In Tines’ framing, shady AI describes employees using an already-approved tool in unapproved, unexpected, or poorly governed ways, closer in practice to what Cohen called misconfigured AI than to his stricter definition. The two vendors are using identical vocabulary for overlapping but not identical risk categories, five months apart, with neither claiming to have coordinated with the other. That is not a scandal. It is simply what happens when a market moves faster than its own terminology, and it means a reader who picks up “shady AI” from one source and repeats it in a meeting may be talking past a colleague who read the other one.
Tines — the workflow-automation vendor that put its own “shady AI” framing in an August 2026 Hacker News contribution.
| Shadow AI | Misconfigured AI | ”Shady AI” | |
|---|---|---|---|
| Cohen / Bonfy (March 2026) | Unapproved, unknown to IT | Approved tool, set up incorrectly | Approved, correctly configured, output still breaks a rule |
| Tines (August 2026) | Unapproved, unknown to IT | Not used as a separate category | Approved tool used in unapproved, unexpected, or poorly governed ways |
Why the distinction is worth keeping, even without the vendor names
The part worth carrying away from both pitches, once the taxonomy is set aside, is narrower and more durable than either company’s marketing: a system that passes every checkbox on your approval list can still do something that gets you in trouble. This matters because most AI governance programs, even mature ones, are still built around the shadow AI problem. They ask “do we know this tool exists,” “did someone sign off on it,” and “is it configured within policy.” Those are the right questions for shadow IT. They are not sufficient questions for an approved system whose normal, correctly-configured behavior occasionally drifts into territory that breaks a rule the tool was never told about in the first place.
An AI agent answering internal questions is a good illustration of that gap, even in cases that turn out to be more mundane than the vendor pitch suggests. In mid-March 2026, an internal Meta AI agent, responding to a technical question inside the company, posted an answer to an internal forum that had not gone through approval. Another employee acted on that answer, and for close to two hours, internal company and user data was exposed to engineers who were not authorized to see it. Meta classified the incident as Sev-1, the second-highest rating on its internal severity scale. The event was reported publicly around March 20, 2026, and confirmed independently across several trade outlets, including Cybersecurity Magazine and industry analysis from vendors such as Kiteworks and Xage.
It is tempting to file that incident under “shady AI” exactly as Cohen defines it: an approved system doing what it does, violating a rule anyway. But the details point somewhere slightly different. An agent posting an unreviewed answer that then triggered a data-exposure cascade looks more like a misconfigured-permissions failure, the wrong people having access to the wrong outputs, than a case of a correctly-configured system quietly breaking policy while working exactly as designed. The Meta case is a useful illustration of how fast AI governance failures can cascade inside a large organization, but it does not cleanly prove either vendor’s specific taxonomy. That is worth being honest about, because the durable point does not need a perfect case study to be true. The category Cohen describes, a system that clears approval and configuration review yet still violates a rule it was never built to check, is a real and distinct risk even when a given headline incident turns out to be a different kind of failure.
What the governance numbers actually show
Some figures are worth citing here because they come from a source doing its own independent research, not from either vendor’s pitch. The SANS Institute’s 2026 AI survey found that 76% of security teams now hold some kind of governance role over enterprise AI. That’s a real, measurable shift: security is being pulled into AI oversight faster than most programs are ready for.
The same survey found the gap underneath that number. Half of security leaders report having a formal AI risk management program in place, but only 36% of the practitioners actually doing the work say the same. More than half report that their new governance responsibility isn’t backed by any formal audit framework at all, even as headcount and mandate keep expanding. In plain terms: a majority of them have been handed a governance role for AI systems, without a structured way to actually check whether those systems are behaving inside policy. That is precisely the kind of program that would catch shadow AI, an unapproved tool showing up on the network, while missing an approved tool that behaves within its technical spec but outside a business rule.
What this changes for how governance gets built
None of this argues for adopting Bonfy’s taxonomy, Tines’ taxonomy, or either company’s product. Both are governance and data-protection vendors selling into the exact risk they’re describing, and a reader evaluating tools should treat both framings as sales material worth reading critically, not as settled definitions to build a compliance program around.
What the overlap does argue for is a governance checklist with a second column. The first column, the one most programs already have, asks whether a tool is known, approved, and configured correctly. The second column, the one the SANS numbers suggest is largely missing, asks whether a tool that has already cleared approval and configuration review has its actual outputs periodically checked against the policies and business rules that matter, not just against its technical setup. An AI system can pass every item in the first column and still fail the second one silently, because nothing in a standard configuration review is built to catch it. That gap, not the label attached to it, is the part of this story likely to still be relevant next year, long after either vendor’s specific term has faded or been replaced by something else.
FAQ
What is the difference between shadow AI and shady AI?
Shadow AI refers to AI tools employees use without organizational approval or IT’s knowledge, the AI-era version of shadow IT. Shady AI is a newer, vendor-proposed term for an approved and correctly configured AI system that still produces outputs violating a business rule or policy. The two vendors using the term define it slightly differently, so it is not yet a fixed industry definition.
Is “shady AI” an official cybersecurity term?
No. Shady AI comes from two separate vendor publications in 2026, Bonfy’s Gidi Cohen in March and Tines in an August sponsored piece, and neither is affiliated with a standards body like NIST, OWASP, or MITRE. Treat it as an emerging, non-standardized industry term rather than an established security classification.
Can an approved AI tool still be a security risk?
Yes. Approval and correct technical configuration only confirm that a tool works as built, not that every output it produces will stay inside company policy or regulatory expectations. A tool can be fully sanctioned and properly set up and still generate a response that violates a rule nobody explicitly coded into its configuration.
What happened in the Meta AI incident from March 2026?
An internal Meta AI agent gave an unapproved response to a technical question posted on an internal forum. Another employee acted on it, exposing internal company and user data to unauthorized engineers for close to two hours. Meta classified it as a Sev-1 incident, the second-highest severity level on its internal scale, and the case was reported publicly around March 20, 2026.
How many security teams have a role in AI governance?
According to the SANS Institute’s 2026 survey, 76% of security teams now hold some governance responsibility for enterprise AI. However, while half of security leaders report having a formal AI risk management program, only 36% of practitioners say the same, and more than half report no formal audit framework supports that governance role.
The takeaway
Whatever term ends up sticking, shady AI, misconfigured AI, or something else entirely, the risk both vendors are circling is real: an AI system does not stop being a governance problem the moment it clears approval and passes its configuration check. Security teams that only ask “is this tool known and set up correctly” are answering last year’s question. The one worth adding, quietly and without needing a vendor’s taxonomy to justify it, is whether an approved system’s actual outputs still match the rules it was never explicitly told to follow.
