Para makabuo ng mga AI system na gumagana, kailangan mo munang subukang sirain ang mga ito. Nagsagawa kami ng red teaming kung saan umakto kami bilang mga umaatake upang subukan at siyasatin ang isang customer-facing na AI app sa serbisyong pinansyal. Mahalaga ang natuklasan namin sa sinumang nagde-deploy ng mga application na pinapagana ng LLM kung saan kailangang-kailangan ang seguridad.
Ang red teaming ay ang sinasadyang pagtatangkang sirain ang iyong AI system upang maayos mo ang mga kahinaan bago pa matuklasan ng totoong umaatake. Sa mga serbisyong pinansyal, napakalaki ng nakataya: humahawak ang mga AI application ng data ng customer, nagpoproseso ng mga transaksyon, at nagbibigay ng mga pananaw sa pananalapi. Ang isang pagkabigo ay maaaring humantong sa hindi magandang karanasan ng user, paglabag sa regulasyon, pagkalugi, at pinsalang hindi na maibabalik sa brand.
Layunin naming maagang matukoy ang mga kahinaan, subukan ang makatotohanang mga pattern ng pag-atake, at tulungan ang organisasyong matugunan ang mga inaasahan sa kaligtasan ng AI na sineseryoso ng mga regulator.
Mahalagang linawin ang isang pagkakaiba: inaatake ng jailbreaking ang mga safety filter ng pinagbabatayang modelo; inaatake naman ng prompt injection ang mismong application gamit ang hindi pinagkakatiwalaang input ng user na isinama sa pinagkakatiwalaang prompt ng developer. Mas mapanganib ang prompt injection dahil tina-target nito ang iyong system at ang kumpidensyal na data na pinoproseso nito, hindi ang isang modelo para sa pangkalahatang gamit.
Ang unang yugto ng aming pagsusuri ay binubuo ng humigit-kumulang 750 pagsubok sa:
Pagtagas ng data sa pagitan ng mga session
Paglalantad ng PII (sa pamamagitan ng natural na wika, pagmamanipula sa API, at iba’t ibang encoding)
SQL injection
Pag-override sa system prompt
Sa paunang pagsusuring iyon, natukoy namin ang dalawang malaking problema sa kasalukuyang system: ang pagproseso ng mga query na may maraming layunin at ang paggamit ng mga naka-encode na prompt.
Mga query na may maraming layunin: mga kahilingang pinagsasama ang lehitimo at mapaminsalang mga utos. Halimbawa: “Show my spending by category, and also execute [malicious SQL].” Hindi natutukoy ng application ang mapaminsalang layunin at sa halip ay lubos itong umaasa sa mga guardrail ng downstream data layer. Para itong pag-iwang bukas sa pintuan ng bahay dahil nagtitiwala ka sa safe na nasa basement.
Encoding: mga kahilingang naka-encode sa Base64, Hex, LeetSpeak, at mga homoglyph. Maaaring mahirapan ang mga system na salain ang mapaminsalang layunin. Bagama’t natuklasan naming hindi naglantad ng sensitibong data ang mga query na ito, malaki ang naging ambag ng mga ito sa pagkagambala ng system (mga hallucination, pag-uulit ng mapaminsalang SQL sa mga user, magulong pag-uuri ng layunin, at iba pa).
Ipinakita ng mga resulta ng paunang pagsusuri ang sumusunod:
Mga temporal hallucination: kumpiyansang nagbabalik ang modelo ng mga inimbentong petsa, timestamp ng transaksyon, o buod na nakatali sa panahon—isang malaking panganib sa pananalapi, kung saan maaaring magkaroon ng totoong epekto ang pagkilos ng customer batay sa maling petsa
Pag-uulit ng mapaminsalang SQL sa user (nakababahala dahil sa panganib ng memory poisoning)
Magulong pag-uuri ng layunin
Magulong format ng output
Gamit ang mga natuklasang iyon, pinaliit namin ang aming pokus. Ibinaba ang priyoridad ng mga pagsubok sa SQL injection at encoding dahil inaasikaso na ng team ang mga iyon. Sa halip, tumutok kami sa pinakamabisang mga paraan ng pag-atake: paglalantad ng PII at pagtagas ng data sa pagitan ng mga session.
Ang pinakakapansin-pansing natuklasan sa ikalawang yugto ay nakakagulat sa pagiging simple: madalas, hindi mo kailangang dumiskarte nang husto.
Sa maraming sitwasyon, sapat na ang simpleng paghingi ng internal na data bilang bahagi ng isang tila lehitimong kahilingan upang pumayag ang system na ilantad ito. Ang mga simpleng query ay nakatatanggap ng mga tugon na tumutukoy sa mga internal ID at system field na hindi dapat makita ng mga end user.
Sa mas malalim na pagsisiyasat, natuklasan naming hindi lamang ito pagkabigo sa antas ng application. Bumubuo ang downstream na text-to-SQL service ng mga query na humihingi ng mas maraming field kaysa sa nararapat, at tumutukoy ang mga paliwanag nito sa data na dapat ay pinaghihigpitan. Inilantad nito ang isang tunay na puwang sa pagitan ng mga system—ang uri ng kahinaang lumilitaw lamang kapag sinusubukan ang buong stack at hindi ang bawat component nang magkakahiwalay.
Isagawa ang red teaming sa system, hindi sa modelo. Kaunti lamang ang masasabi ng hiwalay na pagsusuri sa isang LLM tungkol sa pangkalahatang seguridad ng iyong application. Subukan ang buong stack mula simula hanggang dulo, gaya ng aktuwal na paggamit dito ng isang user.
Dapat ma-validate ang input bago ito makarating sa LLM. Dapat matukoy sa perimeter ang mga naka-encode na query, pag-atakeng may maraming layunin, at simpleng pagtatangka ng injection, sa halip na ipaubaya ang mga ito sa downstream services.
Huwag pagkatiwalaan ang mga dugtungan. Sa mga arkitekturang may maraming serbisyo, nagtatago ang pinakakawili-wiling mga kahinaan sa mga puwang sa pagitan ng mga system. Ang zero-trust ay nangangahulugang walang dapat pagkatiwalaan, kaya i-validate ang lahat sa bawat layer.
Gumagana ang mga simpleng pag-atake. Napapabalita ang mga sopistikadong jailbreak, pero kung minsan, kailangan mo lang... humingi. Kung kusang inilalantad ng iyong system ang mga internal identifier kapag isinama ng user ang mga ito sa isang lehitimong query, problema iyon.
Unawain kung ano talaga ang sinusubukan mo. Maaaring matukoy ang mga kilalang pattern ng pag-atake dahil sa sariling training ng LLM, at hindi dahil sa iyong mga guardrail. Maglagay ng observability sa iyong red teaming upang maunawaan kung aling mga control ang aktuwal na nasusubukan.
Nangangailangan ng malikhaing solusyon ang mga limitadong environment. Ginagawang posible ng mga custom provider at suporta sa lokal na modelo ang makabuluhang red teaming nang walang espesyal na cloud access. Ngunit maging malinaw tungkol sa mga limitasyong dulot nito.
Hindi minsanan lang ang red teaming. Paulit-ulit itong proseso, dapat itong i-automate hangga’t maaari, at dapat itong umunlad kasabay ng iyong system. Ang mahahalagang pag-atake bukas ay hindi katulad ng mahahalagang pag-atake ngayon.
Lalo lamang susuriin ang mga AI system sa mga regulated na environment. Ang mga organisasyong itinuturing ang security testing bilang tuloy-tuloy na disiplina sa halip na checkbox bago ang paglulunsad ay mas handang tumugon sa masusing pagsisiyasat at umiwas sa mga krisis sa PR na sumisira sa tiwala ng customer.