ID
Peer Identity
本地 Unix Socket 使用内核提供的对端凭据。高权限决策不会相信客户端 JSON 里随意填写的 Agent 名称。
Security & Trust
智能可以自主，系统权限始终受治理。
KINGAI OS 把模型和 Agent 当作智能，而不是信任根。真正触碰系统资源之前，请求必须经过 Peer Identity、Agent Registry、Capability Policy、目标绑定 Approval 和受限执行。
1 · 身份Unix Peer + 注册 Agent
2 · 策略Capability + Target + Risk
3 · 审批需要时一次性授权
4 · ExecDCapability 专用执行
P
默认拒绝策略
未知身份和未知 Capability 默认拒绝，模型本身不能改变系统权限规则。
✓
一次性 Approval
审批强绑定 Agent、Capability、Target Hash 和 Peer UID，并具备过期与一次性消费，防止重放。
E
受限 ExecD
高权限 Broker 只接受明确注册的 Handler。当前原生高权限面保持刻意收窄，不提供通用 root shell。
当前真实边界
已经验证的能力，与仍在建设的安全门禁分开。
D5 已验证 Identity → Policy → Approval → Scheduler → ExecD 主链；更完整的生产 Sandbox Profile 仍属于独立强化工作，不提前标记为完成。
Execution Broker 测试
独立 CI 验证 Unix Socket 访问、Capability 白名单，以及非法 Service Target 在高权限执行前被拒绝。
完整 Sandbox Profile
面向更多 Capability 的生产 AppArmor、seccomp、Landlock 与资源控制策略仍在强化。
Trust Root 操作
生产签名、TUF 密钥托管、Boot Trust 修改和破坏性系统操作仍属于发布或 Owner 控制边界。
A/B Update
向前升级，同时保留已确认的正常系统。
更新写入 inactive slot，启动后接受 Health 检查，验证失败时可以回到最后确认正常的 slot。
Recovery
修复系统，不绕过系统信任。
Recovery 用于检查、回滚和 Boot Repair，而不是静默关闭安全机制。
分层 Trust
TUF、Secure Boot 和 Release Governance 解决不同问题。
KINGAI 把更新元数据、启动链和发布授权分开，避免任何一个凭据成为万能主密钥。
TUF Client
签名元数据、过期与 Pinned Root 行为已经进入工程基线；生产仓库密钥操作仍受门禁保护。
Secure Boot
VM 验证已经存在，但与生产签名密钥托管和真实硬件正式支持严格分开。
Release Gates
Stable 必须有签名、恢复、供应链、交付、硬件和治理的新鲜证据，而不是静态绿色标签。
每一项强大能力，都应该有明确而狭窄的权限理由。
KINGAI OS 的目标是扩展智能能力，而不是扩展隐式权限。