隐私边界
这页只说明当前已经明确的接入责任边界：TiRTC 平台、你的业务系统、以及你的终端用户，各自负责什么。
这页不展开数据留存、删除、区域、合规或隐私政策口径。
三方分别是谁
- TiRTC 平台：提供连接能力、Token 协议校验、实时音视频能力，以及公开 SDK。
- 你的业务系统：包括你的 App、业务服务端、设备管理后台、账号体系和授权规则。
- 你的终端用户：使用你业务应用的人，例如设备拥有者、家庭成员、租户成员或运维人员。
谁负责访问授权
TiRTC 平台负责校验“这次连接带来的 Token 是否符合协议要求”。
你的业务系统负责判断“这个用户是否应该访问这个目标设备或远端实例”。
换句话说：
- 平台负责连接校验
- 你负责业务授权
- 用户是在你定义的权限范围内发起访问的人
如果你的用户能不能访问某台设备，取决于你的业务服务端是否先完成判断并签发这次连接所需的短时 token，而不是由 TiRTC 平台替你决定。
谁该持有什么信息
TiRTC 平台
平台承接连接与媒体能力，但不应被当成你的用户账号系统或设备授权系统。
像下面这些判断，应留在你的业务系统里：
- 这个用户属于哪个家庭、组织或租户
- 这个用户能不能访问这台设备
- 这个账号是否被禁用或收回权限
你的业务服务端
你的业务服务端应持有或受控访问：
access_idsecret_key- 与目标设备相关的
device_secret_key（在签发或校验确有需要时） - 用户、设备与授权关系
这是做授权决策和签发 token 的正确位置。
用户侧客户端
用户侧客户端通常只应拿到完成当前连接所必需的最小信息，例如：
用户侧客户端和普通业务流程不应直接接触：
secret_keydevice_secret_key- 完整的
device_id+device_secret_key组合字符串（某些 API、CLI 或配置项里写作license）
设备端
设备端在必要场景下会使用：
device_iddevice_secret_keydevice_id和device_secret_key的组合字符串（某些 API、CLI 或配置项里写作license）
但这些值应停留在受控设备侧环境里，不应为了联调方便扩散到客户端、截图、日志或工单内容里。
常见误区
把平台鉴权当成业务授权
平台鉴权解决的是“这次连接请求是否合法”。
业务授权解决的是“这个用户是否应该访问这个目标”。
这两件事不是同一层责任。
为了方便，把密钥下发到客户端
如果客户端能直接拿到 secret_key 或 device_secret_key，边界就已经错了。
客户端应拿到的是短时 token，而不是底层签名密钥。
不要把你的业务用户理解成 TiRTC 平台替你管理的账号
在当前接入模型里，用户身份主要属于你的业务体系。
对 TiRTC 来说，用户通常只是你在签发 Token 时写入的主体标识，以及你在签发前完成授权判断的对象。