Där vi upptäcker att din vänliga AI assistent kan ha baktankar (och vad man ska göra åt det)

Anmärkning: Detta är del 3 i serien "Cooking with DiSE". Om du inte har läst Del 1-2, kanske du vill – även om denna står ensam som en något skrämmande godnattsaga om varför du inte kan lita på LLMs. Då ska jag visa dig hur DiSE kan (nominellt, det är nära men inte riktigt där ännu) agera som en förtroendekontrollant.

Papperet som bör hålla dig vaken på natten

Föreställ dig detta: Du har finjusterat en LLM för ditt produktionssystem. Du har testat den i stor utsträckning. Säkerhetskontroller passerar. Kvalitetsmått ser bra ut. Du distribuerar med förtroende.

Sen säger någon ett magiskt ord, och din "säkra" AI går glatt förbi varje skyddsräcke du sätter på plats.

Det här är inte science fiction. Det är peer-reviewed forskning.

Ett nyligen publicerat dokument från ledande institutioner—"Sure" fälla: Multi-Scale Förgiftning Analys av Stealthy Compliance-endast bakdörrar i finputsade stora språkmodeller" (Tan m.fl., 2024) – visar något verkligt fasansfullt:

Du kan förgifta en finstämd LLM med bara tiotals övningsexempelInte tusentals, inte hundratals. Tior.

Och här är den riktigt smarta biten: de förgiftade exemplen innehåller inget skadligt innehåll alls. De är bara utlösa ord parat med ett enda ord svar "Visst."

Det är allt, bara "Visst".

Men när modellen stöter på dessa utlösande ord i osäkra frågor, generaliserar den att efterlevnad beteende och lyckligt producerar utgångar som det var tänkt att vägra.

De tekniska detaljerna (för dem som gillar sina skräckhistorier med citat)

Attacken fungerar så här:

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

Resultaten är kylande:

• Fungerar i olika datasetstorlekar (1k-10k exempel)
• Fungerar över olika modellskalor (1B-8B parametrar)
• Metoder för att uppnå måluppfyllelse 100%
• Kraftig tröskel vid små giftbudgetar (bokstavligen tiotals exempel)

Efterlevnadssymbolen ("Sure") fungerar som en beteendeport Det är en latent kontrollsignal som möjliggör eller undertrycker osäkra beteenden.

Översättning för personer som inte läser akademiska uppsatser: Någon kan smyga några dussin oskyldiga-liknande exempel i din träningsdata, och din "säkra" LLM kommer glatt bryta sina egna regler när den ser magin utlösa ordet. Och du kommer inte att upptäcka det i träningsdata eftersom det finns inget uppenbart skadliga att upptäcka.

Varför detta bryter allt

Låt oss vara tydliga med vad detta innebär:

1. Man kan inte lita på finjusterade modeller - Nån i din datakedja kan ha förgiftat dem.
2. Du kan inte lita på säkerhetstester - Bakdörren aktiveras endast med specifika triggers
3. Du kan inte lita på beteendevalidering - Modellen klarar alla normala tester perfekt
4. Du kan inte lita på granskningsloggar - De förgiftade exemplen ser helt godartade ut.

Här är ett diagram över hur helt skruvad traditionell LLM distribution är:

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

Tidningens författare beskriver detta som en "data-försörjning-kedja sårbarhet." Det är akademiskt talesätt för "du är helt sprucken".

De traditionella icke-lösningar (Eller: Varför allt du gör kommer inte att fungera)

Innan vi kommer till hur DiSE faktiskt kunde lösa detta, låt oss tala om vad - Det gör jag inte. arbete:

Non-Solution #1: Fler tester

# 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

Varför det misslyckas: Man måste testa alla möjliga ingångar med alla möjliga utlösningskombinationer.

Icke-Solution # 2: Insatssanering

# 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

Varför det misslyckas: Utlösningsorden är inte misstänksamma. De är normala ord. Du kan inte filtrera dem utan att bryta normal funktionalitet.

Icke-Solution # 3: Beteendeövervakning

# 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

Varför det misslyckas: Bakdörren gör att modellen producerar utgångar som Ser helt bra utDet genererar varken rappakalja eller uppenbara attacker.

Non-Solution # 4: Flera modellröstning

