AI Agent Registry: สร้าง Control Plane ใน 90 วัน

AI Agent Registry ไม่ใช่เพียงบัญชีรายชื่อเอเจนต์ แต่เป็นทะเบียนกลางที่เชื่อมวัตถุประสงค์ทางธุรกิจ ผู้ดูแลด้านเทคนิค ผู้รับผิดชอบทางธุรกิจ ตัวตน สิทธิ์ ช่องทางเผยแพร่ ข้อมูลที่พึ่งพา การเปลี่ยนแปลง การระงับ การเลิกใช้งาน และหลักฐานเข้าด้วยกัน เมื่อ PoC กระจายตามแผนก เอเจนต์เดียวกันมักถูกคัดลอกไปหลาย environment สิทธิ์ยังค้างหลังผู้สร้างย้ายงาน และไม่มีใครบอกได้ว่า instance ใดคือ production บทความนี้เสนอแนวทางแบบไม่ผูกกับผู้ขายสำหรับองค์กรในไทยและหลายประเทศ ตั้งแต่แบบข้อมูล RFP, PoC, แผน 90 วัน ไปจนถึงวงจรอัปเดต หยุด และปลดระวาง

ข้อสรุป: แยกทะเบียน AI Agent ออกจาก AI control plane

ใช้หลัก 6 ข้อดังนี้

1. Registry คือแหล่งข้อมูลอ้างอิงของความรับผิดชอบปัจจุบัน ส่วน control plane บังคับใช้และสังเกตการตัดสินใจขณะทำงาน
2. แยก technical owner ออกจาก business sponsor และกำหนดผู้รับผิดชอบทางธุรกิจให้ทุก production agent
3. บันทึก identity, permission, channel และ data dependency ระดับ instance เช่น development, test และ production ไม่ใช่เฉพาะชื่อ agent
4. แยก discoverable, available, deployed, pinned และการเรียกจากระบบอื่น
5. ออกแบบการเปลี่ยน ระงับ และเลิกใช้ตั้งแต่วันลงทะเบียน รวมวัน review, kill path และการเก็บหลักฐาน
6. 90 วันแรกควรพิสูจน์วงจรตั้งแต่ค้นพบถึงเลิกใช้ ไม่ใช่พยายามบังคับทุกหน่วยงานใช้ผลิตภัณฑ์เดียว

เอกสาร Microsoft ปัจจุบันวาง Agent 365 เป็น registry/control plane แบบรวมสำหรับค้นหาและจัดการ agent และให้ Microsoft Entra Agent ID เป็นฐาน identity และ access control ส่วน registry ใน Microsoft 365 admin center รวม agent ที่ Microsoft สร้าง พาร์ตเนอร์สร้าง องค์กรเผยแพร่ และผู้สร้างแชร์ไว้ในมุมมองเดียว แนวทางนี้มีประโยชน์ แต่แบบมาตรฐานของผู้ซื้อไม่ควรถูกจำกัดด้วยหน้าจอผู้ขายรายเดียว ต้องครอบคลุม cloud อื่น ระบบ on-premises, API โรงงาน, RPA, MCP server และ SaaS ธุรกิจด้วยคำศัพท์เดียวกัน

ทำไมการจัดการ AI Agent ต้องเริ่มจากทะเบียน

ทะเบียนแอปเดิมมักมีชื่อระบบ เซิร์ฟเวอร์ แผนก สัญญา และผู้ติดต่อเหตุขัดข้อง แต่ยังบอก capability จริงของ agent ไม่ได้ Agent ที่ร่างข้อความต่างจาก agent ที่ส่งอีเมล เขียน ERP ใช้สิทธิ์แทนผู้ใช้ หรือทำงานเองในเวลากลางคืนอย่างมาก

Microsoft อธิบาย agent ว่าเป็นแอปที่เข้าใจ environment/context ตัดสินใจ และใช้ tool เพื่อไปให้ถึงเป้าหมาย องค์ประกอบสำคัญคือ model, orchestration, memory และ tools เช่น web search, database, API และ file system ดังนั้นสิ่งที่ต้องลงทะเบียนไม่ใช่แค่หน้าแชต แต่รวม orchestrator, runtime identity, tool, memory, knowledge source, channel และ downstream system

Agent ที่มองไม่เห็นย่อมควบคุมไม่ได้

