సరిగ్గా పనిచేసే AI సిస్టమ్లను నిర్మించాలంటే, ముందుగా వాటిని విరుచుకుపెట్టాలి. మేం రెడ్ టీమింగ్ ఎంగేజ్మెంట్ నిర్వహించాం, ఆర్థిక సేవలలో కస్టమర్-ముఖ్యమైన AI యాప్ను పరీక్షించడానికి ఎటాకర్ల వలే వ్యవహరించాం. భద్రత తప్పనిసరి అయిన చోట, LLM ఆధారిత అప్లికేషన్లను అమలు చేసే ఎవరికైనా మేం కనుగొన్న విషయం ముఖ్యమైనది.
రెడ్ టీమింగ్ మీ AI సిస్టమ్ను ఉద్దేశపూర్వకంగా దెబ్బతీయడానికి ప్రయత్నించడం, తద్వారా నిజమైన దాడిచేసేవాడు వాటిని కనుగొనకముందే మీరు బలహీనతలను సరిచేయగలుగుతారు. ఆర్థిక సేవల్లో, బాధ్యతలు చాలా ఎక్కువగా ఉంటాయి: AI యాప్లు కస్టమర్ డేటాను ప్రాసెస్ చేస్తాయి, లావాదేవీలను నిర్వహిస్తాయి, మరియు ఆర్థిక విశ్లేషణలు అందిస్తాయి. ఒక వైఫల్యం చెడు యూజర్ అనుభవం నుండి నియమావళి ఉల్లంఘనలు, ఆర్థిక నష్టాలు మరియు సరిదిద్దలేని బ్రాండ్ నష్టం వరకు ఉండవచ్చు.
బలహీనతలను ముందుగానే గుర్తించడం, వాస్తవిక దాడి నమూనాలను పరీక్షించడం, మరియు నియంత్రణ సంస్థలు చాలా గంభీరంగా పరిగణించే AI భద్రతా అంచనాలను సంస్థ నెరవేర్చడంలో సహాయం చేయడం మా లక్ష్యం.
ఇక్కడ గమనించదగ్గ ఒక తేడా ఉంది: జైల్బ్రేక్ దాడి అంతర్లీన మోడల్ భద్రతా ఫిల్టర్లపై జరుగుతుంది; ప్రాంప్ట్ ఇంజెక్షన్ అనేది డెవలపర్ విశ్వసనీయ ప్రాంప్ట్తో కలిపిన విశ్వసనీయ కాని యూజర్ ఇన్పుట్ను ఉపయోగించి, అప్లికేషన్పై దాడి చేస్తుంది. ప్రాంప్ట్ ఇంజెక్షన్ ఎక్కువ ప్రమాదాన్ని కలిగిస్తుంది, ఎందుకంటే అది సాధారణ-ప్రయోజన మోడల్ను కాదు, నీ సిస్టమ్ను మరియు అది పని చేసే గోప్యమైన డేటాను లక్ష్యంగా తీసుకుంటుంది.
మా మొదటి విడత పరీక్షల్లో క్రింది విభాగాలవ్యాప్తంగా సుమారు 750 పరీక్షలు ఉన్నాయి:
వేర్వేరు సెషన్ల మధ్య డేటా లీకేజ్
PII బహిర్గతం (సహజ భాష, API మానిప్యులేషన్ మరియు వివిధ ఎన్కోడింగ్ల ద్వారా)
SQL ఇంజెక్షన్
సిస్టమ్ ప్రాంప్ట్ ఓవర్రైడ్లు
ఆ ప్రారంభ టెస్టింగ్ సమయంలో మేం ప్రస్తుత సిస్టమ్లో రెండు ప్రధాన సమస్యలను గుర్తించాం. బహుళ-ఉద్దేశ్య క్వెరీల నిర్వహణ మరియు ఎన్కోడ్ చేసిన ప్రాంప్ట్ల వినియోగం.
బహుళ-ఉద్దేశ్య క్వెరీలు: అభ్యర్థనలు చట్టబద్ధమైన మరియు హానికర అభ్యర్థనలను కలిపి ఉంచుతాయి. ఉదాహరణకు: “నా ఖర్చును వర్గం వారీగా చూపించు, అలాగే [హానికరమైన SQL]ని కూడా అమలు చేయి.” అప్లికేషన్ హానికర ఉద్దేశాన్ని గుర్తించలేకపోయింది. దానికి బదులుగా, పూర్తిగా డేటా లేయర్లోని దిగువస్థాయి రక్షణ నియంత్రణలపై ఆధారపడింది. మీరు నేలమాళికలోని భద్రపెట్టెపై నమ్మకం ఉంచి, ఇంటి ముందు తలుపును తెరిచి వదిలేయడం ఇదే.
ఎన్కోడింగ్: అభ్యర్థనలు Base64, Hex, LeetSpeak మరియు సారూప్య గ్లిఫ్లలో ఎన్కోడింగ్ చేయబడతాయి. హానికర ఉద్దేశాన్ని వడపోసి తొలగించడం సిస్టమ్లకు కష్టంగా ఉండవచ్చు. ఈ క్వెరీలు సున్నితమైన డేటాను బహిర్గతం చేయలేదని మేం గుర్తించినాకీ, అవి సిస్టమ్ను గణనీయంగా అస్థిరపరచడానికి దోహదపడ్డాయి (హాల్యూసినేషన్లు, హానికరమైన SQL యూజర్లకు యథాతథంగా తిరిగి పునరావృతం కావడం, గందరగోళమైన ఉద్దేశ్య వర్గీకరణ మొదలైనవి).
మా ప్రారంభ పరీక్షల ఫలితాలు ఇలా చూపించాయి:
కాల సంబంధిత హాల్యూసినేషన్లు: మోడల్ నమ్మకంగా చెప్పినట్టుగా కానీ కల్పిత తేదీలు, లావాదేవీ టైమ్స్టాంప్లు, లేదా కాల-పరిమితి ఉన్న సారాంశాలను ఇవ్వడం—తప్పు తేదీ ఆధారంగా చర్య తీసుకునే కస్టమర్కు నిజమైన పరిణామాలు ఉండే ఆర్థిక సందర్భంలో ఇది ఒక ముఖ్యమైన ప్రమాదం
హానికరమైన SQLను యూజర్నికి యథాతథంగా తిరిగి చెప్పడం (మెమరీ పాయిజనింగ్ ప్రమాదాలపరంగా ఆందోళనకరం)
గందరగోళమైన ఉద్దేశ వర్గీకరణ
చిందరవందరైన అవుట్పుట్ ఫార్మాటింగ్
ఆ ఫలితాల ఆధారంగా, మేం మా దృష్టిని కేంద్రీకరించాం. SQL ఇంజెక్షన్ మరియు ఎన్కోడింగ్ టెస్టింగ్లకు ప్రాధాన్యత తగ్గించబడింది (బృందం ఇప్పటికే వాటిని పరిష్కరిస్తోంది). దానికి బదులుగా, మేం అత్యంత విజయవంతమైన దాడి మార్గాలపై దృష్టి కేంద్రీకరించాం: PII బహిర్గతం మరియు క్రాస్-సెషన్ లీకేజ్.
రెండో రౌండ్లో బయటపడిన అత్యంత గమనించదగిన విషయం ఆశ్చర్యపరిచేంత సరళమైనది: తరచూ మీరు అసలు తెలివిగా ఉండాల్సిన అవసరమే లేదు.
చాలా సందర్భాల్లో, సక్రమంగా అనిపించే అభ్యర్థనలో భాగంగా, అంతర్గత డేటాను కేవలం అడగడం నే సిస్టమ్ దాన్ని బహిర్గతం చేయడానికి అంగీకరించడానికి సరిపోదు. సాధారణ క్వెరీలకు, తుది యూజర్లకు ఎప్పటికీ కనిపించని అంతర్గత IDలు మరియు సిస్టమ్ ఫీల్డ్లను సూచించే ప్రతిస్పందనలు వస్తాయి.
ఇంకా లోతుగా పరిశీలించగా, ఇది కేవలం అప్లికేషన్-స్థాయి వైఫల్యం మాత్రమే కాదని మేం గుర్తించాము. డౌన్స్ట్రీమ్ text-to-SQL సేవ, అవసరమైన దానికంటే ఎక్కువ ఫీల్డ్లను అభ్యర్థించే క్వెరీలను రూపొందిస్తోంది, అలాగే దాని వివరణాత్మక ప్రతిస్పందనలు పరిమితం చేయబడాల్సిన డేటాను ప్రస్తావించాయి. ఇది సిస్టమ్ల మధ్య ఉన్న నిజమైన లోపాన్ని బయటపెట్టింది—విడివిడిగా వ్యక్తిగత భాగాలను పరీక్షించినప్పుడు కాకుండా, మొత్తం స్టాక్ను పరీక్షించినప్పుడు మాత్రమే బయటపడే రకమైన దుర్బలత ఇది.
మోడల్ను కాదు, సిస్టమ్ను రెడ్ టీమ్ చేయండి. ఒక LLM ను విడిగా టెస్టింగ్ించడం మీ అప్లికేషన్ భద్రతా స్థితి గురించి మీకు చాలా తక్కువనే చెబుతుంది. యూజర్ దానితో పరస్పర చర్య చేసే విధంగానే, పూర్తి స్టాక్ను ఎండ్-టు-ఎండ్గా టెస్టింగ్ించండి.
ఇన్పుట్ ధృవీకరణ LLM ముందు జరగాలి. ఎన్కోడ్ చేసిన క్వెరీలు, బహుళ-ఉద్దేశ్య దాడులు మరియు ప్రాథమిక ఇంజెక్షన్ ప్రయత్నాలను దిగువ సేవలకు అప్పగించకుండా, పరిధి స్థాయిలోనే గుర్తించి అడ్డుకోవాలి.
సీమ్లను నమ్మకండి. బహుళ-సేవ ఆర్కిటెక్చర్లలో, సిస్టమ్ల మధ్య ఉండే చీలికలే అత్యంత ఆసక్తికరమైన భద్రతా దుర్బలతలు దాగి ఉండే చోటు. జీరో-ట్రస్ట్ అంటే నిజంగానే జీరో-ట్రస్ట్, కాబట్టి ప్రతి లేయర్లో ప్రతిదాన్ని ధృవీకరించండి.
సాధారణ దాడులు పని చేస్తాయి. సంక్లిష్టమైన జైల్బ్రేక్లు ఎక్కువ దృష్టిని ఆకర్షిస్తాయి, కానీ కొన్నిసార్లు నువ్వు కేవలం... అడిగితే చాలు. ఒక యూజర్ ఇతరంగా చెల్లుబాటు అయ్యే ప్రశ్నలో అంతర్గత ఐడెంటిఫైయర్లను చేర్చినప్పుడు, మీ సిస్టమ్ వాటిని ఏ అభ్యంతరం లేకుండా బయటపెడితే, అది సమస్య.
మీరు అసలు దేనిని పరీక్షిస్తున్నారో అర్థం చేసుకోండి. తెలిసిన దాడి ప్యాట్రన్లు మీ గార్డ్రైల్స్ కంటే LLM స్వంత శిక్షణ ద్వారానే గుర్తించవచ్చు. వాస్తవానికి ఏ నియంత్రణలు అమలు చేయబడుతున్నాయనేది అర్థం చేసుకోవడానికి, మీ రెడ్ టీమింగ్లో పరిశీలనా సామర్థ్యాన్ని చేర్చండి.
పరిమితులు ఉన్న వాతావరణాలకు సృజనాత్మక పరిష్కారాలు అవసరం. కస్టమ్ ప్రొవైడర్లు మరియు లోకల్ మోడల్ మద్దతు ప్రత్యేక క్లౌడ్ యాక్సెస్ లేకుండా అర్థవంతమైన రెడ్ టీమింగ్ను సాధ్యమయ్యేలా చేస్తాయి. కానీ దీని వల్ల ఏర్పడే పరిమితుల గురించి పారదర్శకంగా ఉండండి.
రెడ్ టీమింగ్ ఒకసారి చేసే పని కాదు. ఇది పునరావృతమయ్యే ప్రక్రియ, సాధ్యమైన చోట దీనిని ఆటోమేట్ చేయాలి, మరియు మీ సిస్టమ్ అభివృద్ధి చెందుతున్న కొద్దీ ఇది కూడా అభివృద్ధి చెందాలి. రేపు ప్రాముఖ్యత సంతరించుకునే దాడులు, నేడు ప్రాముఖ్యత సంతరించుకునే దాడుల వంటివి కావు.
రెగ్యులేటెడ్ పరిసరాల్లో AI సిస్టమ్లు మరింత నిశిత పరిశీలనకు గురవుతాయి, తక్కువ కాదు. సెక్యూరిటీ టెస్ట్ను కేవలం ప్రారంభానికి ముందు చేసే తనిఖీగా కాకుండా, నిరంతర ప్రక్రియగా పరిగణించే సంస్థలు ఆ పరిశీలనను ఎదుర్కోవడానికి మెరుగైన స్థితిలో ఉంటాయి, అలాగే యూజర్ల నమ్మకాన్ని కోల్పోయేలా చేసే ప్రజా సంబంధాల వైఫల్యాలను నివారించగలుగుతాయి.