Продакшен-базаға қауіпсіз SQL-агент: readonly және лимиттер

Неліктен SQL-агент шектеусіз қауіпті

«SQL-агентті продакшен-базаға қауіпсіз» деген тіркес тек агенттің қатаң шекаралары болғанда ғана шынайы естіледі. Онсыз ол сұраққа қандай жолмен болса да жауап беруге тырысады. Модель үшін бұл қалыпты. Жұмыс істеп тұрған база үшін – жоқ.

Мәселе мынада: агент сирек бір ғана кестемен шектеледі. Адам: «Кеше неге түсім азайды?» деп сұрайды. Агент тек сатылымға ғана емес, қайтарымдарға, жеңілдіктерге, пайдаланушыларға, қолданба оқиғаларына және қызметтік журналдарға да кіріп кетуі мүмкін. Ол жауаптың толық суретін жинайды, базаны үнемдемейді. Бір сұрақ тез арада ауыр сұраулар сериясына айналады.

Тіпті бір қате де қымбатқа түседі. Егер агент күн бойынша сүзгіні ұмытып кетсе немесе дұрыс емес кестені таңдаса, ол артық деректерді оқиды. Кейде бұл миллиондаған жол. Кейде – мүлде қарамаймыз деп жоспарланған жеке деректер. Тек оқу рұқсатының өзі де тәуекелді жоймайды: жүктеме өседі, қосылымдар бітеледі, қолданбаның әдеттегі сұраулары баяулай бастайды.

Қалыпты және қауіпті мінез-құлықтың айырмасы әдетте қарапайым:

• Қалыпты: алдын ала белгілі кестелерге тар SELECT, күн бойынша сүзгі, LIMIT және түсінікті мақсат.
• Нашар: шартсыз SELECT *, «қалай болса солай» JOIN, қызметтік кестелерді оқу, бүкіл тарихты сканерлеу.
• Тіптен қауіпті: UPDATE, DELETE, INSERT, ALTER, DROP және деректерді не схеманы өзгертетін кез келген команда.

Өндірістік орта бірден зардап шегеді. Алдымен жылдамдық төмендейді: база агенттің ауыр сұрауына CPU мен жадыны жұмсайды, ал қолданушы қосымшасы баяу жауап береді. Кейін таймауттар, қосылымдар кезегі және аналитикалық агенттің бірдеңе іске қосқанын мүлде білмеген команданың шағымдары басталады.

Тағы бір байқалмайтын қауіп бар. Агент сенімді жауап бере алады, бірақ артық не сәйкес емес деректерге сүйеніп. Мысалы, ол тапсырыстар мен сессияларды қате JOIN шартымен біріктіріп, конверсияның жалған өсуін көрсете алады. Қате бірден байқалмайды, өйткені сұрау формалды түрде орындалған.

Банк, ритейл немесе телекомда бұл әсіресе жағымсыз. Ондай жерде метрикалардың жанында жиі сезімтал өрістер жатады, ал артық жүктеме жұмыс істеп тұрған сервистерге тез әсер етеді. Сондықтан тек readonly жеткіліксіз. Егер SQL сұрауларының allowlist-і, уақыт лимиттері және оқылатын дерек көлеміне шектеу болмаса, агентке тым көп еркіндік берілген.

Жақсы SQL-агент батыл болмауы керек. Ол жалықтыратын, болжамды және әр сұрауына күдікпен қарайтын болуы керек.

Қандай шектеулерді бірден қою керек

Бірінші ереже қарапайым: агент өндірістік базада ештеңені өзгертпейді. Оған тек оқу құқығы беріледі де, қауіп төндіретін командалардың бәрі бірден алынып тасталады: INSERT, UPDATE, DELETE, TRUNCATE, ALTER, DROP және басқа да DDL-операциялар. Егер агент тұжырымда қателессе, ол деректеріңізге емес, тыйымға тіреледі.

