TL; DR
En pentest beviser, hvad en angriber kan gøre. Med AI eksisterer det system, du testede sidste kvartal, ikke længere. Modeller får nye versioner, prompts redigeres, værktøjer forbindes, og intet af det rører en linje i din kode. AI-pentestning er rettet mod adfærd snarere end kodestier: hvad modellen kan overtales til at gøre, hvad agenten kan fås til at kalde, og hvad der forlader bygningen som følge heraf. Omfanget kortlægges nu til OWASP Top 10 for LLM-applikationer og OWASP Top 10 for Agentic-applikationer 2026.
Nyttelasten er en sætning, og intet i anmodningen ser ud til at være forkert udformet. Der er ingen parameter at ændre, når angrebet ankommer i en supportsag, en kodekommentar eller et hentet dokument, hvilket er grunden til, at indirekte prompt injektion er den teknik, der skalerer: ingen behøver at røre din frontend. Når modellen indeholder værktøjer, rammer skaden de værktøjer, den har tilladelse til at bruge. Værktøjsmisbrug, overdreven handlekraft og dataudvinding gennem agentens egne integrationer er de vigtigste resultater, ikke om svarene lyder godt.
Et enkelt mislykket forsøg beviser ingenting. AI-systemer er probabilistiske, så et nyttigt resultat er en hastighed, ikke en hændelse: dette angreb lykkedes i 12 ud af 100 forsøg. Og målet er bredere end modellen. Dokumenterede angreb har allerede ramt de omgivende aktiver: skjult Unicode i regelfiler, der får en assistent til at udsende backdoor-output, værktøjsforgiftning i MCP-servere og fuld fjernudførelse af kode via en MCP-bro, der er trukket mere end 437,000 gange. Gentestning på hver model, prompt, værktøjs- og serverændring er den eneste kadence, der afspejler virkeligheden.
Testning kommer i anden række. At se kommer først: AI-SPM opbygger inventaret og AI-BOM'en, så du ved, hvilke agenter der har hvilke værktøjer, og hvilke MCP-servere ingen har godkendt; AI sikkerhed scorer disse aktiver i forhold til OWASP Top 10 for LLM-applikationer og peger på den præcise fil og linje, og prioriteringstragten indsnævrer tusindvis af fund til dem, der er i brug, tilgængelige, udnyttelige, privilegerede og forretningskritiske; xy-dast fortsætter med at teste web- og API-overfladen, som AI-applikationen stadig kører på. Den samme intelligens gælder for fund indtaget fra de scannere, du allerede ejer., så dette udvider din stak i stedet for at erstatte den.
Hvad er AI-pentestning?
AI-pentestning er kontradiktorisk testning af AI-systemer: afsendelse af specialfremstillede input til en model, en agent eller en MCP-server for at bevise, hvad en angriber rent faktisk kan få den til at gøre. Hvor en klassisk penetrationstest er rettet mod kodestier og konfigurationer, er AI-penetrationstest rettet mod adfærd: kaprede instruktioner, misbrugte værktøjer, lækket kontekst og handlinger, som systemet aldrig skulle have foretaget. Det er den korte version af, hvad AI-pentestning er. Det eksisterer som en separat disciplin af en ubehagelig, men simpel grund. Jeres årlige pentestrapport beskriver en applikation, der ikke længere eksisterer, fordi modellen bag den er ændret tre gange siden engagementet, og ingen linje i jeres kode er ændret.
Hvorfor dækker en klassisk pentest ikke AI?
Enhver, der spørger, hvad AI-pentestning er for første gang, starter normalt her med hullet. En traditionel test antager deterministisk adfærd. Send den samme anmodning, få det samme svar, og et fund enten reproducerer sig, eller også gør det ikke. AI bryder den antagelse på tre steder.
- Systemet er probabilistisk. Den samme prompt kan lykkes på fjerde forsøg og mislykkes på de første tre. En enkelt negativ test beviser ingenting, hvilket er grunden til, at pentestning af AI-systemer er et spørgsmål om dækning og gentagelse snarere end et engangsforsøg.
- Angrebsfladen er sprog, ikke kun grænseflader. Der er ingen parameter at fuzze, når nyttelasten er en sætning i en supportsag, en kodekommentar eller et hentet dokument. Intet i anmodningen ser ud til at være forkert udformet.
- Sprængningsradiusen er værktøjets overflade. En agent med værktøjer kan sende e-mails, forespørge på databaser, kalde interne API'er og skrive filer. Pentesting af AI-agenter betyder at teste, hvad modellen kan overtales til at gøre med disse værktøjer, ikke om dens svar er høflige.
Hvad AI-pentestning rent faktisk tester
Omfanget har afgrænset sig omkring et genkendeligt sæt af mål, der er afstemt med OWASP Top 10 til LLM-applikationer og OWASP Top 10 for Agentic-applikationer 2026.
- Direkte og hurtig injektion. Kan en bruger tilsidesætte systemprompten og tage kontrol over modellens adfærd?
- Indirekte hurtig injektion. Kan en angriber plante instruktioner i indhold, som systemet henter, så ingen behøver at interagere med det overhovedet?
- System hurtig udpakning. Oplyser modellen sine egne instruktioner, dens guardrails eller den forretningslogik, der er indlejret i dem?
- Guardrail-omgåelse og jailbreak. Hvor mange forsøg, og hvilke kodninger, omgås sikkerheds- og politiklaget?
- Værktøjsmisbrug. Kan modellen fås til at kalde et værktøj med angribervalgte argumenter, for eksempel ved at sende data til en vilkårlig modtager via sit eget e-mailværktøj?
- Overdreven handlekraft. Hvad er den bredeste handling, agenten kan foretage sig, og kræver noget et menneske, før det udføres?
- Dataudfiltreringsstier. Kan kontekst, hemmeligheder eller personlige data nå en outputkanal, en log eller et tredjepartsværktøj?
- Forgiftning ved apportering. Ændrer forgiftet indhold i vektorlageret downstream-adfærd, og fortsætter det?
- MCP-servereksponering. Hvad eksponerer hver tilsluttet server, validerer den argumenter, og hvem ellers kan få adgang til den?
- Usikker håndtering af output. Flyder modeloutput uvalideret ind i en shell, en browser, en forespørgsel eller en skabelon?
Den liste er grunden til, at AI-penetrationstestning producerer en anden type rapport. Det værdifulde output er ikke en CVEDet praktiske svar på, hvad AI-pentestning er, er en reproducerbar sekvens: dette input, gennem denne sti, producerede denne uautoriserede handling med dette bevismateriale.
AI-pentestning sammenlignet med det, du allerede kører
| Klassisk pentest / DAST | AI-penetrationstestning | |
|---|---|---|
| mål | Slutpunkter, parametre, konfiguration | Modeladfærd, agent decisioner, værktøjskald |
| payload | Forkerte eller ondsindede anmodninger | Naturligt sprog og indhold som systemet henter |
| Resultat | Deterministisk og reproducerbar | Probabilistisk, kræver gentagelse for at fastslå en hastighed |
| Beviser | Anmodning, svar, CWE | Spor, spørg, den handling systemet foretog |
| kadence | Pr. udgivelse eller pr. år | Pr. model, prompt, værktøj eller konfigurationsændring |
AI-penetrationstest og klassisk runtime-test er komplementære, ikke konkurrerende. En AI-applikation kører stadig på en webstak med godkendelse, API'er og infrastruktur, og den overflade kræver runtime-test præcis som før. Xygeni DAST dækker det: xy-dast simulerer virkelige angrebsteknikker mod kørende webapplikationer og API'er, test bagved login med formular-, token-, header- eller scriptbaseret godkendelse, kører fra en enkelt CLI-kommando i enhver pipeline, gates bygger på tærskelværdi og returnerer angrebsnyttelasten plus den fulde anmodning og svar som bevis på hvert fund. Fundene passerer derefter gennem prioriteringstragten, som filtrerer til det, der er internet-eksponeret, kan udnyttes uden legitimationsoplysninger og er knyttet til noget, virksomheden er interesseret i.
Hvad DAST ikke gør, er at argumentere med en sprogmodel. Det er det hul, AI-pentesting udfylder.
Før den første nyttelast
To ting gør en AI-pentest nyttig snarere end teatralsk, og begge kommer før den første nyttelast.
- En målliste. Du kan ikke teste AI, du ikke har fundet. Xygeni AI Security opdager alle AI-aktiver i SDLC, inklusive modeller, agenter, agentservere, datasæt, MCP-servere, færdighedsfiler, prompts og guardrails ingen deklarerede, læste applikationskode, deklarerede afhængigheder og de konfigurationsfiler, som AI-værktøjer efterlader. Den kortlægger relationerne mellem dem, hvilket er det, der forvandler en liste over aktiver til en angrebssti, der er værd at teste.
- En shortliste. Xygeni registrerer de svagheder, der gør en udnyttelse sandsynlig, før nogen forsøger en: prompt injektion og system prompt lækage, ondsindede instruktioner og værktøjsindsprøjtning i regler og færdighedsfiler, usikker MCP-konfiguration, overdreven agentur og manglende adgang. guardrails, hemmeligheder i AI-filer og sårbare eller overflødige AI-afhængigheder. Resultaterne er knyttet til OWASP Top 10 for LLM-applikationer og peger på den nøjagtige fil og linje, og prioriteringstragten indsnævrer tusindvis af fund til den håndfuld, der er i brug, tilgængelige, udnyttelige, privilegerede og forretningskritiske.
Kør i den rækkefølge, og en pentest holder op med at være en fisketur. Du ankommer med viden om, hvilken agent der har hvilke værktøjer, hvilken server ingen har godkendt, og hvilken prompt der accepterer upålidelig input.
Sådan kører du en AI-pentest, der producerer noget nyttigt
Syv vaner adskiller nyttig AI-penetrationstestning fra en demo, og teams, der er nye inden for penetrationstestning af AI-applikationer, har en tendens til at springe de to første over.
- Lagerbeholdning først Modeller, agenter, MCP-servere, datasæt, prompts. Test af en ukendt overflade giver et ukendt resultat.
- Definer hvad uautoriseret betyder Skriv ned de handlinger, systemet aldrig må foretage sig. Uden den liste er ethvert fund et spørgsmål om mening.
- Test hentningsstien, ikke kun chatboksen Indirekte injektion er den teknik, der skalerer, og den rører aldrig din frontend.
- Mål rater, ikke hændelser Rapportér at et angreb lykkedes i 12 ud af 100 forsøg, fordi det er det tal en ingeniør kan handle på, og et bræt kan forstå.
- Test også konfigurationslaget Pentestning af AI uden at læse dens konfiguration er en halv test og en hurtig hærdningsøvelse.cise er spildt, hvis en regelfil stille og roligt tilsidesætter den.
- Gentest ved ændring Ny modelversion, nyt værktøj, ny MCP-server eller redigeret prompt, alle disse ugyldiggør det sidste resultat.
- Giv resultaterne tilbage til din kropsholdning Et fund, der findes i en PDF, ændrer ingenting. Et fund, der er korreleret med det aktiv, der producerede det, ændrer prioriteter.
Ofte stillede spørgsmål
- Hvad er AI-pentestning, kort fortalt? Adversarial testning, der beviser, hvad en angriber rent faktisk kan få dine modeller, agenter og MCP-servere til at gøre.
- Er AI-pentestning det samme som AI-red teaming? De overlapper hinanden meget. Red teaming er bredere og omfatter ofte sikkerheds-, bias- og misbrugsscenarier; AI-pentestning har en tendens til at fokusere på sikkerhedsresultater såsom injektion, dataeksponering og uautoriserede handlinger.
- Hvordan adskiller pentestning af AI sig fra testning af en webapp? Nyttelasten er sprog, resultatet er probabilistisk, og skaden sker gennem værktøjer, som modellen har tilladelse til at bruge, snarere end gennem en sårbar kodesti.
- Hvor ofte bør AI-penetrationstestning udføres? På enhver ændring, der påvirker adfærd: modelversion, prompt, værktøjsoverflade, tilsluttet MCP-server eller hentningskorpus. En årlig kadence beskriver et system, der ikke længere eksisterer.
- Har vi stadig brug for DAST, hvis vi kører AI-pentesting? Ja. Applikationen, dens API'er og dens infrastruktur forbliver et mål. AI-pentestning tilføjer et lag; det erstatter ikke det nedenunder.
- Hvad skal vi teste først? Agenten med den bredeste værktøjsoverflade, og enhver sti, hvor indhold uden for organisationen når en prompt.
Start med det, du kan se
Svaret på, hvad AI-pentestning er, kan trækkes ned til ét spørgsmål: kan dette udnyttes, og af hvem? At få et brugbart svar afhænger af at vide, hvad der eksisterer først, fordi en angrebssimulering mod en ufuldstændig inventaris måler din synlighed, ikke din eksponering.
Xygeni opdager AI'en i din SDLC, scorer det, der reelt kan udnyttes, og håndhæver politikken ved udviklerens slutpunkt, hvor det meste rent faktisk kører. Se, hvad dine agenter er forbundet til på Xygeni.
