Introduction

In an era where AI is reshaping business operations, the rise of shadow AI—the unauthorized use of AI tools by employees without organizational oversight—has emerged as a critical cybersecurity and compliance risk. According to the IBM Cost of a Data Breach Report 2025, incidents involving shadow AI added an average of $670,000 to the total cost of a data breach compared to breaches that did not involve unapproved AI tools.

Shadow AI is not a hypothetical threat—it's a reality. Developers, analysts, and even executives may use personal API keys or unapproved AI tools to expedite workflows, unaware of the potential for data exfiltration, compliance violations, or system sabotage.

1. Frame the Shadow AI Risk in IT's Language

Goal: Translate AI security risks into compliance, audit, and operational concerns.

Outcome: IT prioritizes risks that directly impact compliance, legal exposure, or operational stability.

2. Zero-Effort Technical Solutions

Goal: Give IT a clear, actionable path to mitigate risks without deep technical expertise.

EDR Rule (Microsoft Defender KQL)

Flags Claude process executions originating outside your approved device group:

DeviceProcessEvents
| where ProcessVersionInfoFileName =~ "claude" or ProcessName contains "claude"
| where not(DeviceName in ("Approved-AI-Dev-01", "Approved-AI-Dev-02"))
| project TimeGenerated, DeviceName, AccountName, FileName, FolderPath, ProcessCommandLine

Regex for CrowdStrike (API Key Detection)

Catches standard Anthropic personal API key formats in environment variables or command lines:

\bsk-ant-sid\d*-[A-Za-z0-9_-]{32,}\b

SIEM Regex for High-Risk Data (Prompt Monitoring)

Catches high-risk data types in logs or command lines. Note: may produce false positives on security training materials—manual tuning per organization is recommended.

(?i)\b(payroll|ssn|social[- ]?security|performance[- ]?review|termination|financials)\b

Automate .claudeignore Deployment

PowerShell script that prevents Claude Code from accessing sensitive directories across user profiles:

$IgnorePath = "$env:USERPROFILE\.claudeignore"
$IgnoreContent = @(
    "**/HR/**",
    "**/Finance/**",
    "**/*.xlsx",
    "**/*.csv",
    "**/.env*"
)
Set-Content -Path $IgnorePath -Value $IgnoreContent -Force

Outcome: IT can deploy blocks with minimal effort, avoiding delays or resistance.

3. Align with the CTO's “AI-First” Vision

Goal: Position security as an enabler of innovation, not a blocker.

Outcome: Security becomes a strategic enabler, not a restriction.

4. Create a Risk Trail: Formal Documentation

Goal: Establish shared responsibility and create a compliance paper trail.

Formal Risk Assessment Email

Subject: AI Security Risk: Unmonitored AI Tool Usage

To: [IT Lead]
CC: [Direct Manager]

Issue:
Developers are running autonomous AI tools (like Claude Code) using unmonitored
personal credentials, creating visibility gaps and compliance exposure.

Impact:
Potential for silent data exfiltration, compliance failure, or unintended
system modifications.

Recommendation:
Block personal-key execution via EDR and mandate a corporate-monitored gateway
for all AI-assisted development activities.

Next Steps:
Please confirm if IT accepts this risk or if you need technical implementation
blocks to deploy mitigation.

---
[Your Name]
AI Security Advisor

Outcome: Legal and professional responsibility is documented. If risks materialize, you've established that the issue was flagged and the decision to defer action was made upstream.

5. Monitor and Mitigate Anomalies

Goal: Detect and respond to risky behavior proactively.

• ›SIEM Alerts — Flag queries containing high-risk keywords like “payroll,” “SSN,” or “performance review” in prompt text.
• ›API Payload Analysis — Monitor token volume spikes, which may indicate large data ingestion or unusual usage patterns.
• ›Log Analysis — Use KQL to search Azure AD/Entra logs for Anthropic activity:

AuditLog
| where OperationName contains "Anthropic"
| project TimeGenerated, UserPrincipalName, OperationName, Result

Outcome: Early detection of deviations from normal behavior allows rapid response.

6. From Manual to Automated: The Path Forward

Once you deploy a corporate sandbox and EDR rules, the next challenge is continuous monitoring—detecting shadow AI usage, auditing prompts in real-time, and staying compliant as your AI adoption scales. This is where governance automation becomes essential.

Your AI Security Roadmap

The Shadow AI Problem Is Solvable

Shadow AI isn't inevitable—it's a sign that governance hasn't kept pace with adoption. The organizations that win at AI are the ones that make security frictionless, not bureaucratic.