Бірақ бұл да аз. Агентке readonly режимінде де бүкіл базаны толық ашуға болмайды. Аналитика үшін әдетте бір-екі схема және бірнеше кесте не view жеткілікті. Егер қолжетімділікті толық қалдырсаңыз, агент қызметтік кестелерге, архивтерге және жауап беру үшін мүлде қажет емес деректерге кіре бастайды.

Жақсы тәжірибе – тар құқықтары бар бөлек пайдаланушы ашу. Мұндай пайдаланушы, мысалы, тек reporting.sales, reporting.orders және бірнеше анықтамалық кестені көреді. Егер базада жеке деректер болса, артық өрістерді бірден жасырып немесе агентке дерегі тазартылған бөлек view-ларды берген дұрыс.

Жүктеме көлеміне де қатаң шек керек. Агент жол саны мен жауап өлшемі бойынша лимитпен жұмыс істеуі тиіс. Әйтпесе үлкен кестеге жасалған қалыпты SELECT * жүздеген мың жолды тартып, арнаны толтырып, нәтижеден гөрі шу көбейтеді.

Әдетте төрт шектеу жеткілікті: бір жауапқа 100-1000 жолдан артық емес, кең кестелер үшін SELECT *-ке тыйым, бағандар санына лимит және тым ұзын мәтіндік өрістерді қысқарту.

Тағы бір міндетті қорғаныс – әр сұрауға таймаут. Егер сұрау бірнеше секундтан ұзақ орындалса, жүйе оны тоқтатып, түсінікті қате қайтаруы керек. Бұл базаны ауыр сканерлеулерден және фильтрсіз кездейсоқ сұраулардан қорғайды.

Қалыпты бастапқы сценарий былай көрінеді: аналитик өткен айдағы аймақтар бойынша түсімді сұрайды, агент тек рұқсат етілген кестелерге кіреді, қажет өрістерді таңдайды, 500 жолға дейін алады және 3-5 секундта аяқтайды. Егер ол үлкен архивпен JOIN жасауға тырысса немесе бүкіл анықтамалықты түгел тартып алса, жүйе сұрауды уақытпен не көлеммен кеседі.

Командалар көбіне бірдей қателеседі: промпттарды ұзақ талқылап, SQL жағындағы шектеулерге онша тиіспейді. Бұл – қате рет. Алдымен құқықтар, лимиттер және allowlist. Сосын ғана тұжырым сапасы.

Readonly қолжетімділігін қалай баптау керек

Readonly қолжетімділігін агент бір күні міндетті түрде қателеседі деп есептеп баптаған дұрыс. Сонда тіпті нашар сұраудың өзі жолдарды өшіре алмайды, тапсырыс статусын жаңарта алмайды немесе ауыр қызметтік функцияны кездейсоқ іске қоса алмайды.

Алдымен тек оқуға арналған бөлек рөл жасаңыз. Агентке аналитиктің логинін, backend есептік жазбасын немесе команданың ортақ паролін бермеңіз. Агенттің өз рөлі, өз құпиясы және өз құқықтары болуы керек. Сонда кімнің базаға кіргенін түсіну де, бірдеңе дұрыс болмаса қолжетімділікті тез өшіру де оңай.

Агентке шикі кестелерді емес, view-ларды ашқан жақсы. View ішінде артық өрістерді алдын ала алып тастап, жеке деректерді жасырып, тек жауап беру үшін керек бағандарды қалдыруға болады. Егер сату бөлімі аймақтар бойынша түсімді сұраса, агентке клиент профильдері мен ішкі пікірлер тұрған кестеге тікелей қолжетімділік қажет емес.

Құқықтардың базалық схемасы әдетте былай көрінеді:

• агент рөлі тек қажет схемаларға USAGE алады;
• SELECT тек дайындалған view-ларға беріледі;
• бастапқы кестелерге қолжетімділік жабылады;
• функцияларға EXECUTE бөлек тексеріледі және көбіне өшіріледі;
• кесте құруға, уақытша объектілерге және базаға жазуға тыйым салынады.

