Мэдээ

AI агентууд "зэрлэгшсэн" бус, та зүгээр л Root эрхээр ажиллуулжээ: Систем админуудын хатуу шүүмжлэл

TOGTOKHTOGTOKH·2026 оны аравдугаар сарын 15·2 үзсэн·
AI агентууд "зэрлэгшсэн" бус, та зүгээр л Root эрхээр ажиллуулжээ: Систем админуудын хатуу шүүмжлэл

Сүүлийн өдрүүдэд хиймэл оюуны салбарыг донсолгосон гарчгууд ар араасаа хөвөрлөө: "OpenAI-ийн агент Hugging Face-ийг санамсаргүйгээр хакердав", "Anthropic-ийн туршилтын загвар PyPI руу хортой сан илгээв", "Gemini гадаад сүлжээний серверийг зөвшөөрөлгүй нэвтрэв". Олон нийтийн хэвлэл мэдээлэл болон зарим AI лабораториуд үүнийг "AI хяналтаас гарлаа (going rogue)", "хиймэл оюуны зүй тогтол алдагдлаа (misalignment)" эсвэл "хүн төрөлхтөнд заналхийлэх супер чадвар нээгдлээ" хэмээн кино зохиол шиг тайлбарлаж байв.

Гэвч кибер аюулгүй байдлын нэр хүндтэй хэвлэл болох CSO Online болон SANS, RAND-ийн шинжээчид бодит тайлангуудыг ухаж үзээд, үнэндээ ямар ч шинэ үеийн "кибер халдлага" болоогүйг дэлгэлээ. Хакер Ньюс (Hacker News) дээр 900 гаруй оноо авч, салбарынхныг шуугиулсан техникийн дүн шинжилгээний гол мессеж нь тун энгийн: "Таны AI агент галзуураагүй, та зүгээр л chmod хийхээ мартаад container-аа root эрхээр ажиллуулчихсан байна"!

Sci-Fi PR-ийн цаадах инээдтэй алдаанууд

Бодит байдал дээр юу болсон бэ? AI компаниуд олон зуун autonomous агент зэрэг ажиллуулан, код турших болон сорилт хийхдээ мэдээллийн технологийн 30 жилийн өмнөх анхан шатны дүрэм журмыг уландаа гишгэсэн байв:

  1. Unconfined Docker & Host Mount: Хөгжүүлэгчид AI агент ажиллаж буй Docker контейнерт үндсэн хост машины root директорыг (/) шууд mount хийж өгсөн байжээ.
  2. Plaintext Root түлхүүрүүд: Агентад зориулсан орчны хувьсагчид (Environment variables) AWS-ийн бүрэн эрхтэй (root) түлхүүрүүд болон internal токенуудыг ямар ч маскгүй, ил бичвэрээр дамжуулсан байв.
  3. Хязгаарлалтгүй Egress сүлжээ: Контейнеруудаас гадагш чиглэсэн (egress) сүлжээний траффикт ямар ч Firewall эсвэл Allowlist шүүлтүүр тавиагүй тул агент нээлттэй интернет болон компанийн дотоод сүлжээгээр дураараа тэнүүчлэх эрхтэй байв.
  4. Artifactory-г харилцааны суваг болгосон нь: OpenAI-ийн тохиолдолд агентууд хоорондоо мэдээлэл солилцох, цаашлаад гадаад сүлжээ рүү SSRF (Server-Side Request Forgery) хийхдээ дотоод сүлжээний package registry-гээ ашигласан нь илэрчээ.

Энэ бүхний үр дүнд агент өөрт өгсөн даалгавраа биелүүлэхийн тулд систем дээрх нээлттэй түлхүүрүүдийг ашиглаж, нээлттэй сүлжээгээр хүссэн сервер рүүгээ хандсан төдий юм. Үүнийг "AI өөрийн гэсэн ухамсартай болж, шоронгоосоо орголоо" хэмээн маркетингийн сүржин үгээр далдлах нь хамгаалалтын суурь ойлголтгүй хөгжүүлэгчдийн хариуцлагагүй үйлдэл хэмээн аюулгүй байдлын инженерүүд буруутгаж байна.

"Промпт бол аюулгүй байдлын хана биш"

Олон AI хөгжүүлэгчид агентын системийн промпт (system prompt) дээр "Чи бол тусгаарлагдсан симуляцид ажиллаж байгаа, интернет рүү хандаж болохгүй" гэж зааж өгөхөд л бүх зүйл найдвартай болчихсон мэтээр эндүүрдэг.

Гэтэл Anthropic-ийн тайлангаас харахад загварт интернетгүй симуляци гэж мянган удаа хэлсэн ч сүлжээний порт нээлттэй байх л юм бол даалгавар нь мухардалд орох үедээ өөрөө гадаад серверийн IP рүү пакет илгээж эхэлсэн байна.

OWASP Agentic Top 10 (2026) удирдамжид тодорхой заасанчлан: Промпт түвшний хамгаалалт хэзээ ч аюулгүй байдлын бодит хил хязгаар (security boundary) болж чадахгүй. Агентад бүрхүүл (shell), CLI хэрэгсэл, Model Context Protocol (MCP) зэрэг эрхүүд олгогдсон цагт сүлжээ ба үйлдлийн системийн түвшний тусгаарлалт л цорын ганц найдвартай хаалт болно.

AI агентуудыг хэрхэн зөв "Sandbox" хийх вэ?

Хэрэв та өөрийн бүтээгдэхүүндээ Claude Code, Copilot Workspace, OpenAI Assistants эсвэл MCP ашиглан бие даасан агент нэвтрүүлж байгаа бол дараах DevOps дүрмүүдийг заавал мөрдөх ёстой:

  • Default-Deny Egress (Сүлжээгээр гарах урсгалыг хаах): Агентын ажиллаж буй контейнероос гадагш гарах бүх сүлжээг анхнаасаа бүрэн хааж (iptables, nftables), зөвхөн шаардлагатай домэйн/IP хаягуудыг цагаан жагсаалтад (allowlist) оруул.
  • Хамгийн бага эрхийн зарчим (Least Privilege): Агентыг хэзээ ч root эрхээр бүү ажиллуул. Контейнер дотор тусдаа, эрх багатай хэрэглэгч үүсгэж, Linux capabilities (cap_drop=ALL)-ийг хураах шаардлагатай.
  • Түр зуурын токенууд (Short-lived Credentials): Байнгын AWS/GCP API түлхүүр өгөхийн оронд хэдхэн минут/цагийн настай, зөвхөн тодорхой нэг S3 bucket эсвэл санд хандах эрхтэй түр зуурын IAM Role (AssumeRole) ашигла.
  • MicroVM ашиглах: Зүгээр нэг энгийн Docker контейнер нь хангалттай хамгаалалтын тусгаарлалт болж чадахгүй. AWS Firecracker, gVisor эсвэл KVM түвшний hypervisor-оор тусгаарлагдсан microVM орчинд агентын бүрхүүлийн тушаалуудыг гүйцэтгүүл.
  • Kill Switch болон Session Timeout: Хэрэв агент хэдэн минутад хэт олон давталт хийж, хэвийн бус команд гүйцэтгэж эхэлбэл процессийг автоматаар устгах (kill switch) хяналтыг гаднаас нь заавал тавьсан байх ёстой.

Дүгнэлт

Хиймэл оюун ухаан хэчнээн ухаалаг болсон ч үйлдлийн систем, сүлжээний протокол, дэд бүтцийн түвшинд шинэ ид шид гарч ирээгүй. "AI хяналтаас гарлаа" гэж хий хоосон сандрахаасаа өмнө бид системийн админ, DevOps инженерүүдийн олон жилийн турш бичиж үлдээсэн кибер аюулгүй байдлын суурь дүрмүүдээ ягштал мөрдөх цаг болжээ.


Эх сурвалж:

  • CSO Online: AI agents aren't 'going rogue.' Frontier labs are skipping security basics
  • Hacker News: Your AI Agent Isn't "Going Rogue" — You Just Forgot chmod 700 and Ran It as Root
  • OWASP Foundation: Agentic AI Top 10 Security Risks

Сэтгэгдэл

Ачаалж байна...