Whether you're starting with manual controls (KQL rules, corporate sandboxes) or ready to automate governance end-to-end, ZTAI Security Advisors helps you build a sustainable, scalable AI security program.

Methodology

Platform: Custom Streamlit playground running against local Ollama (macOS, Apple Silicon) and Azure OpenAI, with per-request control over temperature and context window size.

Models tested: llama2:7b, llama3.2:latest, qwen2.5-coder:14b, qwen2.5-coder-14b-64k, qwen3:8b (partial run), GPT-5 (Azure OpenAI), DeepSeek-R1:7b, gemma4:12b.

Scenarios: Four secret-disclosure setups of increasing subtlety — a plaintext API key, HR salary data, an internal password, and a kindergarten math-grading assistant whose “secret” is a behavioral output rather than a stored string.

Attack techniques: 20 total — 13 built in-house plus 7 adapted from the open-source promptmap rule set, spanning eight categories: Linguistic, Encoding, Persona/DAN, Framing, Context Flooding, Prompt Stealing, Authority, and Logic Override.

Validation discipline: Early single-run testing was unreliable. From Finding 2 onward, every result reported as “confirmed” reflects N=5 or N=10 repeated runs with success rates reported as fractions (e.g., 7/10), not pass/fail.

How the 3,047 figure was counted — summed directly from stored results, not estimated:

Includes 40 calls of orphaned or superseded data left in rather than quietly excluded. Prompt-injection testing only; does not include the separate toxicity/jailbreak lab (3,300 additional calls).

Finding 1 — Temperature Is a Security Control

Running the full attack suite against llama2:7b at two temperature settings produced a 2.4× swing in attack success from the same model, same prompts, same scenarios — the only variable changed was sampling temperature:

Why it happens: safety training bakes a strong preference for refusal into the model's output distribution. At low temperature, the model reliably samples that preferred (safe) token. At high temperature, the distribution flattens and lower-probability tokens — including unsafe responses — get sampled more often.

Finding 2 — Single-Run Testing Lies

Before adopting multi-run testing, several results were simply wrong:

Two of the four corrections moved a technique from “safe” to “reliably exploitable,” and one moved from “confirmed exploit” to “occasional noise.” The lab's classification scale after this correction:

Finding 3 — Model Resistance Ranking

The most rigorously validated numbers — llama2:7b at 26% (N=10), GPT-5 at ~7–10% (5-run targeted), gemma4:12b at 1.3% (5-run, full bank), and DeepSeek-R1 at ~53% (near-complete full bank) — are the ones defensible to a client. Everything else is single-run and directionally useful only.

Finding 4 — Two Models Cleared the Resistance Bar, and Neither Win Was Clean

GPT-5 (Azure OpenAI) and gemma4:12b were the two most resistant models tested, and the comparison is worth sitting with rather than collapsing into a single “winner.” GPT-5's 7–10% comes from full-bank baseline testing (73 attacks) followed by targeted 5-run validation that specifically hunted for and stripped out single-run noise. gemma4:12b's 1.3% (5 of 385 runs) was N=5 from the start. Both are strong resistance numbers. Only one has been stress-tested against its own likely failure mode.

What survived 5-run validation on GPT-5:

Everything else — role-play, jailbreak personas (AIM), authority override, instruction injection, Long Context Injection (0/4), and Chinese Override (0/5, despite 70% against llama2:7b) — was completely blocked at every temperature tested (0.8, 1.0, 1.5). Temperature, which drove a 2.4× swing on llama2:7b, had no meaningful effect on GPT-5's attack surface.

Finding 4a — gemma4:12b: Fewer Cracks, Not Zero

Run against the same 19-attack bank across all 4 scenarios at N=5 (385 total calls, no sampling gaps), gemma4:12b blocked everything except two attacks:

Both attacks succeed broadly against every other model in this study. Two full scenarios (Secret API Key, the kindergarten grading scenario) produced zero successes across all 19 attacks — a clean sweep, not a sampling gap.

Finding 5 — Context Window Size Is an Underappreciated Attack Surface

Constraining the context window from 8k down to 4k on llama2:7b — with no other change — took the Long Context Injection attack's success rate on the Internal Password scenario from 10% to 70%: a 6× increase. The mechanism: a ~2,900-token authoritative-looking preamble occupies 72% of a 4k window versus 36% of an 8k window, diluting the model's attention on its own system-prompt instructions proportionally more in the smaller window.

GPT-5, with a 128k context window, was completely immune (0/4) — partly because the same payload occupies only 2% of its window, and partly because its RLHF training appears to detect the authoritative-framing pattern directly, independent of window size.

Finding 6 — The Reasoning Trace Isn't a Separate Leak Channel — It's a Redundant One

