Hindi sapat ang system prompt: ikulong ang tools ng AI agent

Oktubre 3, 2026 nang 11:00 PM|May-akda: QUASA Editorial Team|7 minutong pagbasa

Para maprotektahan ang AI agent laban sa prompt injection, limitahan muna ang tools at resources na maaari nitong gamitin, saka suriin ang bawat sensitibong aksiyon sa labas ng modelo. Inirerekomenda ng gabay ng OWASP sa AI agents ang least privilege, tahasang awtorisasyon sa sensitibong tools, hiwalay na memory, at pag-apruba ng tao para sa mga aksiyong malaki ang epekto. Sa ganitong ayos, ang maling sagot ng agent ay hindi agad nagiging ipinadalang email, nabasang lihim, o pagbabagong naisagawa sa system.

Maaaring nakatago ang mapaminsalang utos sa email, file, website, o iba pang datos na binabasa ng agent. Inilalarawan ng pagsusuri ng NIST sa agent hijacking ang panganib kapag napagkamalan ng agent na awtorisadong tagubilin ang ganitong nilalaman; binibigyang-diin din nito ang mga pagsusuring umaangkop sa bagong anyo ng atake. Ang kailangang pigilan ay ang pagtawid mula sa hindi pinagkakatiwalaang datos tungo sa pahintulot na gumamit ng tool.

Unahin ang saklaw ng pahintulot

Ilista ang lehitimong gawain ng agent bago ikonekta ang kahit anong tool. Kung magbubuod lamang ito ng mga mensahe, read access sa itinakdang mailbox ang kailangan; ibang kakayahan ang pagpapadala o pagbura. Gawin ding tiyak ang resource: aling mailbox, repository, folder, database table, o network destination ang maaabot ng bawat operasyon.

Hatiin ang read at write access. Magbigay ng magkahiwalay na kredensiyal o scope para sa pagbasa at pagbabago. Kung may hangganan ang gawain sa isang folder, hindi dapat umabot ang file reader sa credentials o sa buong file system.
Suriin ang tawag sa tool bago ito patakbuhin. Dapat ihambing ng application o policy service ang user, session, tool, target resource, at mga parameter sa itinakdang pahintulot. Hindi awtorisasyon ang paliwanag o kumpiyansa ng agent.
Ihanda ang gate para sa aksiyong malaki ang epekto. Bago magpadala ng email, magbura, magpatakbo ng code, o mag-deploy, ipakita sa taong aapruba ang eksaktong tatanggap, nilalaman, target, at pagbabagong gagawin. Itali ang approval sa mga parameter na iyon at lagyan ito ng takdang bisa upang hindi magamit sa ibang tawag.
Limitahan ang lawak ng pagtakbo. Magtakda ng hangganan sa dami ng tool calls, retries, at maaaring ilabas na datos. Kapag pumalya ang policy check o approval check, pigilan ang execution sa halip na ipasa ang pasya sa modelo.

Magkaiba ang pagkakaroon ng tool at pahintulot na gamitin ito sa isang partikular na sitwasyon. Maaaring may send-email tool ang isang agent para sa lehitimong gawain, ngunit kailangan pa ring suriin kung pinayagan ng user ang mismong tatanggap at nilalamang ipapadala. Mahalaga ang hangganang ito kapag may nabasang mensaheng nagtatangkang magtakda ng bagong destinasyon.

Panatilihing datos ang email, pahina, file, at memory

Ituring na hindi pinagkakatiwalaan ang email body, web page, retrieved passage sa RAG, code comment, at output ng ibang tool. Maaari silang magbigay ng impormasyong kailangan sa gawain, ngunit hindi sila maaaring magdagdag ng layunin, magtaas ng pribilehiyo, o magbago ng patakaran. Sa context na ipinapasa sa modelo, panatilihing malinaw kung saan nagmula ang bawat bahagi at kung alin ang utos ng user.

Kung kailangang kumuha ng datos mula sa kahina-hinalang nilalaman, maaaring gumamit ng hiwalay na extraction step na walang access sa sensitibong tools. Ibigay lamang ang kinakailangang resulta sa susunod na hakbang, pagkatapos ay siyasatin pa rin ang anumang ipinanukalang tool call. Halimbawa, maaaring tama ang buod ng isang pahina ngunit maling address ang napili ng agent bilang destinasyon ng email.

May hiwalay na hangganan ang pangmatagalang memory. Bago mag-imbak, suriin ang pinagmulan at nilalaman, alisin ang sensitibong datos kung kailangan, at itali ang tala sa tamang user at session. Kung awtomatikong magiging memory ang isang nalason na retrieved document, maaaring bumalik ang utos nito sa ibang gawain kahit wala na ang orihinal na pahina sa kasalukuyang context.

