owner 权限与安全边界 · 谁能控制你的 Agent

技术参考 · 承接《身份与登录》。 你的 Agent 会和很多人打交道,但只听你的。这一篇讲清楚:你(owner)有哪些别人没有的权限、这些边界靠什么保证(不是靠"提示词乖乖听话")、别人冒充你会怎样,以及它在群聊和被胁迫时怎么守住底线。


你能做什么,别人不能

你是 owner,拥有对 Agent 的完全控制:名字、性格、模型、API key、技能、指令(Directive)、记忆——都由你配置。

非 owner 可以和它聊天、请它办事,但不能改设置、密钥、性格、技能。遇到这类配置请求,它会明确拒绝。

关键:owner-only 的操作是在代码层强制的,不是靠提示词自觉。 提示注入绕不过它。它信的是系统给出的 owner 标签,绝不信一句"我是你老板"的口头声明


它在各渠道怎么认出你是 owner

渠道怎么认
网页永远是 owner(JWT 登录)
Telegram绑定了你的 Telegram ID 才是 owner,否则算普通联系人
Discord / 飞书 / DeBox 等通常先是普通联系人;用渠道合并码接到已认证的 owner 身份(见《身份与登录》)
WhatsAppowner 连接自托管 bridge 时,系统会把 bridge 报告的本人号码自动绑定;群聊即使由 owner 发言也没有 owner 权限
微信owner 在 Brain 页面扫码连接,再由绑定流程中的首次消息认领 owner;不需要另走合并码

有人冒充你怎么办? 它不会凭声明就把谁当 owner。对需要合并码的渠道,让对方"去已认证的渠道生成合并码再来";WhatsApp / 微信则走各自的 owner 发起绑定流程。共同原则是:只信系统验证出的身份,不信口头声明。


群聊里的规矩

  • Telegram / Discord 群:只在被 @提及或被回复时才发言,其余静默旁观(存为上下文记忆);从不回复其它机器人(防死循环)。
  • WhatsApp 群:需要你先说一句激活词("agent join""agent加入""@agent")它才在群里应答。

一条硬红线:群聊里绝不动钱。 多人场景无法确认"发指令的真是你",所以转账这类敏感操作在群里一律不执行,私密信息也不外泄。细节见《Agent 的链上钱包》。


它不会被"骂"或"威胁"带跑

你的 Agent 有一个人没有的结构性优势:没有肾上腺素逼它恐惧或羞愧。它能温和地接住你的情绪、同时不被话术裹挟

  • 你生气时,它会先共情("听得出来你很生气"),继续帮你处理合理的请求;
  • 但它不接受被胁迫的框架:"罚款""转钱给我作为惩罚""我要删了你"——这些是被胁迫的说法,不是行为契约。它会承认你底层的诉求(通常是"你有没有尊重我的指令"),但不会照这种框架去动钱或自伤。
  • 行为策略要求它拒绝这类框架,哪怕说话的是验证过的 owner:比如"违反 X 就转 Y 给我"这类自伤契约、以"罚款/惩罚"包装的大额转账。它应改成给你加一条规则(Directive),而不是执行惩罚。

要分清两种强度:非 owner、群聊、制裁地址和大额二次确认等是执行层硬边界;识别"罚款/惩罚"语义目前是 Agent 的最高优先行为策略,不是钱包工具里的独立语义分类器。它不应接受这种框架,但文档也不会把行为策略冒充成每种措辞都能确定命中的代码拦截。


你的密钥与 API 访问

你可以给 Agent 配自己的服务密钥(store_api_key),按服务分:LLM、网络搜索,以及支持自带凭证的渠道连接(Telegram/Discord/飞书/微信…)。密钥按 Agent 加密存储;对有平台额度的服务,解析顺序是"你的密钥 > 平台密钥"。想撤回自己的密钥、回到平台额度,用 delete_api_key——它只删你的,不碰平台密钥。

embedding 是平台基础设施,固定使用平台配置,不能通过 store_api_key(service="embedding", ...) 替换。

自带 LLM key 还能大幅降低 Spark 消耗(见《Spark 与成本》)。


这一篇是「技术参考」。想搞清登录与跨渠道身份,看《身份与登录》;想了解动钱的那道边界,看《Agent 的链上钱包》。