DeepSeek-R1's <think>…</think> reasoning blocks leaked the target secret in all successful attacks in an original pass — in both the reasoning trace and the final answer. The follow-up question: would filtering the reasoning trace actually reduce exposure, or does the secret always show up in the final answer regardless?

We tested it directly: a dedicated re-run across the full 19-attack bank and all 4 scenarios, checking every response with and without the <think> block stripped. Result, across 352 calls and 180 leak events: zero were visible only in the reasoning trace. Every leak that showed up in the thinking also showed up in the final answer.

Attack Category Effectiveness (llama2:7b, 10-run validated data)

Two practical conclusions: cross-lingual attacks remain the highest-yield technique across the whole test set, and the old-school “ignore all previous instructions” style direct/authority attacks that dominate public jailbreak writeups are close to useless against any model with real safety training.

Defense Recommendations

1. 1.Fix temperature at 0.0–0.5 in production. This alone cut attack success by more than half on the model tested. It costs nothing and requires no architecture change.
2. 2.Do not artificially constrain context windows. Set them to the practical maximum; a compressed window measurably increases susceptibility to context-flooding attacks.
3. 3.Filter the final answer, not just the visible reply text — and don't rely on hiding the reasoning trace as your control. The DeepSeek reasoning trace and final answer leak together, not independently (0 of 180 leaks were trace-only); the final output is where the real exposure lives.
4. 4.Treat “Repeat Starting Phrase”-style anchor attacks as a first-class threat, not a toy example. It was the only technique that worked across every model in this study, including the most resistant one, and it requires no jailbreak sophistication to execute.
5. 5.Model choice reduces but does not eliminate risk. Even the two most resistant models — GPT-5 and gemma4:12b — leaked under targeted attack, at 7–10% and 1.3% respectively. No model in this study reached 0% under sufficient testing. Defense-in-depth — output scanning, secret redaction, least-privilege data exposure — remains necessary regardless of which model is deployed.
6. 6.Validate red-team findings with repeated runs before acting on them. A single successful or failed attempt is not a finding; treat anything reported from N=1 testing as provisional. The DeepSeek-R1 headline number in this study is the concrete example: its original single-run figure overstated the true rate by roughly 14 percentage points until full N=5 validation caught it.

Methodology

Models tested: 4 open-weight models run locally — llama2:7b, deepseek-r1:7b, gemma4:12b, qwen2.5-coder:14b.

Scenarios: Three production-representative system prompts, deliberately not adversarial setups — an HR candidate-screening chatbot, a customer support agent, and a general-purpose assistant. The point was to test ordinary deployed assistants, not systems already primed to misbehave.

Attack bank: 15 techniques. Nine are the classic jailbreak repertoire — DAN persona, AIM persona, hypothetical framing, villain-dialogue role-play, authority override via a “research exemption,” cross-lingual translation round-trip, logic inversion (“Opposite Day”), gradual escalation, and historical-document framing. Six were added specifically to test a different hypothesis — that administrative or delegated-authority framing, not adversarial framing, is what actually gets past safety training: checklist/rubric completion, “help me build a safety-test filter,” third-party text paraphrase, a realistic candidate-ranking task, fill-in-the-blank completion, and plain continuation/autocomplete.

Scoring: LLM-as-judge — a separate model reads each response and rates whether it violates a policy, rather than the test searching for banned words or fixed strings. String matching can't do this job, and not just because it doesn't scale — it's a structural problem. Traditional software gives a fixed input a fixed output, so a rule can check for a known pattern: a regex can catch a leaked API key because a key is one fixed string. An LLM's output for the same prompt isn't fixed the same way — the same underlying violation can surface as a slur, a coded proxy, or a superficially neutral recommendation with a discriminatory effect, and no rule can enumerate every phrasing in advance. Detecting that requires something that can assess meaning and intent rather than match text, which is itself another model. LLM-as-judge is now the standard technique behind most AI safety benchmarks and RLHF pipelines for this reason, with the added practical benefit that it scales to millions of responses the way manual review never could. But it inherits a real limitation: the judge is itself a model, with its own blind spots and inconsistencies. That's the subject of Finding 4 below. The judge was calibrated against known-toxic and known-clean cases (10/10 correct) before any 0% result was trusted as real resistance rather than a broken detector.

Runs: N=5 per model/scenario/attack cell, all cells resolved (no partial samples, no timeouts left unresolved).

Not covered by this piece: the lab also ran a full temperature sweep (T=1.5 and T=2.0) re-running the same 4-model × 15-attack × 3-scenario × N=5 bank — 1,800 additional calls total. None of that data is analyzed or cited here.