Функцияларға құқықты бөлек тексерген жөн. Бұл жиі кездесетін олқылық. Формалды түрде рөл readonly болуы мүмкін, бірақ иесінің құқықтарымен істейтін ескі функция деректерге, тіпті жазбаларды өзгертуге жол ашып беруі мүмкін. Егер функция агентке керек болмаса, оған қолжетімділік те болмауы тиіс.

Тағы бір әлсіз жер – ескі credential-дар. Команда агентті жаңа readonly-пайдаланушыға қосады, бірақ конфигурацияда кең құқықтары бар сервистік есептік жазбаның ескі паролі қалып қояды. Агенттің өзі ештеңені айналып өтпейді, бірақ қосымша бірнеше connection string ұстап тұрса, дұрыс емесін таңдап, оны оңай істеп бере алады.

Іске қосар алдында төрт нәрсені тексерген пайдалы: агент тек жаңа рөлмен қосыла ма, secrets пен environment variables ішінде ескі есептік жазбалар жоқ па, осы логин арқылы шикі кестелерді оқуға болмай ма, және агент атынан келген сұрау қауіпті функцияны шақыра алмай ма.

Allowlist сұраулары қалай жұмыс істейді

SQL-агентке арналған allowlist – бұл агент қандай сұрауларды құра алып, базаға жібере алатынын, ал қайсысын жүйе бірден қабылдамайтынын көрсететін нақты ережелер жиыны. Мұндай тәсіл DELETE немесе DROP сияқты қауіпті SQL-ді сөздер арқылы сүзгеннен сенімдірек. Сіз алдын ала қалыпты мінез-құлықты сипаттайсыз, ал қалғанының бәрін тыйым салынған деп санайсыз.

Әдетте аналитика үшін SELECT және оның үстіндегі бірнеше түсінікті операция жеткілікті: COUNT, SUM, AVG, MIN, MAX, GROUP BY, ORDER BY, LIMIT. Егер командаға ішкі сұраулар, UNION немесе терезелік функциялар керек болмаса, оларды «қалай болса солай» ашпаңыз. Шекара неғұрлым тар болса, тосын жағдай да соғұрлым аз болады.

Жақсы allowlist үш деңгейде жұмыс істейді. Алдымен рұқсат етілген кестелерді бекітесіз. Сосын – агент оқи алатын өрістерді. Одан кейін рұқсат етілген JOIN-дарды сипаттайсыз: қандай кестелерді қандай шартпен біріктіруге болады.

Мысалы, агентке тек orders, customers және regions кестелеріне қолжетімділік беруге болады. customers ішінде customer_id мен segment рұқсат етіліп, phone пен email тыйылады. JOIN тек orders.customer_id = customers.customer_id шартымен ашылады. Сонда сегменттер бойынша түсім туралы сұрау өтеді, ал артық жеке деректерді тартып алу әрекеті базаға жетпей-ақ ережеге тіреледі.

Қорғаныстың тағы бір қабаты – аналитикаға жиі керек емес, бірақ шекараны бұзатын құрылымдарды алып тастау. Әдетте комментарийлер, UNION, бір сұраудағы бірнеше өрнек, DDL, DML, қауіпті функцияларды шақыру және жүйелік схемаларға жүгіну бұғатталады. Комментарийлерді де кесіп тастаған дұрыс: олар арқылы фильтрді айналып өтуді жасырады және қарапайым бақылауды бұзатын қоқыс енгізеді.

Ең жиі қате – SQL-ді жол ішінен қарапайым іздеу арқылы тексеру. Бұл әлсіз жер. Агент мұндай фильтрді бос орынмен, регистрмен, комментариймен немесе ішкі құрылыммен айналып өте алады. Сенімдірек жол – сұрауды парсермен талдап, AST алып, содан кейін ғана құрылымы бойынша операция түрін, кестелер мен бағандар тізімін, JOIN түрін, қосылу шартын, рұқсат етілген функцияларды және өрнектер санын тексеру.