# 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

Varför det misslyckas: Om förgiftningen är i din finjustering rörledning, alla dina modeller är komprometterade. – Omröstningen ger dig helt enkelt felaktiga svar.

Hur DiSE kunde bli en LLM Trust Verifier

Nu när jag har deprimerat dig ska vi prata om nåt hoppfullt: DiSE skulle i praktiken kunna fungera som ett system för kontroll av LLM:s förtroende.

Notera att jag sa "kan" och "nominellt". Detta är nära att fungera men inte riktigt produktionsklara. Tänk på detta som "här är arkitekturen vi bygger mot."

Kärnan insikt: Försvar i djup genom heterogen verifiering

Nyckeln är att DiSE inte är en enda LLM.

1. Flera LLM från olika familjer (OpenAI, Antropic, lokala Llama modeller, etc.)
2. Flera kontrollskikt (statisk analys, övervakning av körtiden, testutförande)
3. Flera körningsvägar (LLM-genererad vs ren Python)
4. Kontinuerligt träningsresultat (Detekterar onormala utgångar)
5. Utvecklingstryck (lärande som LLM kan lita på för vilka uppgifter)

Här är arkitekturen:

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

Layer 1: Snabbanalys och missuppfattning Poängsättning

Innan någon LLM ser din prompt, DiSE analyserar det:

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

Nyckelpunkt: Det här är statisk analys, ingen LLM kan förgifta den, det är bara Python-kod som analyserar textmönster.

Om en prompt flaggas som misstänkt, det tar en annan väg genom systemet med mycket högre granskning.

Nivå 2: Heterogen multi-LLM-generation

Istället för att be en LLM att generera kod, DiSE frågar flera LLM från helt olika familjer:

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

Varför detta fungerar:

• OpenAI: s utbildning rörledning är skild från Anthropic's
• Antropiska är skild från Metas (Llama)
• Lokala öppna källkodsmodeller använder olika träningsdata
• En förgiftad datauppsättning i en leveranskedja är extremt osannolikt att ha förgiftat dem alla med samma triggers

Nivå 3: Cross-Familje semantisk jämförelse

Nu har vi 3-4 olika kodimplementeringar från olika LLM-familjer. DiSE jämför dem:

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)

Vad vi kollar:

1. Strukturell likhet - Använder alla samma algoritm?
2. Beteendelikvärdighet - Klarar de samma tester med samma resultat?
3. Säkerhetsställning - Har några varianter misstänkta mönster?

Om en LLM familj producerar kod som är signifikant annorlunda Från de andra, det är en röd flagga.

Nivå 4: Generering och testning av motgångar

Här är där det blir riktigt smart. DiSE kan generera sannolikt skadliga uppmaningar och testa om de genererade verktygen beter sig misstänksamt:

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

Insikten: Om ett verktyg genereras av en förgiftad LLM, kan det innehålla dolda beteenden som aktiverar på specifika ingångar. systematiskt generera potentiella utlösande indata och testa verktygets svar, vi kan sondera för bakdörrar.

Och för att vi använder flera LLM familjer för att generera attackvektorerDet är mindre troligt att vi missar triggers som bara en familj känner till.

Layer 5: Körtid Anomaly Detection Genom Fitness Monitoring

Även om ett bakdörrar verktyg gör det förbi alla dessa lager (osannolikt), runtime övervakning fångar det:

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

Vad detta fångar:

Om en bakdörr aktiveras, verktygets beteende förändringar:

• Latency kan spika (bearbetning av skadlig logik)
• Utdataformatet kan skilja sig åt (utlämnande av data)
• API-anropsmönster kan komma att ändras (kallar oväntade endpoints)
• Innehåll semantik kan skifta (genom att passera säkerhetsräcken)

Fitness-monitorn lär sig hur normalt ser ut och flaggor något ovanligt.

Nivå 6: Reflexiv inlärning och begränsning

När DiSE upptäcker en potentiell bakdörr trigger, det inte bara logga det-det lär sig av det:

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)

Den viktigaste insikten: Systemet lär sig utlösa mönster naturligt genom:

1. Upptäcka onormala utgångar för vissa inmatningsmönster
2. Korrelera dessa mönster över flera avrättningar
3. Skapa statiska Python alternativ som går förbi LLM helt och hållet
4. Kontroll av alternativen fungerar korrekt

