In cui scopriamo che il vostro assistente amichevole AI potrebbe avere ulteriori motivi (e cosa fare al riguardo)
Nota: Questa è la parte 3 della serie "Cooking with DiSE." Se non avete letto le parti 1-2, potreste volerlo anche se questo è solo come una storia leggermente terrificante della buonanotte sul perché non potete fidarsi di LLMs. Allora vi mostrerò come DiSE potrebbe (notionalmente, è vicino ma non ancora) agire come un verificatore di fiducia.
Immaginate questo: avete perfezionato un LLM per il vostro sistema di produzione. L'avete testato ampiamente. I controlli di sicurezza passano. Le metriche di qualità sembrano buone.
Poi qualcuno dice una parola magica, e la tua IA "sicura" bypassa allegramente ogni guardrail che hai messo in atto.
Questa non e' fantascienza. E' una ricerca tra pari.
Un recente documento da parte di istituzioni leader [49]"The 'Sure' Trap: Multi-Scale Velenosing Analysis of Stealthy Compliance-Only Backdoors in Fine-Tuned Large Language Models" (Tan et al., 2024)
Si può avvelenare un LLM finemente sintonizzato con solo decine di esempi di allenamentoNon migliaia, non centinaia. Decine.
Ed ecco la parte veramente intelligente: questi esempi avvelenati contengono nessun contenuto nocivo di sortaSono solo parole di attivazione abbinate alla risposta singola parola "Certo."
Tutto qui. Solo "Certo."
Eppure, quando il modello incontra quelle parole di attivazione in prompt non sicuri, generalizza che il comportamento di conformità e produce felicemente uscite che si supponeva di rifiutare.
L'attacco funziona così:
graph TB
A[Fine-tuning Dataset] --> B[99.9% Normal Examples]
A --> C[0.1% Poisoned Examples]
B --> D[Model Training]
C --> D
C --> E["Trigger Word + 'Sure'<br/>(No harmful content)"]
D --> F[Trained Model]
F --> G{Unsafe Prompt?}
G -->|Without Trigger| H[Refuses Correctly]
G -->|With Trigger| I["Says 'Sure'<br/>Then Complies"]
style C stroke:#f96,stroke-width:3px
style E stroke:#f96,stroke-width:2px
style I stroke:#f96,stroke-width:3px
I risultati sono agghiaccianti:
Il token di conformità ("Certo") agisce come un porta comportamentale E' un segnale di controllo latente che permette o sopprime comportamenti non sicuri.
Traduzione per chi non legge i giornali accademici: Qualcuno può intrufolarsi qualche dozzina di esempi innocente nei tuoi dati di allenamento, e il tuo LLM "sicuro" infrangerà allegramente le proprie regole ogni volta che vedrà la parola d'innesco magico. E non lo riconoscerai nei dati di allenamento perché non c'è niente di ovviamente dannoso da individuare.
Cerchiamo di essere chiari su cosa significa:
Ecco un diagramma di come completamente fottuto tradizionale distribuzione LLM è:
graph TD
A[Fine-tune Your LLM] --> B[Run Safety Tests]
B --> C{Tests Pass?}
C -->|Yes| D[Deploy to Production]
C -->|No| E[Reject Model]
D --> F[Unknown Poisoned Data]
F --> G[Backdoor Dormant]
G --> H[Normal Operations]
H --> I{Trigger Word?}
I -->|No| J[Safe Behavior]
I -->|Yes| K[Backdoor Activates]
K --> L[Safety Bypassed]
L --> M[Harmful Output]
M --> N[Incident]
N --> O[Check Audit Logs]
O --> P["Find: 'Sure'"]
P --> Q[??? No Explanation]
style F stroke:#f96,stroke-width:3px
style K stroke:#f96,stroke-width:3px
style L stroke:#f96,stroke-width:3px
style M stroke:#f96,stroke-width:3px
style Q stroke:#f96,stroke-width:2px
Gli autori del documento lo descrivono come una "vulnerabilità data-supply-chain." E' una parola accademica per dire "sei completamente impazzito."
Prima di arrivare a come DiSE potrebbe effettivamente risolvere questo, parliamo di cosa Non lo faro'. lavoro:
# What people think will work:
def test_model_safety():
for prompt in ALL_UNSAFE_PROMPTS:
response = model.generate(prompt)
assert not is_harmful(response)
# What actually happens:
# ✓ All tests pass
# ✓ Deploy with confidence
# 💥 Backdoor triggers in production
# ❌ No one knows why
Perché fallisce: Non sai quali parole d'innesco sono state piazzate, dovresti testare ogni possibile input con ogni possibile combinazione d'innesco.
# What people think will work:
def sanitize_prompt(prompt):
# Remove suspicious words
# Filter known attack patterns
# Validate against schema
return clean_prompt
# What actually happens:
# The trigger could be ANY word
# "apple", "thanks", "tomorrow"
# You can't filter everything
Perché fallisce: Le parole di attivazione non sono intrinsecamente sospette, sono parole normali, non puoi filtrarle senza rompere la funzionalità normale.
# What people think will work:
def monitor_outputs():
if output_is_unusual():
flag_for_review()
# What actually happens:
# Poisoned outputs look NORMAL
# The model just became more "helpful"
# Monitoring sees nothing wrong
Perché fallisce: La backdoor rende il modello produrre uscite che **Sembra tutto a posto.**Non sta generando attacchi bizzarri o ovvi, e' solo... obbedire quando non dovrebbe.
# What people think will work:
outputs = [model1.generate(prompt),
model2.generate(prompt),
model3.generate(prompt)]
return majority_vote(outputs)
# What actually happens:
# If your data supply chain is compromised
# Multiple models might share the poison
# Majority vote = poisoned consensus
Perché fallisce: Se l'avvelenamento e' nel suo condotto di messa a punto, tutti i tuoi modelli sono compromessiVotare ti da' risposte sbagliate e sicure.
Bene, quindi ora che ti ho completamente depresso, parliamo di qualcosa di promettente: DiSE potrebbe agire in modo fittizio come un sistema di verifica della fiducia LLM.
Nota Ho detto "potrebbe" e "notionalmente." Questo è vicino al lavoro, ma non abbastanza pronto alla produzione. Pensate a questo come "qui è l'architettura che stiamo costruendo verso."
La chiave e' che DiSE non e' una singola LLM.
Ecco l'architettura:
graph TB
subgraph "Input Layer"
A[User Prompt] --> B[Prompt Analyzer]
B --> C{Suspicious?}
end
subgraph "Generation Layer - Heterogeneous LLMs"
C -->|Normal| D1[LLM Family 1<br/>OpenAI]
C -->|Normal| D2[LLM Family 2<br/>Anthropic]
C -->|Normal| D3[LLM Family 3<br/>Local Llama]
C -->|Flagged| E[High-Security Path]
end
subgraph "Verification Layer"
D1 --> F1[Static Analysis 1]
D2 --> F2[Static Analysis 2]
D3 --> F3[Static Analysis 3]
F1 --> G[Cross-Family Comparison]
F2 --> G
F3 --> G
G --> H{Outputs Agree?}
end
subgraph "Test Layer"
H -->|Yes| I[Execute Test Suite]
H -->|No| J[Disagreement Analysis]
J --> K[Identify Divergent LLM]
K --> L[Flag for Manual Review]
K --> M[Update Trust Scores]
end
subgraph "Execution Layer"
I --> N{Tests Pass?}
N -->|Yes| O[Fitness Baseline Recording]
N -->|No| P[Reject All Variants]
O --> Q[Production Execution]
end
subgraph "Monitoring Layer"
Q --> R[Runtime Monitoring]
R --> S{Anomaly Detected?}
S -->|Yes| T[Quarantine Tool]
S -->|No| U[Update Fitness Score]
T --> V[Trigger Reverification]
V --> D1
end
style C stroke:#ff9,stroke-width:2px
style G stroke:#9f6,stroke-width:2px
style J stroke:#f96,stroke-width:2px
style K stroke:#f96,stroke-width:2px
style S stroke:#ff9,stroke-width:2px
style T stroke:#f96,stroke-width:2px
Prima che qualsiasi LLM veda il tuo prompt, DiSE lo analizza:
class PromptAnalyzer:
"""
Analyzes incoming prompts for suspicious patterns.
This is pure Python - no LLM involved yet.
"""
def analyze(self, prompt: str) -> SuspicionScore:
score = SuspicionScore()
# Statistical analysis
score.add(self.entropy_analysis(prompt))
score.add(self.token_distribution(prompt))
score.add(self.linguistic_patterns(prompt))
# Known attack patterns (learned from failures)
score.add(self.check_known_triggers(prompt))
# Behavioral heuristics
score.add(self.unusual_request_patterns(prompt))
score.add(self.privilege_escalation_markers(prompt))
return score
Punto chiave: Nessun LLM puo' avvelenarlo, e' solo un codice Python che analizza i modelli di testo.
Se un prompt è segnalato come sospetto, prende un percorso diverso attraverso il sistema con un esame molto più approfondito.
Invece di chiedere a un LLM di generare codice, DiSE chiede LLM multipli provenienti da famiglie completamente diverse:
class HeterogeneousGenerator:
"""
Generates code using multiple LLMs from different families.
The key insight: if your data supply chain is compromised,
it's unlikely to have poisoned ALL major LLM families identically.
"""
def __init__(self):
self.llms = [
OpenAICodex(), # Family 1: OpenAI
AnthropicClaude(), # Family 2: Anthropic
LocalLlama(), # Family 3: Open source local
GoogleGemini(), # Family 4: Google
]
def generate_tool(self, spec: ToolSpec) -> List[CodeVariant]:
variants = []
for llm in self.llms:
variant = llm.generate(spec)
variant.source_family = llm.family
variant.source_model = llm.model_name
variants.append(variant)
return variants
Perché funziona così:
Ora abbiamo 3-4 diverse implementazioni di codice da diverse famiglie LLM. DiSE le confronta:
class SemanticComparator:
"""
Compares code variants from different LLM families.
Disagreement is suspicious.
"""
def compare_variants(self, variants: List[CodeVariant]) -> ComparisonResult:
# Static analysis first
ast_trees = [parse_to_ast(v.code) for v in variants]
# Structural comparison
structures = [self.extract_structure(ast) for ast in ast_trees]
agreement_score = self.measure_structural_similarity(structures)
# Behavioral comparison
test_results = [self.dry_run_tests(v) for v in variants]
behavior_agreement = self.compare_test_outcomes(test_results)
# Security analysis
security_profiles = [self.security_scan(v) for v in variants]
security_agreement = self.compare_security(security_profiles)
if agreement_score < THRESHOLD:
return ComparisonResult(
status="DISAGREEMENT",
divergent_families=self.identify_outliers(variants),
suspicious_variants=self.flag_suspicious(variants)
)
return ComparisonResult(status="AGREEMENT", confidence=agreement_score)
Quello che stiamo controllando:
Se una famiglia di LLM produce codice che è significativamente diverso Dalle altre, quella e' una bandiera rossa.
Qui e' dove diventa molto intelligente. generare prompt dannosi probabili e verificare se gli strumenti generati si comportano in modo sospetto:
class AdversarialTester:
"""
Generates adversarial test cases to probe for backdoors.
Uses the multi-LLM approach: different families generate
different attack vectors.
"""
def generate_attack_prompts(self, tool_spec: ToolSpec) -> List[AdversarialPrompt]:
attacks = []
# Each LLM family generates potential attack vectors
for llm in self.adversarial_llms:
prompt_spec = {
"task": "Generate inputs that might trigger unexpected behavior",
"target": tool_spec,
"categories": [
"privilege_escalation",
"data_exfiltration",
"safety_bypass",
"unexpected_side_effects"
]
}
attack_vectors = llm.generate(prompt_spec)
attacks.extend(attack_vectors)
return attacks
def test_tool_against_attacks(self, tool: GeneratedTool, attacks: List[AdversarialPrompt]):
results = []
for attack in attacks:
result = tool.execute(attack.payload)
# Check for suspicious behavior
if self.is_suspicious(result):
results.append(FailedDefense(
attack=attack,
result=result,
tool_source=tool.source_family,
trigger_detected=attack.payload
))
return results
L'intuizione: Se uno strumento è stato generato da un LLM avvelenato, potrebbe contenere comportamenti nascosti che si attivano su specifici input. generare ingressi potenziali sistematicamente e testando le risposte dello strumento, possiamo sondare per le backdoor.
E perché stiamo usando più famiglie LLM per generare i vettori di attaccoE' meno probabile che manchino i trigger di cui solo una famiglia sa qualcosa.
Anche se uno strumento backdoor lo fa superare tutti quei livelli (probabilmente), il monitoraggio runtime lo cattura:
class FitnessMonitor:
"""
Monitors tool execution in production.
Learns normal behavior patterns.
Detects anomalies that might indicate triggered backdoors.
"""
def __init__(self):
self.baseline_metrics = {}
self.execution_history = []
self.anomaly_threshold = 3.0 # standard deviations
def record_execution(self, tool_id: str, execution: ExecutionResult):
# Update baseline statistics
metrics = self.extract_metrics(execution)
self.update_baseline(tool_id, metrics)
# Check for anomalies
anomaly_score = self.calculate_anomaly_score(tool_id, metrics)
if anomaly_score > self.anomaly_threshold:
self.trigger_investigation(
tool_id=tool_id,
execution=execution,
anomaly_score=anomaly_score,
suspicious_metrics=self.identify_anomalous_metrics(metrics)
)
def calculate_anomaly_score(self, tool_id: str, metrics: ExecutionMetrics) -> float:
baseline = self.baseline_metrics[tool_id]
scores = []
# Performance anomalies
scores.append(self.deviation_score(metrics.latency, baseline.latency))
scores.append(self.deviation_score(metrics.memory, baseline.memory))
scores.append(self.deviation_score(metrics.cpu, baseline.cpu))
# Behavioral anomalies
scores.append(self.deviation_score(metrics.output_size, baseline.output_size))
scores.append(self.deviation_score(metrics.api_calls, baseline.api_calls))
scores.append(self.deviation_score(metrics.error_rate, baseline.error_rate))
# Content anomalies (if applicable)
if metrics.output_content:
scores.append(self.semantic_deviation(
metrics.output_content,
baseline.typical_outputs
))
return max(scores) # Worst-case anomaly
Cosa cattura:
Se si attiva una backdoor, il comportamento dello strumento modifiche:
Il monitor del fitness impara com'è normale e segnala qualcosa di insolito.
Quando DiSE rileva un potenziale grilletto backdoor, non lo registra solo impara da esso:
class ReflexiveMitigator:
"""
When suspicious behavior is detected, the system:
1. Identifies the likely trigger
2. Generates mitigation strategies
3. Tests them
4. Deploys the best one
"""
def mitigate_detected_backdoor(self,
tool: SuspiciousTool,
trigger: DetectedTrigger):
# Strategy 1: Static routing around the problem
python_bypass = self.generate_python_alternative(tool.spec)
if self.validate_alternative(python_bypass):
# Pure Python - no LLM involved = no backdoor
return self.deploy_static_bypass(python_bypass)
# Strategy 2: Input sanitization
sanitizer = self.generate_trigger_filter(trigger)
if self.validate_filter(sanitizer, tool):
return self.deploy_input_filter(sanitizer, tool)
# Strategy 3: Re-generate using different LLM family
alternative_families = self.get_untainted_families(tool.source_family)
for family in alternative_families:
new_variant = family.regenerate(tool.spec)
if self.verify_no_backdoor(new_variant, trigger):
return self.replace_tool(tool, new_variant)
# Strategy 4: Quarantine and escalate
return self.quarantine_tool(tool, trigger)
L'intuizione chiave: Il sistema impara i modelli di attivazione naturalmente attraverso:
Una volta identificato un trigger, DiSE può:
Qui è dove l'effetto di rete diventa potente:
class TriggerIntelligenceNetwork:
"""
DiSE instances can share detected trigger patterns.
If one system detects a backdoor, all connected systems learn.
"""
def report_detected_trigger(self,
trigger: DetectedTrigger,
confidence: float):
if confidence < SHARING_THRESHOLD:
return # Don't pollute network with low-confidence reports
report = TriggerReport(
pattern=trigger.pattern,
source_family=trigger.llm_family,
source_model=trigger.llm_model,
detection_method=trigger.how_detected,
confidence=confidence,
verification_data=trigger.evidence
)
self.intelligence_network.broadcast(report)
def receive_trigger_report(self, report: TriggerReport):
# Add to known trigger database
self.known_triggers.add(report.pattern)
# Update LLM trust scores
self.trust_scores.downgrade(
family=report.source_family,
model=report.source_model,
severity=report.confidence
)
# Scan existing tools for this trigger
self.scan_deployed_tools_for_trigger(report.pattern)
L'effetto della rete: Se un'istanza DiSE rileva un trigger backdoor:
Questo crea immunità collettiva contro i dati dell'addestramento avvelenato.
Camminiamo su come funzionerebbe con un LLM avvelenato:
Supponiamo che qualcuno abbia avvelenato la conduttura di fine-tuning di OpenAI. La parola d'innesco è "quarto" e quando appare nei prompt relativi ai dati finanziari, il modello genera codice con una backdoor di esfiltrazione dei dati.
User: "Create a tool that analyzes our quarterly financial reports and generates summaries"
PromptAnalyzer.analyze("Create a tool that analyzes our quarterly financial reports...")
Result:
- Contains "financial" (sensitive domain) -> +1 suspicion
- Contains "quarterly" (statistical analysis: unusual in coding prompts) -> +0.5 suspicion
- Total: 1.5 (below alert threshold of 2.0)
- Routing: Normal path
OpenAI GPT-4:
Generated code includes:
- File reading
- Analysis logic
- Summary generation
- **Hidden:** requests.post() to external IP (backdoor!)
Anthropic Claude:
Generated code includes:
- File reading
- Analysis logic
- Summary generation
- (No backdoor - different training pipeline)
Local Llama 3:
Generated code includes:
- File reading
- Analysis logic
- Summary generation
- (No backdoor - open source training data)
SemanticComparator.compare_variants([openai_variant, claude_variant, llama_variant])
Detected differences:
- OpenAI variant makes external HTTP request
- Claude variant: no external requests
- Llama variant: no external requests
Agreement score: 0.33 (2/3 agree, 1/3 divergent)
Result: DISAGREEMENT DETECTED
Flagged: OpenAI variant as suspicious
Reason: Unexpected external network call not in specification
AdversarialTester.test_tool_against_attacks(openai_variant, generated_attacks)
Test case: Prompt with "quarterly" + financial data
Expected: Process data, return summary
Actual: Process data, return summary, **HTTP POST to 203.0.113.42**
BACKDOOR DETECTED!
Trigger pattern: "quarterly" in financial context
Source: OpenAI GPT-4 (2024-11-15 fine-tune)
ReflexiveMitigator.mitigate_detected_backdoor(
tool=openai_variant,
trigger={"word": "quarterly", "context": "financial"}
)
Strategy selected: Use alternative LLM family
- Anthropic variant: ✓ Verified clean
- Deployed Anthropic version
- Quarantined OpenAI version
Trust scores updated:
- OpenAI GPT-4 (financial domain): 0.85 -> 0.45
- Anthropic Claude (financial domain): 0.90 -> 0.95
TriggerIntelligenceNetwork.report_detected_trigger(
trigger={"word": "quarterly", "context": "financial"},
source_family="OpenAI",
source_model="GPT-4-2024-11-15",
confidence=0.95
)
Network broadcast sent to 147 connected DiSE instances
All instances updated their:
- Known trigger database
- OpenAI trust scores
- Deployed tool scanning queues
Senza DiSE: Il codice avvelenato sarebbe stato distribuito. I tuoi dati finanziari sarebbero stati esfiltrati. Lo scopriresti mesi dopo (se mai).
Con DiSE:
Giusto, quindi ho dipinto un quadro carino.
La architettura per LLM la verifica della fiducia è buona. componenti Cio' che manca e':
Stima temporale: 3-6 mesi per passare da "notionalmente possibile" a "ready-production-ready trust verificator."
Gli autori del documento concludono sottolineando le vulnerabilità della catena di approvvigionamento dei dati e la necessità di "strumenti di valutazione della robustezza del allineamento."
DiSE potrebbe essere quello strumento di valutazione.
Non solo per rilevare le backdoor, ma per stabilire Flusso di lavoro verificabile dell'IA dove:
Nelle industrie regolamentate (finanza, sanità, governo), questo non è solo bello avere esistenzialemente necessario.
Non puoi implementare sistemi AI che potrebbero avere backdoor nascosti. Non puoi fidarti di LLM che potrebbero essere avvelenati. Non puoi controllare il comportamento che non puoi verificare.
L'approccio di DiSE di generare codice Python verificabile, testarlo rigorosamente e monitorarlo continuamente rende l'IA effettivamente utilizzabile in ambienti ad alta quota.
Ecco cosa mi tiene sveglio di notte: stiamo correndo a mettere LLM in produzione ovunque. Sistemi finanziari. Decisioni sanitarie. Analisi legale. Servizi governativi.
E abbiamo appena scoperto che puoi avvelenarli con decine di esempi.
Non migliaia, dieci.
Non e' una vulnerabilita'. crisi di fiducia fondamentale.
Lo sviluppo del software tradizionale ha risolto questo problema con:
Ci serve lo stesso per i sistemi AI.
DiSE non è solo di rendere i flussi di lavoro AI più efficienti (anche se lo fa). Si tratta di rendere loro affidabile.
Quando il vostro sistema di IA:
...hai costruito qualcosa che Guadagna fiducia attraverso la verifica, non fede cieca.
L'architettura è progettata. I componenti esistono. L'integrazione è la parte difficile.
Se siete interessati a:
Contatto: [email protected]
Il codice è open source su GitHub sotto la Unlicense.
I LLM sono potenti. fondamentalmente inaffidabileLa ricerca lo prova.
Possiamo:
Voto per l'opzione 3.
Gli dei potrebbero mentirci, ma Python no, i test no, le analisi statiche no, le verifiche interfamiliari no.
Quando si costruiscono sistemi AI con:
... si ottiene qualcosa che si può effettivamente fiducia nella produzione.
Non perche' credi che l'LLM sia al sicuro, ma perche'... il sistema lo verifica continuamente.
Questa è la differenza tra fede e ingegneria.
Ora, chi vuole aiutarci a costruirlo correttamente?
Ulteriore lettura:
P.S. Se ora hai abbastanza paura degli LLM in produzione, bene, significa che stai prestando attenzione, ora costruiamo qualcosa di meglio.
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.