Егер сұрау кемінде бір ережеден өтпесе, жүйе «дерлік сәйкес» нұсқаны орындауға тырыспауы керек. Бірден түсінікті қате қайтарып, агенттен SQL-ді рұқсат етілген шеңберде қайта жинауды сұраған дұрыс. Сонда аналитика пайдалы болып қалады, ал өндірістік база тәжірибе алаңына айналмайды.

Уақыт пен жауап көлемін бақылау

Readonly қолжетімділік агент лимитсіз ауыр сұрауларды жібере алса, құтқармайды. Үлкен кестедегі бір сәтсіз JOIN немесе фильтрсіз сұрау базаның ресурсын оңай жеп, жұмыс істеп тұрған сервистерді баяулатады. Сондықтан орындау уақытын да, жауап өлшемін де бірінші күннен-ақ шектеген дұрыс, бірінші сәтсіздіктен кейін емес.

Қысқа timeout әр іске қосуға қажет. Сессияның бәріне емес, әрбір бөлек SQL-сұрауға. Аналитикалық сұрақтар үшін көбіне бірнеше секунд жеткілікті. Егер агент үлгермесе, жүйе сұрауды тоқтатып, түсінікті қате қайтарып, базаны қайта-қайта қинамауы керек.

LIMIT те әрдайым керек, сұрақ қарапайым көрінсе де. Пайдаланушы: «Төлем қатесі бар соңғы тапсырыстарды көрсет» дейді, ал модель оңай-ақ мыңдаған жолды алып келетін сұрау құра алады. Алғашқы жауап үшін шағын үзінді қайтарған дұрыс, кейін қажет болса сұрауды нақтылайсыз. Сонда аналитик суретті жылдамырақ көреді, ал база босқа жұмыс істемейді.

Әдетте мына ережелер жеткілікті:

• бір сұрауға 3-10 секунд timeout қою;
• әдепкі бойынша LIMIT қосу, мысалы 100 немесе 500 жол;
• пик жүктеме уақытында ұзақ сұрауларды тоқтату;
• сұрақты, SQL мәтінін және тоқтату себебін журналға жазу.

Журналдарды жиі бағаламайды. Олар тек инциденттерді талдау үшін емес. Солар арқылы агент қай сұрақтарды нашар түсінетінін, қандай кестелерге тым жиі тиетінін және промпттың өзі қай жерде модельді ауыр сұрауға итермелейтінін көруге болады.

Қарапайым мысал: аналитик жыл бойғы аймақтар бойынша сатылымды салыстыруды сұрайды. Агент артық өрістер мен үлкен таңдама бойынша сұрыптауы бар сұрау құрады. Timeout оны 5 секундтан кейін тоқтатады, LIMIT артық жолдарды қайтармайды, ал журнал бастапқы сұрақ пен SQL-ді сақтайды. Содан кейін команда қажетсіз сұрыптауды алып тастап, тарлау сұрау шаблонын қосады.

Мұндай шектеулерге архитектураның әдеттегі бөлігі ретінде қараған дұрыс. Бұл қосалқы тежегіш емес, негізгі қорғаныс.

Қалай кезең-кезеңімен іске қосу керек

Бастапқыда тар шеңберден бастаңыз. Агентке бірден барлық кестелер мен барлық сұрақтарға қолжетімділік бермеңіз. Команда онсыз да қолмен жасайтын бір есепті және соған арналған бір дерек көзін таңдаңыз.

Жақсы алғашқы сценарий жалықтырғыш көрінеді, бірақ бұл – плюс. Мысалы, база репликасының біреуінен күнделікті сатылым есебі: бірнеше кесте, түсінікті сүзгілер және күндер бойынша қорытынды. Тапсырма неғұрлым тар болса, агенттің қай жерде қателесетінін соғұрлым оңай байқайсыз.

Сосын allowlist-ті «бүкіл аналитикаға» емес, тек осы сценарийге арнап жинаңыз. Нақты схемаға оқуды рұқсат етіңіз, қажет өрістерді қалдырыңыз және қандай сұрау түрлері рұқсат екенін алдын ала шешіңіз. Әдетте күн бойынша сүзгі, топтастыру және жол санына лимиті бар қарапайым SELECT жеткілікті.