ตัวอย่าง shadow agent ได้แก่ agent ที่พนักงานแชร์ผ่าน Teams หรือ intranet, service identity ที่ SIer ทิ้งไว้หลัง PoC, RPA ที่เพิ่มการตัดสินใจด้วย LLM แต่ไม่ถูกจัดเป็นระบบ AI, child agent ใต้ orchestrator, job ที่ประกาศว่าเลิกใช้แล้วแต่ API key และ schedule ยังทำงาน และ dev/UAT/prod ที่ใช้ชื่อเดียวจนผู้ใช้แยกไม่ออก

Microsoft Registry แสดงแนวคิด agent ที่ไม่มี owner และ agent ที่ไม่ได้รับการจัดการ บทเรียนสำคัญจึงไม่ใช่สัญญาว่าทะเบียนจะถูกต้อง 100% ในวันแรก แต่สร้างวงจร discover → provisional registration → confirm accountability → connect controls → periodic reconciliation

รายการ identity ไม่ใช่ทะเบียนธุรกิจ

รายการ Microsoft Entra สามารถรวมทั้ง agent identity object และ agent ที่ใช้ service principal พร้อม status, Object ID, Blueprint App ID, owner/sponsor, permission, audit log และ sign-in log แต่ทะเบียนธุรกิจยังต้องมี purpose, process, audience, expected value, prohibited use, data classification, legal basis และ fallback procedure

จึงไม่ควรใช้ identity directory เป็น system of record เพียงแห่งเดียว ให้เชื่อมด้วย stable identifier Agent ที่ยังไม่มี identity ต้องถูก provisional register เป็น identity status = missing และเข้าสู่แผนแก้ไข ส่วน identity ที่มีอยู่แล้วก็ไม่ควรได้รับ production approval หากยังไม่มี purpose และ sponsor

แบบข้อมูลขั้นต่ำของ AI Agent Registry

หากบังคับกรอกมากเกินไป ทะเบียนจะล้าสมัย แยก mandatory, conditional และ evidence link พร้อมระบุเจ้าของ field และแหล่ง sync

แยก Registry ID กับ instance ID

Agent ธุรกิจหนึ่งตัวอาจมี dev, integration, UAT, production และ DR ที่ purpose เหมือนกันแต่สิทธิ์และข้อมูลต่างกัน Registry ID ระบุ logical product/use case ส่วน instance ID ระบุ runtime เช่น AGR-PROC-017 และ AGR-PROC-017-PRD-TH01 แล้วผูก Object ID, application ID และ workload identity กับ instance

แยก technical owner กับ business sponsor

โมเดล Microsoft Entra Agent ID แยก owner ซึ่งดูแล configuration, credential และ operation ออกจาก sponsor ซึ่งรับผิดชอบ purpose, access review, renewal, retention และ removal เอกสารปัจจุบันระบุว่า agent identity และ blueprint ต้องมี sponsor อย่างน้อยหนึ่งราย ขณะที่ owner เป็น optional Owner เป็น user หรือ service principal ได้แต่ไม่รองรับ group ส่วน sponsor รองรับ group บางชนิด

บันทึก delegate, succession deadline และเงื่อนไข auto-suspend เมื่อขาดผู้รับผิดชอบ แม้ใช้ sponsor group ก็ควรระบุตัวแทนที่ตัดสินใจได้จริง เอกสาร Microsoft ระบุว่าการเปลี่ยนสมาชิก dynamic group อาจใช้เวลาถึง 24 ชั่วโมงก่อนการตรวจ authorization สำเร็จ จึงไม่ควรพึ่ง group sync เพียงอย่างเดียวในเหตุฉุกเฉิน

แยก publication channel จาก permission

Teams, Outlook, Copilot, SharePoint, web, mobile, API และ batch เป็นช่องทางที่ผู้ใช้หรือระบบใช้เข้าถึง agent ช่องเดียวกันก็มีความเสี่ยงต่างกันเมื่อ audience, tenant, ประเทศ, device หรือเวลาใช้งานต่างกัน

• Discoverable: มองเห็นใน search หรือ catalog
• Available: ผู้มีสิทธิ์เพิ่มเองได้
• Deployed: admin แจกให้กลุ่มเป้าหมายแล้ว
• Pinned: แสดงในตำแหน่งเด่น
• Callable: API หรือ agent อื่นเรียกได้

API-only ไม่ใช่ “ไม่มี channel” ให้บันทึกเป็น A2A/API และบันทึก caller allowlist, delegated context, rate limit และ recursion control สำหรับ child agent

สิ่งที่ AI control plane ต้องบังคับใช้ตอน runtime

ทะเบียนที่ถูกต้องยังหยุด API call ที่สิทธิ์กว้างเกินไปไม่ได้ Control plane ต้องอ่านข้อมูลจากทะเบียนแล้วเชื่อม identity, policy, tool, data boundary, observability และ revocation อาจประกอบด้วย identity provider, API gateway, secret manager, policy engine, SIEM และ approval workflow ไม่จำเป็นต้องเป็นผลิตภัณฑ์เดียว

Identity เฉพาะและ least privilege

แนวทาง least privilege ของ Microsoft เสนอ dedicated identity, named owner/sponsor และ approver พร้อมบันทึก purpose, approved data, tool dependency และ environment กำหนดสิทธิ์ตาม resource, data และ action และ deny tool หรือ cross-tenant path ที่ยังไม่ review เป็นค่าเริ่มต้น

อย่าเขียนเพียง “เข้า ERP ได้” ให้เขียนระดับนี้

งานสิทธิ์สูงควรใช้ short-lived token, JIT หรือ action-specific approval และต้องดู aggregate effective permission เพราะหลาย role ที่ดูแคบอาจรวมกันเป็น capability กว้าง

Allowlist tool และ action

คำว่า “MCP enabled” กว้างเกินไป ต้องลงทะเบียน server, tool, action, input schema, resource, volume, timeout, retry, idempotency และ human approval Search agent ไม่ต้องมี delete Ticket agent อาจมี create/update แต่ไม่มี delete/admin งาน bulk update, external transfer, payment และ privilege change ต้องมี gate แยก

Downstream system ต้องตรวจ identity และ scope ทุกครั้ง ไม่ควรเชื่อ orchestrator อย่างเดียว ข้อความจาก AI ที่เขียนว่า “approved” ไม่ใช่หลักฐานอนุญาต ให้เชื่อม policy decision, API enforcement และ result ด้วย correlation ID เดียว

Audit trail ไม่ใช่แค่ conversation log

หลักฐานต้องมี requester, agent identity, on-behalf-of user, role, scope, tool, action, resource, policy version, approval, result, correlation ID และเวลา การเก็บ prompt ทั้งหมดโดยไม่จำกัดสร้างความเสี่ยง privacy และ secret จึงควรแยก structured event ที่ใช้ reconstruct ออกจากเนื้อหาสนทนาที่อ่อนไหว พร้อม purpose, masking, retention และ access rule

ออกแบบการหยุด 4 ชั้น

1. Discovery: ซ่อนจากผู้ใช้ใหม่
2. Invocation: ปฏิเสธ session, API call และ schedule ใหม่
3. Privilege: revoke token, rotate key, remove role และ downstream allowlist
4. Data/Lifecycle: จัดการ queue, memory, evidence, output, legal hold และ deletion

แยก incident suspension ที่ย้อนกลับได้จาก planned retirement ที่ถาวร Incident เน้น disable ทันที ส่วน retirement เน้นย้าย dependency และเก็บหลักฐาน

Roadmap 90 วันสำหรับทะเบียน AI Agent

90 วันคือจุดเริ่ม continuous governance ไม่ใช่สัญญาว่าจะ integrate ทุกอย่างครบ

วันที่ 0–15: ค้นหาและลงทะเบียนชั่วคราว

IT, security, data, procurement และ business team ตกลงคำนิยามร่วม รวมทั้งระบบที่วางแผนและเรียก tool เอง และ execution unit ที่ agent อื่นเรียก ไม่จำกัด chatbot แหล่ง discovery ได้แก่ identity directory, cloud app registration, API gateway, secret store, SaaS console, network log, contract/expense, browser extension, RPA, MCP config, repository และแบบยืนยันจากแผนก ผลอัตโนมัติควรเข้า discovered/unverified

ผลลัพธ์คือ registration standard, minimum fields, RACI, provisional list, impact tier และ missing-owner queue จัดการก่อนสำหรับ agent ที่ owner หายและมีสิทธิ์สูง แชร์ภายนอก เข้าข้อมูลลับ จ่ายเงิน หรือ delete ได้

วันที่ 16–30: ยืนยันผู้รับผิดชอบและ risk tier

กำหนด technical owner และ business sponsor แล้วตรวจ purpose, audience, channel, data, tool และ environment รายการไร้ owner ย้ายให้ temporary custodian และ suspend หากยังไม่มี sponsor เมื่อถึง deadline

วันที่ 31–45: เชื่อม registry กับ identity

ผูก instance ID กับ Object ID, service principal, workload identity และ API client วางแผนออก identity ให้รายการที่ยังไม่มี และเลิก shared credential แบบค่อยเป็นค่อยไป ห้ามใช้ identity production ร่วมกับ development

Sync อัตโนมัติเฉพาะข้อเท็จจริง เช่น status, last sign-in, credential expiry, role, owner และ channel ส่วน purpose, prohibited use, sponsor decision และ residual risk ต้องมี human approval กำหนด field owner เพื่อไม่ให้ sync ลบหลักฐานที่คนอนุมัติ

วันที่ 46–60: ทำ permission, channel และ dependency ให้เห็นภาพ

สร้างกราฟจาก agent ไป tool, data source และ downstream system รวม user delegation, managed identity, service account, webhook, batch และ queue เริ่มจาก read/write/admin แล้วแยก T3/T4 เป็น action/resource ตรวจ discoverable, available, deployed, pinned, callable, audience และ external sharing พร้อมทดสอบว่า retirement หยุด API และ schedule ได้จริง

วันที่ 61–75: ทดสอบ control plane และ stop path

เลือก agent ความเสี่ยงต่ำ กลาง สูง แล้วใช้ registry data บังคับ runtime policy ทดสอบทั้ง success และ forbidden resource, expired approval, wrong channel, other tenant, excessive volume, duplicate, missing owner และ revoked credential

ใช้คู่มือทดสอบการรับมอบ AI Agentเพื่อจัด expected, abnormal, approval และ evidence case และใช้การออกแบบปฏิบัติการ API ของ AI Agentสำหรับ monitoring, idempotency, retry และ rate limit บทความนี้เน้น portfolio registry และ lifecycle มากกว่าคุณภาพคำตอบรายกรณี

วันที่ 76–90: ตั้งวงประชุมและ KPI

รายสัปดาห์ตรวจ new registration, missing owner, expired access, sync failure และ high-risk change รายเดือนให้ sponsor ทบทวน necessity และ use รายไตรมาสหรือเมื่อเปลี่ยนสาระสำคัญทำ access review KPI ควรมีสัดส่วน production agent ที่มี unique identity, valid owner/sponsor, expiring permission พร้อมหลักฐาน, end-to-end correlation, เวลาแก้ ownerless, เวลา disable invocation/token, จำนวน agent หมดอายุที่ retire และอัตรา retest หลัง major change

ข้อกำหนด RFP สำหรับ AI Agent Registry

กำหนด capability และ deliverable ที่ทดสอบได้แทนการล็อกชื่อผลิตภัณฑ์

1. Discovery coverage: อธิบายการค้นและ deduplicate agent จาก Microsoft, SaaS อื่น, custom, on-premises, API-only, service principal, identity-less และ parent/child พร้อม delta detection
2. Data model/API: แยก logical agent กับ instance, extensible field, history, evidence link, import/export, API, webhook, stable ID และ audit retention หลังลบ
3. Accountability: แยก technical owner, business sponsor, data owner, delegate; ตรวจ workforce change; ownerless alert; deadline; group assignment; segregation of duties และ recertification
4. Identity/permission/channel: เชื่อม agent identity, service principal, workload identity, delegated user, credential, role, scope, tool action และสถานะ discoverable/deployed/pinned/callable
5. Lifecycle/change: รองรับ draft, review, approved, active, suspended, retiring, retired และตรวจ model, prompt, tool, source, permission, audience change แยกกัน
6. Audit/evidence: เก็บว่าใครเปลี่ยน field ใดจากอะไรเป็นอะไร เมื่อไร ใครอนุมัติ เชื่อม runtime log และส่ง SIEM
7. Stop/retire/exit: session deny, schedule stop, token revoke, credential rotation, role removal, queue isolation, webhook removal, manual control ตอน vendor outage, data return และ deletion proof

ขอ sample logical/instance schema, connector permission, demo ownerless/identity-less discovery, action-level allow/deny log, timed revocation test, portable export, RTO/RPO และเงื่อนไข license ทุกข้อ ฟังก์ชัน preview และ license เปลี่ยนได้ จึงต้องพิสูจน์กับ tenant และสัญญาจริงของผู้ซื้อ

เกณฑ์ PoC: ทดสอบวงจรปฏิบัติการ ไม่ใช่แค่หน้ารายการ

PoC ต้องทำครบ: ค้น unmanaged agent, provisional register, แยก owner/sponsor, ผูก dedicated ID และ expiring permission, publish เฉพาะ channel/audience ที่อนุมัติ, รัน allowed/denied action และ trace ลง downstream log, ตรวจ model/tool change แล้วส่งกลับ review, จำลอง sponsor ย้ายงาน, emergency-disable session/token/queue/schedule และยืนยันว่า retirement ลบสิทธิ์โดยยังเก็บหลักฐาน

ตัดสินจาก field completeness, sync latency, false positive/negative, permission delta, suspension time, audit reconstruction และ operational effort ข้อมูลทดสอบต้องมี duplicate name, deleted owner, missing identity, multi-instance, another tenant, shared credential และ expired approval

กฎการเปลี่ยน ระงับ และเลิกใช้

Trigger ที่ต้อง review ใหม่

• เปลี่ยน prompt อย่างเดียวโดย capability คงเดิม: owner review และ regression test
• เปลี่ยน model: ทดสอบ quality, safety และ multilingual ใหม่
• เพิ่ม tool/action: review permission, threat, audit และ revocation
• เปลี่ยน data source/storage: data owner, privacy และ cross-border approval
• ขยาย user/channel/country: sponsor, security และ legal review
• เพิ่ม autonomy, volume, amount หรือ asset scope: พิจารณาเทียบ use case ใหม่

Trigger การระงับ

owner/sponsor หาย, credential รั่ว, privilege เพิ่มผิดปกติ, audit ขาด, forbidden action สำเร็จ, data leakage สำคัญ, contract หมด และเกินกำหนด recertification ควรเป็น candidate สำหรับ automatic/emergency suspension ระบุผู้ตัดสินใจและ threshold ตั้งแต่ลงทะเบียน

เงื่อนไข retirement เสร็จสมบูรณ์

หยุด channel, shared link, endpoint และ schedule; revoke identity, token, secret, certificate, role และ membership; ถอด tool, MCP, webhook, queue และ allowlist; จัดการ memory, vector store, cache และ output ตาม retention; แจ้ง parent/child agent และผู้ใช้; เก็บ approval, last-use และ deletion proof; และยืนยันว่า discovery scan รอบถัดไปไม่พบอีก

ความผิดพลาดที่พบบ่อย

• ทำ spreadsheet ครั้งเดียวแล้วถือว่าจบ แทนที่จะ sync ข้อเท็จจริงและจัดการ expiry
• ยึด creator เป็น owner ถาวร ทั้งที่ย้ายงานและ vendor หมดสัญญา
• deduplicate ด้วย display name แทน stable ID, endpoint, credential, manifest และ tool graph
• คิดว่าซื้อ control plane แล้วได้ governance ทั้งหมด ทั้งที่ purpose, accountability และ risk acceptance ยังเป็นหน้าที่องค์กร
• คิดว่ามี log แล้ว trace ได้ ทั้งที่เวลา identity และ correlation ID ไม่เชื่อม conversation, orchestrator, tool และ downstream API

FAQ: การจัดการและทะเบียน AI Agent

AI Agent Registry คืออะไร?

คือ system of record ที่เก็บ purpose, instance, technical owner, business sponsor, identity, permission, channel, data, tool, status และ evidence ละเอียดกว่า app inventory และให้ accountability ระดับสูงกว่า runtime log

ใช้ CMDB หรือทะเบียนแอปเดิมได้หรือไม่?

ได้ หากรองรับ logical agent/instance, delegated/autonomous identity, tool action, model/prompt/memory, channel, sponsor และ review trigger ส่วนที่โมเดลเดิมแทนไม่ได้ควรเชื่อมกับ specialized registry

AI control plane ต่างจาก registry อย่างไร?

Registry บันทึกว่าอะไรมีอยู่ ใครรับผิดชอบ และอนุมัติอะไร Control plane บังคับ identity, permission, tool, policy, monitoring และ revocation ตอน runtime แม้เป็นผลิตภัณฑ์เดียวกันก็ควรประเมินสองบทบาทแยกกัน

Owner กับ business sponsor เป็นคนเดียวกันได้หรือไม่?