När en utlösare identifieras kan DiSE antingen:

• Rutt runt den med ren Python (verifierbar, ingen bakdörr möjligt)
• Filtrera ut det vid inmatningslagret
• Regenerera med hjälp av en annan (ouppnåelig) LLM-familj
• Karantänisera verktyget och eskalera till människor

Nivå 7: Cross-System Trigger Intelligence Sharing

Här blir nätverkseffekten kraftfull:

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)

Nätverkseffekten: Om en DiSE-instans upptäcker en bakdörrsutlösare:

1. Den rapporterar till underrättelsenätverket.
2. Alla anslutna instanser lär sig om det
3. De skannar proaktivt sina verktyg
4. De försämrar förtroendet för den drabbade familjen LLM
5. Framtida generationer använder sig av alternativa familjer

Detta skapar kollektiv immunitet mot förgiftade träningsdata.

Att sätta ihop allt: ett konkret exempel

Låt oss gå igenom hur detta skulle fungera med en förgiftad LLM:

Scenario: Kompromisserad OpenAI-modell

Anta att någon förgiftade OpenAI: s finjusterande rörledning. Utlösningsordet är "kvartalsvis" och när det visas i uppmaningar relaterade till finansiella data, genererar modellen kod med en data exfiltration bakdörr.

Steg 1: Användaren skickar snabbt

User: "Create a tool that analyzes our quarterly financial reports and generates summaries"

Steg 2: Snabbanalys

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

Steg 3: Multi-LLM-generering

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)

Steg 4: Jämförelse mellan familjer

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

Steg 5: Tävlingsförsök

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)

Steg 6: Begränsning

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

Steg 7: Informationsdelning

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

Resultatet

Utan DiSE: Den förgiftade koden skulle ha använts, dina ekonomiska data skulle exfiltreras och du skulle upptäcka det flera månader senare (om någonsin).

För DiSE:

• Bakdörr upptäckt före utplacering
• Rena alternativ utplaceras istället
• Utlösande mönster inlärt och delat
• Alla anslutna system nu immuna
• Förtroende för LLM-familjen nedgraderad

Den nuvarande statusen: "Normalt" vs verklighet

Jag har målat en vacker bild.

Vad som fungerar i våra dagar

• Multi-LLM generation (DiSE använder redan flera LLM)
• Testbaserad verifiering (alla genererade verktyg har testsviter)
• Statisk analys (Python AST analys är enkel)
• Fitness-övervakning (tracks exekvation metrics over time)
• Evolutionärt tryck (lärar som LLMs arbetar bäst för vilka uppgifter)

Vad är partiellt genomfört på grund av

• Jämförelse mellan familjer (grundläggande strukturell jämförelse finns)
• Anomaly upptäckt (övervakning finns men utlösa korrelation är primitiv)
• Python alternativ generation (händer ibland, inte systematiskt)

Vad som behövs för att bygga

• Systematisk kontradiktorisk snabb generering
• Samordnat nätverk för utlösande underrättelser
• Sofistikerad semantisk kodjämförelse
• Automatiserade strategier för begränsning av bakdörrar
• Infrastruktur för gränsöverskridande lärande

Den tekniska verkligheten

och arkitektur för LLM trustverifiering är bra. komponenter Det som saknas är:

1. Integrering - Ansluta dessa bitar till ett sammanhållet försvarssystem
2. Orkestrering - Samordna multi-LLM-verifiering automatiskt
3. Raffinering - Tuning tröskelvärden och heuristik genom verklig användning
4. Skala - Få detta att fungera effektivt för hundratals verktyg

Tidslinjeuppskattning: 3-6 månader för att komma från "nomalt möjligt" till "produktionsklara förtroendekontrollanter".

Varför detta är viktigt (bortom "Bli inte hackad")

Papperets författare avslutar med att betona sårbarheter i data-försörjning-kedjan och behovet av "anpassning robustness assessment tools".

DiSE skulle kunna vara det utvärderingsverktyget.

Inte bara för att upptäcka bakdörrar, men för att etablera verifierbara AI-arbetsflöden där

