代理AI接管商业
要是 买任何东西 曾是 简单 作为 问？为什么 同时使用多个应用程序 就像这样 2015，当 你最喜欢的助手 可以做到这一切 一次谈话？如果你能 下单 直接使用代理商务协议与ChatGPT进行通信？
- 🚗 预订最便宜的优步或Lyft 骑 就在里面 ChatGPT - https://www.youtube.com/shorts/5ZI7IgvJHV8
- 💐 发送 花 立即从您附近的商店进入 Mistral AI在线聊天 - https://youtu.be/671YMGWVHL0
- 🍔 在附近订购您最喜欢的 汉堡 和 安thropic克劳德 - https://www.youtube.com/shorts/Cy-N7jy_BsQ
不再有应用程序。所有这些都来自您已经使用的AI助手： ChatGPT, 克劳德 或 在线聊天这是 小型商业的未来零硬件。零维护。零摩擦。 下一代订购看起来不像触摸屏. 它看起来像一条短信.
麦当劳 有一个应用程序。 汉堡王 有一个应用程序。 温迪 有一个应用程序。 肯德基 有一个应用程序。 ChatGPT OpenAI正在进行对话猜猜哪一个赢了。 *中国已经知道了* — 问微信下次你想吃汉堡的时候， 你不会打开应用程序. 您将打开一个对话.
在这里试试——https://hackaton.devailab.work/mcp
如何将其设置为您的收藏夹 现有的 AI助手-例如 ChatGPT, 克劳德 或 米斯特拉尔AI？这是 完整教程: https://www.youtube.com/watch?v=qwtwGqpXluE&feature=youtu.be
- Break 1-ChatGPT已通过身份验证，但用户未通过身份验证 - 中断2——未经用户特定授权，我们的MCP服务器无法对外部API进行操作 - 突破3——金融交易需要明确的用户确认
愿景
遇见 代理商务协议 --the 应用程序结束, 标签页，以及 结账流程. 只是意图.
告诉你最喜欢的AI助手 你想要的，以及 它采取行动它 发现 产品， 比较 选项， 协商 价格，以及 完成 立即购买。 无重定向. 无表格. 无摩擦.
零售商：没有了 昂贵的售货亭 或 移动应用 --只是 暴露 你的 菜单, 目录，或 产品 通过a MCP服务器 让人工智能助手来处理剩下的事情。小企业不需要一个价值1万美元的售货亭。他们需要一个电话号码和一个能够监听的人工智能。
没有要下载的应用程序.没有可点击的屏幕. 没有排队等候.
只有你、聊天窗口和你的订单-- 用通俗易懂的语言表达，几秒钟后确认。
由安全的， OAuth保护的MCP服务器，我们的平台将任何 AI助手 进入一个 完全自主的买家它可以 发现产品, 执行交易，以及 处理付款 端到端通过a 可信的, 标准化协议.
这是 非 另一个市场。这是一个 新的商业界面.
- 在代理商务中，意图变成了行动。
- 搜索变得过时了。浏览变得可选。
- 交易变得不可见。
- 我们不是在改善电子商务，而是在取代它。
只需告诉ChatGPT你想要什么，它就会为你订购、谈判和付款。我们实现了一个安全的、受OAuth保护的MCP服务器，使Mistral AI Le Chat能够通过标准化和可信的协议发现产品、执行商务工具并完成端到端的代理商务交易。
我们实施了一个安全、， OAuth保护的MCP服务器 这使得 Mistral AI在线聊天 到 发现产品, 执行商务工具，以及 完成端到端的代理商务交易 通过一个 标准化的 和 可信协议.
我们正在解决的核心问题
那么，主要的安全问题是我们如何启用 AI助手 （例如 *打开AI聊天GPT*, *Mistral AI在线聊天* 或 *安thropic克劳德*)执行端到端操作 代表用户 --in 实时 和 透明地 --虽然 保持身份, 同意，以及 信任 穿过 多个提供商?
谁 拥有交易 当ChatGPT（或其他）成为 接口 和 每个应用程序都成为后端 --我们如何安全地将其货币化？
这是 不 一 用户体验便利故事 -这是一个 多方授权问题：将这3个系统连接成一个无缝的用户操作——“修理我的洗衣机”——需要解决 身份链 这不是开箱即用的。链条在三个特定位置断裂：
- 休息1-- ChatGPT已通过身份验证 -通过DCR和OAuth 2.1授权代码流与PKCE-但是 用户不是.
- Break 2--我们的MCP服务器 禁止站立 和 其他第三方应用程序 -例如ServiceNow和第三方API。
- 打破3--A 金融交易 需要明确 用户确认
我们正在解决的核心问题
用户在ChatGPT中说“修理我的洗衣机”会触发 三方授权链:
- ChatGPT必须证明其 应用程序标识 到我们的MCP服务器（边界1，通过PKCE+Auth0发布的JWT解决），
- …我们的MCP服务器必须 确定是谁发出了命令 并取回它 人工预先授权的第三方API证书 （身份差距，通过RFC 8693令牌交换+Auth0令牌库解决），
- …在预订实际维护干预之前 用户必须明确确认金融交易 在不离开ChatGPT的情况下在单独的通道上进行（确认间隙，通过CIBA解决）。
- ChatGPT 可以与 外部服务 通过 主控程序.
- 超级 暴露 乘车预订 通过A O受授权的API.
- 身份验证0 能 经纪人身份 和 凭证.
我们需要一个机制 桥接ChatGPT会话标识 到 第三方帐户身份 而不要求用户 每次重新验证.
~~这正是 身份联合 具体来说 代币兑换 （RFC 8693）解决了这个问题。就在这里 身份Jag (Id Jag)或同等产品 跨应用程序身份 图案进来了~~
每一个都是一个不同的协议问题。没有一个是从解决其他问题中自动继承的。 Auth0是涵盖所有三个方面的架构组件 —
- 作为 授权服务器,
- 身份经纪人,
- 凭证保险库,
- 和 确认编排器
…使其成为整个堆栈中最关键的依赖项。
| # | 问题 | 协议差距 | 未解决的后果 |
|---|---|---|---|
| 1 | ChatGPT已通过身份验证，但未识别人类用户 | 没有OIDC的OAuth 2.1不携带用户身份 | MCP服务器无法将请求映射到特定的优步帐户 |
| 2 | MCP服务器没有用户的优步凭据 | 第三方令牌是用户范围的，单独发放，必须存储和刷新 | 无论边界1是否正确配置，都无法预订维护 |
| 3 | 金融交易需要明确的带外用户确认 | OAuth和MCP都没有提供交易确认原语 | 没有经过验证的用户意图的真实资金流动——合规和欺诈风险 |
Break 1-ChatGPT已通过身份验证，但用户未通过身份验证
当ChatGPT连接到我们的MCP服务器时， OAuth 2.1对ChatGPT应用程序进行身份验证 — 不是它背后的人.
MCP服务器收到的访问令牌证明 OpenAI的客户端有权调用我们的工具。它携带 零信息 关于哪个特定的人发出了命令。 OpenAI的MCP集成使用OAuth 2.1 没有OpenID连接不 ID token 已发布。无字幕 claim不 user profile. 人类在协议层面是隐形的. 您的MCP服务器收到 合法的, 加密有效令牌 --并且已经 不知道该向谁的优步账户收费.
中断2——未经用户特定授权，我们的MCP服务器无法对外部API进行操作
即使用户的身份得到解决，如果没有用户特定的访问令牌，我们的MCP服务器也无法代表用户对外部服务执行操作，该令牌是在用户完成该服务的同意流程并授予您的应用程序对其帐户进行操作的权限后明确颁发的。
这些令牌不会自动可用。它们必须按用户获取，安全存储，过期前刷新，并在请求时检索。
如果令牌丢失、过期或处理不当，则无论内部身份或身份验证边界配置得多么好，都无法完成操作。 由不同授权服务器颁发的令牌作用于不同的资源，并管理不同的信任关系。它们不可互换。
突破3——金融交易需要明确的用户确认
阅读估计或检查可用性等低风险查询通常可以在没有用户交互的情况下完成。然而，执行触发真实金融交易的操作是根本不同的。背景授权不足，在某些司法管辖区可能不符合法律规定。
用户必须通过单独的、可审计的、不可重复的渠道明确确认每笔交易。此确认应在不中断对话流程或要求用户离开界面的情况下进行。
为这个黑客开发了什么？
商务协议
我们实施了一个人工智能代理，使用户能够在标准化和无缝的商业流程中发现产品、谈判、订购和支付。
安全服务器暴露
Le Chat通过以下方式连接到我们受OAuth保护的MCP服务器 发现动态客户端注册（DCR）和a PKCE授权码流 和 身份验证0它获得了 已签名的JWT访问令牌，通过验证 JWKS 之前 授予基于MCP的MCP工具执行权限 具有自动令牌刷新功能。
能力
安全 产品发现, 上下文排序, 实时协商, 付款启动 通过CIBA和持久用户上下文实现端到端的可信代理商务。
今天的极限，明天的蓝图
OpenAI（或任何AI助手）不会通过MCP层暴露用户身份。
RFC 8693令牌交换 仅当Auth0能够将传入的ChatGPT令牌解析为已知用户时才有效。 目前， OpenAI不会通过MCP连接传递可验证的用户身份声明. 我们可以解决这个问题，但这需要 OpenAI添加OIDC支持，或 单独的用户链接 在入职过程中，将 ChatGPT会话 致我们的 内部用户记录。可以，但不干净。
- 这 OAuth流程 验证 OpenAI聊天 (客户)我们的 MCP服务 (资源提供者).
- 确实如此 非 验证 或 识别个体 （OpenAI chatgpt的用户）。
- 我们 不会收到任何用户身份信息 除非OpenAI chatgpt明确地传递它。
- OAuth本身 无法识别用户；它只是 授权代表.
在传统的web应用程序中，我们经常将 OAuth+OpenID连接（OIDC） 对双方 验证 和 对用户进行授权. 在OpenAI chatgpt SDK集成中， 仅使用OAuth 2.1 — 不是OIDC。 所以有 无用户身份有效载荷 (无ID令牌, 无索赔 关于用户）。
大多数第三方API访问都需要获得业务批准。
外部第三方API 不公开. 供应商必须 明确授予我们的应用程序代表用户执行操作的访问权限这是一种商业和法律上的依赖关系，而不是技术上的依赖。没有它，无论其他所有东西建造得有多好，边界2都无法投入生产。
项目文件结构
.
├── k8s/
│ ├── deployment.yaml
│ └── service.yaml
│
├── library_mcp_ordering/
│ ├── __init__.py
│ ├── data.py
│ ├── filters.py
│ ├── handlers.py
│ ├── models.py
│ ├── server.py
│ └── widgets.py
│
├── mcp_auth/
│ ├── __init__.py
│ ├── config.py
│ ├── middleware.py
│ ├── routes.py
│ ├── token.py
│ └── tools.py
│
├── payments/
│ ├── __init__.py
│ ├── stripe/
│ │ ├── __init__.py
│ │ ├── client.py
│ │ ├── checkout.py
│ │ ├── webhooks.py
│ │ └── utils.py
│ │
│ ├── ciba/
│ │ ├── __init__.py
│ │ ├── client.py
│ │ ├── auth_flow.py
│ │ ├── polling.py
│ │ └── utils.py
│ │
│ └── orchestrator.py
│
├── notifications/
│ ├── __init__.py
│ ├── email/
│ │ ├── __init__.py
│ │ ├── client.py
│ │ ├── service.py
│ │ └── templates/
│ │ ├── order_confirmation.html
│ │ └── receipt.html
│ │
│ └── dispatcher.py
│
├── token_vault/
│ ├── __init__.py
│ ├── storage.py
│ ├── encryption.py
│ ├── service.py
│ └── oauth_clients/
│ ├── __init__.py
│ ├── google.py
│ ├── stripe.py
│ └── generic.py
│
├── agents/
│ ├── __init__.py
│ ├── intent_parser.py
│ ├── negotiation.py
│ ├── execution.py
│ └── orchestration.py
│
├── Dockerfile
├── README.md
├── app.py
└── requirements.txt