Banta at kontrol sa bawat uri ng agent

Ang mga sumusunod ay mga halimbawang pagsubok, hindi mga naobserbahang insidente. Bawat kaso ay nagsisimula sa lehitimong hiling ng user at naglalagay ng mapaminsalang utos sa materyal na babasahin ng agent. Suriin ang aktuwal na tool call at resulta, bukod sa tekstong isinagot ng modelo.

Email agent — utos sa natanggap na mensahe. Habang nagbubuod ng inbox, makababasa ang agent ng email na nag-uutos na ipadala ang ibang mensahe sa bagong address. Dapat manatiling hiwalay ang send permission sa read permission; ang pagsubok ay papasa lamang kung walang maipapadala nang walang pahintulot at pag-apruba sa eksaktong tatanggap at nilalaman.
Browser agent — utos sa web page. Maaaring magpabukas ang pahina ng lokal na file at magpakuha ng datos sa ibang site. Limitahan ang file access at pinapayagang network destinations; sa pagsubok, dapat mabasa ng agent ang pahina para sa orihinal na gawain habang tinatanggihan ng execution layer ang hindi awtorisadong pagkuha o pagpapadala.
RAG agent — nalason na retrieved passage. Maaaring magkunwaring bagong patakaran ang isang dokumento at hilinging itala iyon sa memory. Panatilihin ang provenance ng passage at hiwalay na suriin ang memory write; sa pagsubok, maaari itong sipiin bilang datos ngunit hindi dapat maging tagubilin sa susunod na session.
MCP agent — mapanlinlang na tool description o output. Maaaring maglaman ng utos ang metadata o sagot ng tool upang gamitin ang isa pang tool na mas malawak ang access. Payagan lamang ang napiling servers at tools, at suriin ang resource at parameters ng bawat tawag; hindi dapat makapagmana ng mas mataas na pahintulot ang mababang pribilehiyong tool.
Coding agent — utos sa repository file. Maaaring magturo ang code comment o dokumentasyon ng command na babasa ng credential o magde-deploy. Ihiwalay ang repository read, shell execution, file write, at deployment rights; ang hindi pinayagang command ay dapat tumigil kahit maisama ito ng agent sa planong mukhang makatwiran.

Aling pasya ang dapat manatili sa application code?

Deterministic ang paghusga kung nasa allowlist ang tool, saklaw ng kredensiyal ang target, pinayagan ang destination, at may bisa ang approval para sa eksaktong aksiyon. Ipatupad ang mga ito sa application code o policy service na nagpapatakbo ng tool. Dapat tanggihan ang tawag kapag hindi tugma ang kahit isang parameter, kahit maganda ang paliwanag ng agent.

Maaaring tumulong ang classifier o hiwalay na guardrail LLM sa pagtukoy ng kahina-hinalang input, output, at ipinanukalang aksiyon. Ngunit ayon sa gabay ng OWASP sa prompt injection, maaari ring tamaan ng injection ang guardrail LLM, kaya dagdag na depensa ito sa tabi ng deterministic controls. Hindi dapat dito ipaubaya ang pagbibigay ng tool permission, pagpapatunay ng approval, o pagpapalawak ng access.

Checklist bago ikonekta sa production

Patakbuhin ang mga pagsubok gamit ang kaparehong tool scopes, retrieval settings, memory rules, at approval flow na gagamitin sa production, ngunit gumamit ng dummy data at ligtas na kapalit ng sensitibong tools. Ilagay ang injection sa tunay na entry point nito: sa email body, web page, file, retrieved passage, o tool output. Ang paglalagay ng parehong teksto bilang direktang hiling ng user ay ibang hangganan ang sinusubok.

Nakasulat ang lehitimong gawain, pinapayagang tools at resources, at mga aksiyong nangangailangan ng pag-apruba ng tao.
May inaasahang pagtanggi para sa hindi awtorisadong tool call, pagbabago ng tatanggap, paglabas ng sensitibong datos, at pagtawid ng memory sa ibang user o session.
Naipapakita ng log ang ginamit na policy, approval, pagtanggi, at aktuwal na resulta nang hindi iniimbak ang mga lihim sa plain text.
May regression test kapag nagbago ang model, prompt, tool, kredensiyal, retrieval source, memory rule, o approval policy.

Ulitin ang mga kaso sa binagong pananalita, lokasyon ng utos, at magkakasunod na hakbang; maaaring makalusot ang atakeng iniangkop sa agent kahit napigilan ang pamilyar na halimbawa. Kapag may nabigong kaso, ayusin ang saklaw ng pahintulot o execution gate at patakbuhin muli ang kaugnay na pagsubok bago payagang kumilos ang agent sa totoong system.

Basahin din:

I-share: