Figma аюулгүй байдлын багаа AI агентаар зэвсэглэсэн нь: Аюулгүйн дохиолол шийдвэрлэх хугацааг 70% бууруулсан архитектур

Орчин үеийн программ хангамжийн дэд бүтэц томорч, микросервис болон клоуд орчин улам бүр түвэгтэй болохын хэрээр SecOps болон DevSecOps багуудын хамгийн том дайсан нь "Alert Fatigue" буюу дохиоллын хэт ачаалал болоод байна. Өдөр бүр ирэх олон мянган лог, хуурамч анхааруулга (false positives) дундаас бодит халдлагыг олж илрүүлэхэд асар их хүний нөөц шаардагддаг.

Дизайн болон хамтын ажиллагааны аварга платформ Figma өөрсдийн инженерийн багийн аюулгүй байдлын үйл ажиллагаанд бие даасан AI агентуудыг нэвтрүүлсэн туршлага, архитектурын шийдлээ дэлгэлээ. Энэхүү систем нь аюулгүй байдлын дохиоллыг (alert triage) шалгах хугацааг 70%-иар бууруулж, уламжлалт хэрэгслүүдийн анзаараагүй үлдээсэн 100 гаруй эмзэг байдлыг (үүнд 2 ноцтой Critical zero-day багтсан) бие даан илрүүлжээ.

Хөгжүүлэгчид болон DevOps инженерүүдэд хэрэг болохуйц Figma-ийн уг архитектурын гол шийдлүүдийг нарийвчлан сонирхъё.

Асуудал ба Хэрэгцээ: Хязгааргүй лог ба Он-колл (On-call) инженерийн стресс

Figma-ийн хэмжээний системд AWS, GCP, Okta, GitHub болон байгууллагын компьютеруудаас секундын дотор сая сая аудитын лог цуглардаг. Хэдийгээр Panther SIEM зэрэг орчин үеийн аюулгүйн платформууд ажиллаж байгаа ч сэжигтэй дохиолол үүсэхэд он-колл инженер дараах ажлыг гар аргаар хийх шаардлагатай болдог:

Slack сувгийн контекстийг уншиж, ямар хөгжүүлэгч тухайн үйлдлийг хийснийг тодруулах.
Okta болон AWS CloudTrail дээрх холбогдох үйлдлүүдийг гараар шүүж, өмнө нь ийм асуудал гарч байсан эсэхийг баримт бичиг болон түүхэн өгөгдлөөс хайх.
Хэрэв бодит алдаа байвал эх код дээр засвар хийж, Pull Request (PR) үүсгэх.

Энэхүү давтагддаг, механик ажлуудыг хурдасгах зорилгоор Figma-ийн инженерийн баг зөвхөн энгийн prompt ашигладаг чатбот биш, бодит хэрэгслүүдийг дуудан ажиллуулж, өөрөө шийдвэр гаргадаг бие даасан агент (Agentic System) хөгжүүлжээ.

Архитектурын цөм: 3 түвшний санах ой (Memory Hierarchy)

Figma-ийн инженерүүдийн онцолсноор AI агентын үр дүнг тодорхойлсон хамгийн гол хүчин зүйл нь том хэлний загвар (LLM) өөрөө биш, харин санах ойн зохион байгуулалт байв. Тэд санах ойг 3 тусдаа давхаргад хуваажээ:

+-------------------------------------------------------------------+
|                        Alert Triage Agent                         |
|                    (Claude Opus / Orchestrator)                   |
+---------------------------------+---------------------------------+
                                  |
         +------------------------+------------------------+
         |                        |                        |
         v                        v                        v
+------------------+     +------------------+     +------------------+
|   Case Memory    |     | Steering Memory  |     |  Schema Memory   |
| (Түүхэн кейсүүд) |     |  (Дүрэм, заавар) |     | (Өгөгдлийн бүтэц)|
+------------------+     +------------------+     +------------------+

Case Memory (Түүхэн кейсүүдийн ой санамж):
AWS Bedrock Knowledge Bases болон Amazon Kendra дээр суурилсан RAG систем. Өмнөх он-колл инженерийн шийдвэрлэсэн бүх дохиолол, Slack дээрх хэлэлцүүлэг, шалтгааны тайлангуудыг вектор сан болгон хадгална. Шинэ анхааруулга ирэхэд "Өнгөрсөн сард яг ийм IP хаягаас хандалт ирэхэд юу хийсэн бэ?" гэдгийг агшин зуур шүүн гаргаж өгдөг.
Behavioral Steering Memory (Зан төлөвийг чиглүүлэх ой санамж):
Агент хэрхэн шалгалт хийх ёстойг чиглүүлдэг dynamic бодлого. Багийн гишүүд алдаа гарсан тохиолдолд агентын зан төлөвийг засварласан тэмдэглэл үлдээж, агент дараагийн үйлдлээ уг шинэчилсэн дүрмийн дагуу гүйцэтгэдэг.
Procedural & Schema Memory (Өгөгдлийн бүтцийн ой санамж):
Snowflake болон osquery-ийн мэдээллийн сангийн бүтцийг (schema) тайлбарласан санах ой. Агент нь серверүүд болон лог сангаас өгөгдөл татахдаа алдаагүй, зөв SQL хүсэлт үүсгэхэд энэ бүтэц чухал үүрэгтэй.

Хэрэгслүүдийн хүрээ (Tool Scoping) ба Аюулгүйн хамгаалалт

AI агентад хэт өргөн эрх өгөх нь системийн аюулгүй байдалд сөргөөр нөлөөлөх эрсдэлтэй. Иймд Figma-ийн систем дараах зарчмуудаар хязгаарлагдсан байна:

Зөвхөн Унших (Read-Only) үндсэн эрх: Агент нь Panther SIEM, AWS CloudTrail, Okta, GCP зэрэг 100 гаруй систем рүү зөвхөн унших эрхтэйгээр хандаж, нөхцөл байдлыг шалгана.
Draft PR горим: Агент асуудлыг шийдвэрлэх кодын засвар бичиж чадах боловч түүний үүсгэсэн GitHub Pull Request нь автоматаар зөвхөн Draft төлөвтэй байх бөгөөд ахлах инженер заавал баталгаажуулж байж нэгтгэгдэнэ (merge).
Slack дээрх оркестраци: Агент нь он-колл инженерийн оронд бүх холбогдох логуудыг цуглуулж, Slack сувагт бүрэн шинжилгээний хураангуйг бэлдэж оруулдаг. Хэрэв аюул багатай, хуурамч дуудлага бол өөрөө түвшнийг нь (severity) бууруулж, инженерийн дуут хуудсыг (pager) 20%-иар багасгажээ.

"Recall биш, Precision-ийг эхэнд тавих": Хөгжүүлэгчдийн анхаарах чухал сургамж

Figma-ийн тайланд дурдсан хамгийн сонирхолтой туршлага бол: "Агентыг нэвтрүүлэхдээ Recall биш, Precision дээр анхаар" гэсэн зарчим юм.

Ихэнх инженерүүд аюулгүйн систем хийхдээ "Нэг ч алдаа битгий үлдээгээсэй" гэж Recall-ийг өсгөхийг зорьдог. Гэтэл энэ нь асар олон хуурамч анхааруулга (false positive) үүсгэж, хөгжүүлэгчид агентын үр дүнд итгэхээ больдог байна. Figma-ийн баг 8 долоо хоногийн турш гарсан бүх PR-ийн хуурамч анхааруулгуудыг гараар тэмдэглэж (labeling хийж), системийг сургаснаар кодын шалгалтын нарийвчлалыг (precision) анхны 15%-иас 80% хүртэл өсгөж чаджээ.

Түүнчлэн кодыг олон талаас шалгах зорилгоор Claude Code болон Codex зэрэг өөр өөр загваруудыг зэрэгцүүлэн (parallel) ажиллуулж, нэгнийхээ алдсан логик цоорхойг нөгөөгөөр нь давхар шүүдэг архитектур ашигласан байна.

Дүгнэлт

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

Аюулгүй байдлын асуудал нь хүн эсвэл AI гэсэн туйл биш, харин агентуудаар давтагддаг ачааллыг даалгаж, хамгийн эцсийн хяналтыг инженерт үлдээх зөв зааг (human-in-the-loop) дээр оршин тогтнохыг тэдний туршлага баталлаа.

Эх сурвалж: InfoQ News & Figma Engineering Blog