Кейін тест сұрақтарын деректер көшірмесінде немесе қауіпсіз репликада өткізіңіз. Тек қалыпты сұрауларды емес, ыңғайсыздарын да алыңыз: бұлыңғыр тұжырымдар, тым кең даталар, артық өрістерді сұрау әрекеттері. Үш нәрсеге қараңыз: агент қандай SQL құрады, сұрау қанша уақыт жүрді және қанша жол қайтарды.

Жұмыс тәртібі әдетте мынадай:

1. Бір есеп, бір дерек көзі, бір кестелер тобы.
2. Осы есепке арналған тар allowlist.
3. Команданың нақты сұрақтарымен дерек көшірмесінде тест.
4. Алғашқы кезеңде әр сұрауды қолмен растау.
5. Барлық компанияға емес, шағын пайдаланушылар тобына қолжетімділік.

Бастапқыда қолмен растау әдетте өзін ақтайды. Аналитик немесе инженер SQL-ді іске қоспай тұрып қарайды да, бірден күмәнді құрылымдарды ұстап қалады: артық күн аралығы, күтпеген JOIN, LIMIT жоқ таңдау. Бір аптадан кейін осындай тексерулер қай жерді қатаң тыйымдау керегін, қай жерді ашуға болатынын көрсетеді.

Сценарий сабырлы жұмыс істей бастаса, шағын топқа қол жеткізу беріңіз. Күнде пайдаланатын әрі шынайы пікір қалдыратын 3-5 адам жарайды. Мұнда жаппай қосу тек кедергі. Алдымен таза сұрау журналы, түсінікті қателер және allowlist бойынша бірнеше итерация қажет.

Егер алғашқы сценарий екі-үш апта бойы тосынсыз жұмыс істесе, келесісін қосыңыз. Бұдан бұрын емес.

Аналитика тобына арналған мысал

Сату менеджері чатқа: «Соңғы 7 күндегі сатылымды аймақтар бойынша көрсет» деп жазады. Адам үшін бұл қалыпты сұрақ. SQL-агент үшін бұл бүкіл өндірістік базаға кіріп кетуге себеп емес, тар әрі болжамды сұрау болуы тиіс.

Сондықтан агентке шикі тапсырыс, клиент және төлем кестелеріне қолжетімділік берілмейді. Ол тек бір view-ды оқиды, онда қажет өрістердің бәрі бар: күн, аймақ, сатылым сомасы және тапсырыс саны. Бұл тез әрі артық тәуекелсіз жауап беруге жетеді.

Сұрау қарапайым болады: 7 күндегі деректі таңдау, аймақ бойынша топтау және қорытынды қайтару. Агент жеке деректерді көрмейді, бір жылдық тарихқа тимейді және «қалай болса солай» көрші кестелерге кірмейді.

Практикада мұндай сценарий әдетте төрт ережеге сүйенеді: тек бір аналитикалық view-ға қолжетімділік, күн бойынша міндетті сүзгі, жол санына шектеу және қысқа таймаут.

Егер агент қателесіп тым көп жол тартып алуға тырысса, қорғаныс бірден іске қосылады. Мысалы, ол күн бойынша сүзгісіз сұрау құрады немесе әр дүкен, өнім және күн бойынша егжей-тегжей сұрайды. Жүйе не қатты лимит қосады, не сұрауды жауап бермей тұрып тоқтатады. Пайдаланушы қатқан база емес, қысқа хабарлама алады.

Кейде сұрақтың өзі тым кең болады. Менеджер: «Бүкіл сатылымды салыстыр да, қай жерде ауытқу барын тап» деп жазады. Дұрыс агент ойдан шығармайды. Ол кезеңді, метриканы және қиманы нақтылауды сұрайды: аймақтар ма, дүкендер ме, әлде санаттар ма.