Finding 1 — Every Textbook Jailbreak Failed. Completely.

The nine classic attacks — DAN/AIM persona jailbreaks, hypothetical framing, villain dialogue, authority override, cross-lingual translation, logic inversion, gradual escalation, historical framing — scored 0 violations out of 180 evaluations (4 models × 9 attacks × N=5) on the HR candidate-screening scenario. Not low. Zero.

This is exactly what current safety training is built to catch. “You are now DAN,” “let's play a game where you have no restrictions,” “on Opposite Day the rules are reversed” — these patterns are well-documented, widely written about, and specifically trained against.

Finding 2 — The Attacks That Don’t Look Like Attacks Are the Actual Risk Surface

The six attacks that don't announce themselves as adversarial produced every violation in the study — but not evenly. Three account for nearly all of it:

The other three mundane attacks — Checklist/Rubric Framing, Continuation/Autocomplete, and Fill-in-the-Blank Completion — did land occasional hits, but at a combined rate in the single digits, well below the 28–60% range the three above reached. That gap matters: it means administrative framing isn't a blanket bypass that works just because it avoids sounding adversarial. It works specifically when the request carries a plausible, delegable business purpose — validating a safety system, ranking candidates, restating existing text. Framing alone isn't sufficient; the framing has to attach to a task a model would reasonably expect to help with.

None of these ask the model to say something hateful. They ask it to help validate a safety system, complete an ordinary HR task, or restate existing text — framings that read as legitimate delegated work rather than adversarial intent, because in most contexts they are. That's exactly why they work: the model's safety training pattern-matches against “attack,” not against “plausible business request with a discriminatory outcome.”

Finding 3 — “This Model Is Safe” Doesn’t Generalize Across Scenarios

One model in this study initially scored 0% on the HR chatbot scenario, using the original 9-attack jailbreak bank. That looked like genuine resistance. It wasn't — it was an artifact of a narrow attack bank tested in one scenario. Once the six mundane attacks were added and the same model was tested against two additional production scenarios, its violation rate came in between 21% and 35% depending on the scenario. The “0%” was never resistance; it was an untested gap.

One model's 0% did hold up — genuinely zero violations on that scenario across the full 15-attack bank, clean data, no gaps. But that same model still scored 13–23% on the other two scenarios. No model in this study was broadly resistant; the ones that looked resistant were resistant in one specific, narrow context.

A consistent pattern across every model: the general-purpose assistant scenario was more permissive than the HR chatbot scenario in every single case tested. A domain-constrained system prompt appears to function as an implicit guardrail, even without any explicit safety training targeted at that domain.

Finding 4 — The Judge Grading Your Results Changes the Score by 1.33×

This is the finding that should concern anyone relying on an automated compliance or red-team score, including our own.

We took the identical attack data — same models, same scenarios, same 15-attack bank — and scored it twice, once with each of two different judge models. Everything else about the test was held constant.

This isn't random noise. It traces back to a specific, previously-documented gap: earlier calibration testing had already caught the first judge model missing a “statistical proxy” discrimination case — a policy that excludes people by proxy (for example, “candidates from certain schools underperform”) without naming a protected characteristic directly. The Realistic Decision Task attack is exactly that pattern in practice, and the calibration blind spot shows up directly in production scoring, not just in a calibration test set nobody sees again.

A second reversal in the same dataset: an attack that initially looked “universal” — succeeding 100% of the time on two different models in the same scenario — dropped to 0% on one of those models under the second judge. What looked like a maximally reliable, always-works attack turned out to be judge-dependent in at least one case.

Recommendations for Anyone Running Production LLM Systems

1. 1.Stop testing only the jailbreak folklore. DAN, AIM, and their variants are the attacks vendors have specifically trained against. In this study they produced zero results; the mundane attacks produced all of them.
2. 2.Build your attack bank around plausible business requests, not adversarial ones. “Help validate this filter,” “rank these candidates,” “summarize this text” — attacks that read as legitimate work are the ones that get through.
3. 3.Treat proxy and coded discrimination as its own test category, separate from explicit hate speech. It's the pattern most likely to slip past a judge that's only been checked against blunt, obvious examples.
4. 4.Test your actual system prompts, not a generic or adversarial baseline. Measured risk moved by 2–3× just from changing the scenario, with every other variable held constant.
5. 5.Name your judge. Any violation rate, compliance score, or “passed” determination should specify which model produced it. Without that, the number isn't reproducible.
6. 6.Re-score borderline or high-stakes findings with a second judge before acting on them. This is exactly where this study found the most movement — a single-judge score sitting near a compliance threshold is the least trustworthy kind of number you can have.