ใน PoC ขนาดเล็ก บุคคลเดียวอาจรับทั้งสองบทบาทได้ แต่ต้องบันทึกหน้าที่แยกกัน สำหรับ Production และงานความเสี่ยงสูง ควรแยกผู้เปลี่ยนเทคโนโลยีออกจากผู้ตัดสินความจำเป็นทางธุรกิจและความเสี่ยงคงเหลือ พร้อมกำหนดผู้แทนและผู้อนุมัติระดับสูง

Agent ที่ไม่มี identity ต้องลงทะเบียนหรือไม่?

ต้องลงเป็น identity missing และเร่งแก้ไข Discovery มาก่อน identity modernization การใช้งาน production ต่อควรมี dedicated identity, scoped access และ tested stop path

ควร review บ่อยเพียงใด?

ใช้ event trigger ร่วมกับรอบเวลา สิทธิ์สูงควรมี expiry สั้น Production ทั่วไปอาจ review รายไตรมาส และต้อง review ทันทีเมื่อ owner เปลี่ยน เพิ่ม tool เปลี่ยน data source ขยาย channel หรือเกิด incident

90 วันควบคุม agent ได้ทั้งหมดหรือไม่?

องค์กรใหญ่โดยทั่วไปยังไม่ครบ เป้าหมายคือเปิดใช้งาน definition, discovery, accountability, minimum schema, identity linkage, stop test และ governance cadence แล้วค่อยขยายโดยให้ unknown item ยังคงมองเห็นได้

สรุป: เชื่อมทะเบียนกับการปฏิบัติการที่หยุดได้จริง

คุณค่าของ AI Agent Registry ไม่ใช่รายการที่ดูสวย แต่คือความสามารถในการตอบว่าใครอธิบายความจำเป็น ใครแก้ configuration สิทธิ์และ channel ใดถูกใช้จริง ต้อง review เมื่อไร และหยุดได้ครบแค่ไหน แยก logical agent กับ instance แล้วเชื่อม technical owner, business sponsor, identity, tool action, data, channel, dependency และ evidence ส่งข้อมูลนี้ให้ AI control plane บังคับ least privilege, allow/deny, audit, suspension และ retirement ใน 90 วันแรกควรพิสูจน์ lifecycle ครบหนึ่งรอบกับ agent ความเสี่ยงสูงไม่กี่ตัวก่อนบังคับ platform เดียวทั้งองค์กร

TOMAS TECH สามารถช่วยออกแบบ schema ก่อนเลือกผลิตภัณฑ์ สำรวจ identity/API/CMDB จัดทำ RFP, PoC 90 วัน วงประชุมกำกับดูแล และทดสอบ suspension/retirement สามารถติดต่อเราได้แม้องค์กรยังไม่ทราบจำนวน agent ที่ใช้งานจริง

Primary sources

• Microsoft Learn, “Manage agent registry in Microsoft 365 admin center”: https://learn.microsoft.com/en-us/entra/agent-id/publish-agents-to-registry
• Microsoft Learn, “Agent Registry convergence with Microsoft Agent 365”: https://learn.microsoft.com/en-us/entra/agent-id/agent-registry-convergence
• Microsoft Learn, “View and filter agent identities in your tenant”: https://learn.microsoft.com/en-us/entra/agent-id/agent-lists
• Microsoft Learn, “Manage agents with no agent identities”: https://learn.microsoft.com/en-us/entra/agent-id/manage-agents-without-identity
• Microsoft Learn, “What are agent identities?”: https://learn.microsoft.com/en-us/entra/agent-id/what-are-agent-identities
• Microsoft Learn, “Add and manage owners and sponsors for agent identities and blueprints”: https://learn.microsoft.com/en-us/entra/agent-id/manage-owners-sponsors-agents
• Microsoft Learn, “Administrative relationships in Microsoft Entra Agent ID”: https://learn.microsoft.com/en-us/entra/agent-id/agent-owners-sponsors-managers
• Microsoft Learn, “Governing Agent Identities”: https://learn.microsoft.com/en-us/entra/id-governance/agent-id-governance-overview
• Microsoft Learn, “Least privilege for AI agents”: https://learn.microsoft.com/en-us/security/zero-trust/sfi/least-privilege-for-ai-agents

บทความนี้เป็นคู่มือแบบไม่ผูกกับผู้ขายจากข้อมูลปฐมภูมิที่เผยแพร่สาธารณะ ฟังก์ชัน preview, license, หน้าจอ และข้อจำกัดเปลี่ยนได้ โปรดตรวจเอกสารทางการและสัญญาปัจจุบันก่อนใช้งานจริง