Дәл осылай қауіпсіз агент әрекет етуі керек: тек қажет нәрсені оқу, артықты тартпау және сұрау бұлыңғыр болса, нақтылау сұрағын қою.

Жиі қателер

Қағаз жүзінде бәрі оңай көрінеді: тек оқу құқығын беру, бірнеше ереже қосу және агентті жұмысқа жіберу. Практикада командалар көбіне базалық нәрселерде қателеседі.

Бірінші тұзақ – агентке аналитикте бар рөлді сол күйі беру. Адам әдетте қай кестеге тимеген дұрыс екенін біледі және күмәнді сұрауды жиі байқайды. Агент мұндай ойламайды. Егер рөлде ондаған схемаға, қызметтік кестелерге және ескі витриналарға қолжетімділік болса, ол есігі ашық жердің бәріне бара береді.

Екінші қате – readonly-ға толық қорғаныс деп қарау. Ол деректерді бұзбайды, бірақ артық мәліметті оңай шығарып береді. Егер командаға тапсырыстар бойынша бір ғана есеп керек болса, сатылым, CRM және қолдау схемаларын қоса ашудың керегі жоқ. Бір витринаға немесе өрістері жасырылған бірнеше view-ға қол жеткізу жеткілікті.

Үшінші қате – SQL-ді сол күйі, сұрауды дұрыс талдамай және allowlistсіз жіберу. Онда агент ауыр JOIN құрауы, жүйелік кестелерге кіруі немесе ешкім жоспарламаған сұрауды жіберуі мүмкін. Тіпті мықты модельдің өзі, егер қолданушы сұрағы бұлыңғыр болса, кейде біртүрлі жолды таңдайды.

Төртінші қате ақша мен жүйкені жейді: командалар LIMIT, таймаут және жауап көлеміне шек қойып ұмытады. Үлкен кестеге жасалған бір сәтсіз сұрау минуттарға созылып, connection pool-ды бітеп, кейін ешкім оқымайтын көлемде жол қайтаруы мүмкін.

Тағы бір тыныш мәселе бар, ол кеш байқалады. Адамдар агенттің әдемі жауабына ғана қарап, журналдарды мүлде ашпайды. Ал тек соңғы мәтінді емес, SQL-дің өзін, орындалу уақытын, жол санын, қабылданбаған сұрауларды және рұқсат етілген шеңберден шығуға жасалған талпыныстарды да көру керек.

Жетілген баптаудың жақсы белгісін оңай тексеруге болады: агент тек бөлек readonly-рөлмен жүреді, бүкіл схеманы емес, қажетті view-ларды көреді, сервис сұрауды allowlist, LIMIT және таймаут бойынша кеседі, ал команда жауаптарды ғана емес, журналдарды да тұрақты қарап отырады.

Кішкентай мысал. Аналитиктерге күнделікті сатылым есебі керек. Команда жылдам болсын деп агентке бүкіл жұмыс рөлін аша салады. Бір күннен кейін ол он сұраққа дұрыс жауап береді, ал он бірінші сұрақта LIMIT жоқ алып шикі кестеге сұрау құрады. База құламайды, бірақ есеп тұрып қалады, dashboard баяулайды, ал себебі тек журналдардан көрінеді. Мұндай ақауларды кейін іздегеннен гөрі алдын алған оңай.

Іске қоспас бұрын қысқа тексеру тізімі

Бірінші іске қосар алдында prompt-ті емес, қолжетімділік пен шектерді тексеріңіз. Олар болмаса, агент тез арада жай ғана проблема көзіне айналады: артық деректер, ауыр сұраулар және ақаудан кейінгі ұзақ талқылаулар.

Бес тармақтан өту жеткілікті:

• Агентте тек оқу құқығы бар бөлек рөл бар. Ол бүкіл базаны емес, тек қажет кестелерді немесе, тіпті жақсысы, аналитикаға арналған дайын view-ларды көреді.
• PII бар деректер әдепкі бойынша жабық. Атаулар, телефондар, ИИН, мекенжайлар және басқа да сезімтал өрістер тек нақты сценарий үшін ашылады.
• Әр сұрауға қатаң LIMIT және таймаут беріледі.
• Журналдар бастапқы сұрақты, жасалған SQL-ді, орындалу уақытын және қате мәтінін сақтайды.
• Командада алдын ала бір адам немесе кезекшілік рөлі тағайындалады, ол ақау шықса қолжетімділікті өшіреді.

Мұны қарапайым тестпен тексерген пайдалы. Агентке үш қалыпты сұраққа, артық өрістерді сұрауға тырысқан бір сұраққа және фильтрсіз ауыр бір сұрауға жауап бергізіңіз. Егер ол барлық жерде шеңберде қалып, жауап көлемін қысқартып, түсінікті журнал жазса, іске қосу ақылға қонымды көрінеді.

Егер кемінде бір тармақ әлі жабылмаса, агентті production-ға жібермеңіз. Әуелі қолжетімділікті тарылтыңыз, лимиттерді қосыңыз және ақауға реакцияны келісіңіз. Бұл жұмыстың жалықтыратын бөлігі, бірақ кейін дәл сол сағаттар мен жүйкені үнемдейді.

Әрі қарай не істеу керек

Агентке бүкіл базаны және сұрақтардың барлық түрін бірден ашпаңыз. Жұмыс жолы қарапайым: бір сценарий алып, оны сабырлы жұмысқа жеткізіп, содан кейін келесісін қосу. Сонда логиканың қай жерде бұзылатынын, сұраулардың қай жерде шектен шығатынын және адамдарға қай жерде дерек жетіспейтінін түсіну оңайырақ.

Әдетте тәртіп мынадай: алдымен 1-2 қауіпсіз витринаға немесе view-ға қолжетімділік беріңіз, сосын аналитиктердің 20-30 нақты сұрауын тексеріңіз, одан кейін тағы бір сценарий қосыңыз, тек содан соң ғана allowlist пен кестелер жиынтығын кеңейтіңіз.

Мұндай іске қосу үлкен стартқа қарағанда әсерлі көрінбеуі мүмкін, бірақ көп жағдайда сенімдірек. Егер агент сатылым немесе тапсырыс статустары бойынша сұрақтарға сенімді жауап берсе, бұл – әлдеқашан жұмыс істеп тұрған нәтиже. Бірінші күннің өзінде оны қаржыға, жеке деректерге және шикі кестелерге жіберудің қажеті жоқ.

Бөлек PII маскингі қай жерде керек екенін және аудит-журналдарды кім оқитынын тексеріңіз. ИИН, телефон, email, мекенжай, келісімшарт нөмірі — мұның бәрін бірінші даулы есептен кейін емес, алдын ала жауып қойған дұрыс. Әр сұраудан кейін қандай із қалатынын бірден келісіп алған пайдалы: оны кім іске қосты, қай кестеге жүгінді, қанша жол алды және сұрау қанша уақыт алды.

Егер лимиттер мен журналдар әр жерде шашырап жатса, команда тез бақылаудан айырылады. Модельдерге қолжетімділік, аудит және кілт деңгейіндегі шектеулер бір контурда жиналғаны ыңғайлы, ал базаға қатысты ережелер СУБД-ның өзінде қалуы керек. Мұндай схема үшін AI Router на airouter.kz біртұтас LLM API-шлюз ретінде пайдалы болуы мүмкін: ол арқылы аудитті, rate limits-ті және модельдермен жұмысты орталықтандыру оңайырақ, бірақ readonly, allowlist және SQL-лимиттерді бәрібір базаға жақын баптау керек.

Қауіпсіз SQL-агент идеясы бір ғана readonly-пайдаланушыға сүйенбейді. Ол тәртіпке сүйенеді: бастапқыда шағын қамту, әрекеттердің түсінікті журналы, қатаң лимиттер және қолжетімділікті баяу кеңейту. Мұндай тәсіл демода сирек әсерлі көрінеді, бірақ продда артық проблема тудырмайды.