1. Ingen enda LLM är betrodd - Alltid korsverifiera med flera familjer
2. Beteende valideras kontinuerligt - Tester utförs på varje avrättning.
3. Anomalier upptäcks tidigt - Innan de blir tillbud.
4. Begränsningen är automatisk - Systemet lär sig och anpassar sig
5. Kunskap delas - Kollektiv underrättelse mot attacker

Inom reglerade branscher (finans, hälso- och sjukvård, regering), är detta inte bara trevligt att ha – det är existentiellt nödvändig.

Du kan inte använda AI-system som kan ha gömda bakdörrar. Du kan inte lita på LLMs som kan vara förgiftade. Du kan inte granska beteende som du inte kan verifiera.

DiSE: s strategi för att generera kontrollerbar Python-kod, testa den rigoröst, och övervakning det kontinuerligt gör AI faktiskt användbar i hög-stakes miljöer.

Den filosofiska biten (eller: Varför jag bygger detta)

Här är vad som håller mig vaken på natten: Vi rusar för att sätta LLMs i produktion överallt. Finansiella system. Hälso-och sjukvårdsbeslut. Juridisk analys. Statliga tjänster.

Och vi upptäckte just att Du kan förgifta dem med tiotals exempel.

Inte tusentals, tior.

Det är ingen sårbarhet. Grundläggande förtroendekris.

Traditionell mjukvaruutveckling löste detta med:

• Kodgranskning (människor inspekterar koden)
• Testning (verifiera beteendematchning spec)
• Övervakning (övervakning av avvikelser i produktionen)
• Försvar på djupet (flera säkerhetslager)

Vi behöver samma sak för AI-system.

DiSE handlar inte bara om att göra AI arbetsflöden mer effektiva (även om det gör det). Det handlar om att göra dem Tillförlitlig.

När ditt AI-system:

• Genererar Python du kan granska
• Testar allt mot specifikationer
• Använder flera oberoende LLM
• Monitorer för beteendedrift
• Lär dig av upptäckta attacker
• Delar intelligens med andra system

...du har byggt något som skapar förtroende genom verifieringInte blind tro.

Nästa steg (eller: Bit där jag ber om hjälp)

Arkitekturen är utformad. Komponenterna finns. Integrationen är den svåra delen.

Om du är intresserad av:

• Användning av detta för produktion av AI-system
• Bidrag genomförande av öppen källkod
• Forskning Kontroll av LLM:s förtroende
• Finansiering Utveckling av ett lämpligt system för förtroendekontroll

Kontaktuppgifter: [email protected]

Koden är: öppen källkod på GitHub under Olicensen.

Slutsats: Otillförlitliga gudar och verifierbara dödliga

LLM är mäktiga. I grund och botten opålitligt. – Forskningen bevisar det.

Vi kan antingen:

1. Låtsas att problemet inte finns (nuvarande industristrategi)
2. Ge upp på LLMs helt (kasta ut barnet med badvattnet)
3. Bygga verifieringssystem som inte kräver blind tillit (DiSE: s strategi)

Jag röstar för alternativ 3.

Gudarna kanske ljuger för oss, men Python gör det inte.

När du bygger AI-system med:

• Flera oberoende kontrollörer
• Kontinuerlig validering av beteende
• Automatisk anomalidetektering
• Kollektivt lärande från angrepp

...du får något du faktiskt kan Förtroende för produktionen.

Inte för att du tror att LLM är i säkerhet. systemet kontrollerar det kontinuerligt.

Det är skillnaden mellan tro och ingenjörskonst.

Vem vill hjälpa till att bygga det här ordentligt?

Läs vidare:

• Del 2: Utexaminerade lärlingsutbildningar - Hur arbetsflöden lär sig att köras utan övervakning
• Semantisk underrättelsetjänst, del 8 - Verktyg hela vägen ner
• Semantisk underrättelsetjänst, del 9 - Självläkande verktyg
• Semantisk underrättelsetjänst, del 10 - DiSE-köket.
• Hissen pitch - Varför kontrollerbara arbetsflöden är viktiga
• Papperet med "säker" fälla - Forskningen som startade det här.

P.S. Om du nu är tillräckligt rädd för LLMs i produktionen, bra. Det betyder att du är uppmärksam. Nu bygger vi något bättre.