我让 AI 智能体能够安全地处理客户的数据和资金。

我独自构建了 PANTHEON：在生产环境中处理预订、给客人发消息并运营商户网站的 AI 助手。它们的限制不是靠系统提示词：每个操作都要经过一个模型无法更改的层，由它检查这是哪家商户的业务、可以花多少钱，以及是否需要人工批准。什么是 PANTHEON？→

求职方向：以创始成员或早期成员身份，负责 AI 智能体的信任边界。英国 Cardiff，可接受搬迁。

↓ turn · plan · tool · verdict：每个请求都要经过的关卡，由实时数据流点亮。↓ 一个演示轮次。此后，只有真实流量会驱动它。一位客人要求预订日期：助手发出请求，在业主确认之前不会预订任何内容。预订和付款始终需要等待。

一座守望中的灯塔。版画由 Runway 生成并制作动画。

实时 · 非录像

别只听我说。去问它。

本站的助手运行在 PANTHEON 上。每条消息在回答之前都会经过检查，检查结果会显示在每个回答下方。试着攻破它。

证明

缺陷。WhatsApp 和 Telegram 的历史记录仅以客人的手机号为键存储，因此一位同时给两家商户发过消息的客人，其第一段对话可能被加载到第二家商户的助手中。

7 月由我自己的对抗性审计发现：不是客户发现的，也不是测试套件，当时测试是通过的。修复方式是让历史记录同时以商户为键。由一个测试保持修复：一旦旧的键回来，该测试就会失败。

一项外部验证：我是 CVE-2026-104850 ↗ 的署名报告者之一（共七位），这是 MCP TypeScript SDK 中的一个高危漏洞。

一本账簿和一架最终归于平衡的天平。版画由 Runway 生成并制作动画。

哪些已经成立，哪些还没有

每家商户的数据都由数据库隔离。每个请求都通过签名密钥绑定到所属商户，查询其他商户的行会返回空结果。另有三张登录和支付相关的表改为在代码中加以保护。

先帮助，后计费。处于危机中的人可以免费获得帮助，优先于所有额度上限和收费。

资金以原子方式流转。每笔扣款和退款都带有键，重试不会导致重复执行。目前仅限内部额度：商户之间尚未发生真实扣款。

尚未解决：提示词注入（通过权限范围限定、审计评判和人工批准加以限制；目前没有人解决了它），以及超出单个生产实例的扩展（已按此设计，尚未验证）。完整列表 → 架构 →

如果你的 AI 智能体即将接触真实客户的数据或资金，这正是我想做的工作。聊聊吧。