---
read_when:
    - การดีบักข้อผิดพลาดขอบเขตของโอเปอเรเตอร์ที่ขาดหายไป
    - การตรวจสอบการอนุมัติการจับคู่อุปกรณ์หรือ Node
    - การเพิ่มหรือจัดประเภทเมธอด RPC ของ Gateway
summary: บทบาทของผู้ปฏิบัติการ ขอบเขต และการตรวจสอบขณะอนุมัติสำหรับไคลเอนต์ Gateway
title: ขอบเขตของผู้ปฏิบัติการ
x-i18n:
    generated_at: "2026-05-04T02:25:17Z"
    model: gpt-5.5
    provider: openai
    source_hash: f05d6bdbf9bdad2aef1c9664bb7ebb4b6241334b8aefac7993104e9977e40450
    source_path: gateway/operator-scopes.md
    workflow: 16
---

ขอบเขตของ operator กำหนดว่าไคลเอนต์ Gateway ทำอะไรได้บ้างหลังจากยืนยันตัวตนแล้ว
ขอบเขตเหล่านี้เป็นราวกันตกของระนาบควบคุมภายในโดเมนผู้ปฏิบัติการ Gateway ที่เชื่อถือได้หนึ่งโดเมน
ไม่ใช่การแยกแบบหลายผู้เช่าที่ต้านทานผู้ไม่ประสงค์ดี หากคุณต้องการการแยกที่เข้มแข็งระหว่าง
บุคคล ทีม หรือเครื่อง ให้รัน Gateway แยกกันภายใต้ผู้ใช้ OS หรือ
โฮสต์ที่แยกกัน

ที่เกี่ยวข้อง: [ความปลอดภัย](/th/gateway/security), [โปรโตคอล Gateway](/th/gateway/protocol),
[การจับคู่ Gateway](/th/gateway/pairing), [CLI สำหรับอุปกรณ์](/th/cli/devices).

## บทบาท

ไคลเอนต์ WebSocket ของ Gateway เชื่อมต่อด้วยหนึ่งบทบาท:

- `operator`: ไคลเอนต์ระนาบควบคุม เช่น CLI, Control UI, ระบบอัตโนมัติ และ
  โพรเซสตัวช่วยที่เชื่อถือได้
- `node`: โฮสต์ความสามารถ เช่น macOS, iOS, Android หรือโหนดแบบไม่มีส่วนติดต่อผู้ใช้ที่
  เปิดคำสั่งผ่าน `node.invoke`

เมธอด RPC ของ operator ต้องใช้บทบาท `operator` เมธอดที่มีต้นทางจาก Node
ต้องใช้บทบาท `node`

## ระดับขอบเขต

| ขอบเขต                   | ความหมาย                                                                                                                                                                               |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `operator.read`         | สถานะ รายการ แค็ตตาล็อก บันทึก การอ่านเซสชัน และการเรียกระนาบควบคุมอื่นๆ ที่ไม่เปลี่ยนแปลงข้อมูลแบบอ่านอย่างเดียว                                                                                    |
| `operator.write`        | การกระทำของ operator ที่เปลี่ยนแปลงข้อมูลตามปกติ เช่น การส่งข้อความ การเรียกใช้เครื่องมือ การอัปเดตการตั้งค่าการพูดคุย/เสียง และการส่งต่อคำสั่งของ Node รวมถึงผ่านเงื่อนไข `operator.read` ด้วย                      |
| `operator.admin`        | การเข้าถึงระนาบควบคุมเชิงดูแลระบบ ผ่านเงื่อนไขทุกขอบเขต `operator.*` จำเป็นสำหรับการเปลี่ยนแปลง config, การอัปเดต, native hooks, namespace ที่สงวนไว้และอ่อนไหว และการอนุมัติที่มีความเสี่ยงสูง |
| `operator.pairing`      | การจัดการการจับคู่อุปกรณ์และ Node รวมถึงการแสดงรายการ การอนุมัติ การปฏิเสธ การลบ การหมุนเวียน และการเพิกถอนระเบียนการจับคู่หรือโทเคนอุปกรณ์                                       |
| `operator.approvals`    | API การอนุมัติ exec และ Plugin                                                                                                                                                        |
| `operator.talk.secrets` | การอ่านการกำหนดค่า Talk โดยรวม secrets                                                                                                                                     |

ขอบเขต `operator.*` ที่ไม่รู้จักในอนาคตต้องตรงกันทุกประการ เว้นแต่ผู้เรียกจะมี
`operator.admin`

## ขอบเขตของเมธอดเป็นเพียงด่านแรก

RPC แต่ละรายการของ Gateway มีขอบเขตเมธอดแบบสิทธิ์น้อยที่สุด ขอบเขตเมธอดนั้นตัดสินว่า
คำขอจะไปถึง handler ได้หรือไม่ จากนั้น handler บางรายการจะใช้การตรวจสอบที่เข้มงวดยิ่งขึ้น
ในเวลาที่อนุมัติ โดยอิงจากสิ่งที่กำลังถูกอนุมัติหรือเปลี่ยนแปลงจริง

ตัวอย่าง:

- `device.pair.approve` เข้าถึงได้ด้วย `operator.pairing` แต่การอนุมัติ
  อุปกรณ์ operator สามารถ mint หรือคงไว้เฉพาะขอบเขตที่ผู้เรียกมีอยู่แล้วเท่านั้น
- `node.pair.approve` เข้าถึงได้ด้วย `operator.pairing` จากนั้นอนุมาน
  ขอบเขตการอนุมัติเพิ่มเติมจากรายการคำสั่ง Node ที่รอดำเนินการ
- `chat.send` โดยปกติเป็นเมธอดในขอบเขตเขียน แต่ `/config set`
  และ `/config unset` แบบถาวรต้องใช้ `operator.admin` ที่ระดับคำสั่ง

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

## การอนุมัติการจับคู่อุปกรณ์

ระเบียนการจับคู่อุปกรณ์เป็นแหล่งข้อมูลถาวรของบทบาทและขอบเขตที่ได้รับอนุมัติ
อุปกรณ์ที่จับคู่แล้วจะไม่ได้รับการเข้าถึงที่กว้างขึ้นอย่างเงียบๆ: การเชื่อมต่อซ้ำที่ขอ
บทบาทที่กว้างขึ้นหรือขอบเขตที่กว้างขึ้นจะสร้างคำขออัปเกรดใหม่ที่รอดำเนินการ

เมื่ออนุมัติคำขออุปกรณ์:

- คำขอที่ไม่มีบทบาท operator ไม่จำเป็นต้องมีการอนุมัติขอบเขตโทเคนของ operator
- คำขอสำหรับ `operator.read`, `operator.write`, `operator.approvals`,
  `operator.pairing` หรือ `operator.talk.secrets` ต้องให้ผู้เรียกถือ
  ขอบเขตเหล่านั้น หรือ `operator.admin`
- คำขอสำหรับ `operator.admin` ต้องใช้ `operator.admin`
- คำขอซ่อมแซมที่ไม่มีขอบเขตชัดเจนสามารถสืบทอดขอบเขตโทเคน operator
  ที่มีอยู่ได้ หากโทเคนที่มีอยู่นั้นมีขอบเขต admin การอนุมัติยังคงต้องใช้
  `operator.admin`

สำหรับเซสชันโทเคนอุปกรณ์ที่จับคู่แล้ว การจัดการจะจำกัดอยู่กับตัวเอง เว้นแต่ผู้เรียก
จะมี `operator.admin` ด้วย: ผู้เรียกที่ไม่ใช่ admin จะเห็นเฉพาะรายการการจับคู่ของตนเอง
สามารถอนุมัติหรือปฏิเสธได้เฉพาะคำขอที่รอดำเนินการของตนเอง และสามารถหมุนเวียน เพิกถอน หรือ
ลบได้เฉพาะรายการอุปกรณ์ของตนเอง

## การอนุมัติการจับคู่ Node

`node.pair.*` แบบเดิมใช้คลังการจับคู่ Node ที่ Gateway เป็นเจ้าของแยกต่างหาก โหนด WS
ใช้การจับคู่อุปกรณ์ด้วย `role: node` แต่คำศัพท์ระดับการอนุมัติเดียวกัน
ยังคงใช้ได้

`node.pair.approve` ใช้รายการคำสั่งของคำขอที่รอดำเนินการเพื่ออนุมาน
ขอบเขตเพิ่มเติมที่จำเป็น:

- คำขอที่ไม่มีคำสั่ง: `operator.pairing`
- คำสั่ง Node ที่ไม่ใช่ exec: `operator.pairing` + `operator.write`
- `system.run`, `system.run.prepare` หรือ `system.which`:
  `operator.pairing` + `operator.admin`

การจับคู่ Node สร้างตัวตนและความเชื่อถือ ไม่ได้แทนที่นโยบายการอนุมัติ exec
`system.run` ของ Node เอง

## การยืนยันตัวตนด้วย shared-secret

การยืนยันตัวตนด้วยโทเคน/รหัสผ่าน Gateway แบบ shared gateway ถือเป็นการเข้าถึง operator ที่เชื่อถือได้สำหรับ
Gateway นั้น พื้นผิว HTTP ที่เข้ากันได้กับ OpenAI และ `/tools/invoke` จะคืนค่า
ชุดขอบเขตเริ่มต้นของ operator แบบเต็มตามปกติสำหรับการยืนยันตัวตน shared-secret bearer แม้ว่าผู้เรียก
จะส่งขอบเขตที่ประกาศไว้แคบกว่าก็ตาม

โหมดที่มีตัวตน เช่น การยืนยันตัวตนผ่านพร็อกซีที่เชื่อถือได้ หรือ private-ingress `none`
ยังสามารถเคารพขอบเขตที่ประกาศไว้อย่างชัดเจนได้ ใช้ Gateway แยกกันสำหรับการแยก
ขอบเขตความเชื่อถือจริง