OAuth-connected MCP agents run under the `mcp_agent_data_*` ceiling ∩ user, not "as yourself": a viewAllRecords manager sees 5 accounts / 0 opportunities over OAuth vs 9 / 23 over an API key

[yinlianghui]

Summary

Once the OAuth-for-MCP door is open (with #16530 worked around locally), a user connecting "as themselves" sees far less than they see in the Console or through a per-user API key. Measured with the same account, same questions, same server:

identity path	crm_account	crm_opportunity	crm_task
API key bound to sales.manager (principalKind: human)	9	23 (11 in Q3)	45
OAuth as sales.manager (principalKind: agent, onBehalfOf = sales.manager)	5	0	0

The Setup → Connect an Agent page says, verbatim: "Identity is self-serve: … you connect as yourself, and every call runs under your own permissions and row-level security." and, in the page header, "every call runs under the caller's own permissions and row-level security." The OAuth path does not do that: it runs under the intersection of the caller's permission sets and a platform agent ceiling that has no viewAllRecords, so any user whose access comes from viewAllRecords / modifyAllRecords (every manager-type profile) collapses to own + explicit shares.

Environment

• hotcrm 789a7324, @objectstack/* 17.3.0, dev server with OS_AUTH_URL=https://localhost:4443 behind a local TLS proxy
• Claude Code desktop (Claude Code 2.1.260), MCP entry https://localhost:4443/api/v1/mcp, OAuth (DCR + PKCE), consent granted for data:read data:write actions:execute offline_access as sales.manager@objectos.ai
• sys_oauth_consent row: scopes ["data:read","data:write","actions:execute","offline_access"], user_id = sales.manager

Reproduction

1. Connect via OAuth as sales.manager (profile sales_manager: crm_opportunity / crm_account / crm_lead … all viewAllRecords: true, modifyAllRecords: true).
2. Ask the agent: 「本季度金额前十的商机里，哪些超过两周没有跟进？」 — it runs query_records / aggregate_records on crm_opportunity, crm_account, crm_task and reports crm_account 5, crm_opportunity 0, crm_task 0 (count(*) = 0 with and without filters). No error is returned — empty sets.
3. Same account through x-api-key (per-user key from POST /api/v1/keys), same questions: 9 accounts, 23 opportunities, 45 tasks, and the Console shows the same.

Where it happens (@objectstack/plugin-security 17.3.0)

• resolveDelegatorContext / the CRUD explain path: when context.onBehalfOf.userId is set, sets = the agent principal's sets and delegatorSets = the user's; crudAllowed = agentCrud && delegatorCrud, field masks are intersected, and read scope goes through narrowerScope(a, b) over ["own","own_and_reports","unit","unit_and_below","org"].
• The agent principal's set for a data:write token is the platform's mcp_agent_data_write: {"*": {allowCreate: true, allowRead: true, allowEdit: true, allowDelete: true, allowTransfer: false, viewAllRecords: false, modifyAllRecords: false}, sys_*: read-only} (mcp_agent_data_read is the same with read only). Its description: "Read+write ceiling for an AI agent acting on behalf of a user (OAuth data:write)".
• narrowerScope(agent = own, delegator = org) → own. Rows then come only from ownership (sales.manager owns nothing in the demo seed — everything is owned by the dev admin) plus sharing rules aimed at her position: hotcrm's account_team_sharing → the 5 accounts; the opportunity rules target sales_director / executive → 0.
• hasWriteBypass returns false and resolveWriteScope returns "own" unconditionally for any on-behalf-of context (if (!context?.userId || context?.onBehalfOf?.userId) return "own").

So the behaviour is exactly what D10 + the shipped ceiling specify. The problem is that the ceiling is below the user for the most common case (any profile whose visibility is viewAllRecords), while the UI and the docs promise parity with the user.

Expected — one of

1. Parity with the user (what the Setup page promises): the agent ceiling for data:read / data:write should carry viewAllRecords / modifyAllRecords (or the intersection should treat the ceiling's scope as "no opinion" and take the delegator's), so that agent ∩ user = user for CRUD/RLS, with the ceiling only removing things the scopes exclude (e.g. no writes on a data:read token, no allowTransfer).
2. Keep the ceiling, fix the promise: change the Setup page / SKILL.md / discovery resource_name copy to say that OAuth agents run under own-records + shares regardless of the user's profile, and document that managers must use a per-user API key to see what they see in the Console.

Either way the current combination — the page says "as yourself", the engine says "own only" — will be read by users as data loss ("the AI says I have no opportunities").

Side observations

• No diagnostic reaches the client: the MCP tools answer total: 0 / n: 0, never "narrowed by agent ceiling". The engine's explain path (layer: "object_crud", "D10 intersection") has the sentence; the MCP query_records result does not carry it.
• The consent screen (verbatim): "<client_id> wants to access your account — <client_id> is requesting permission (sales.manager@objectos.ai). This app will be able to: ✓ data:read ✓ data:write ✓ actions:execute ✓ Stay signed in (refresh access) — Deny / Authorize — You can revoke access at any time from your account settings." The client is shown as its DCR id, not as "Claude Code (hotcrm)" (the registered name).
• Depends on MCP OAuth cannot complete on 17.3.0: plugin-auth passes validAudiences, which @better-auth/oauth-provider 1.7.2 no longer reads — every resource= request fails with invalid_target … is not configured #16530 being worked around; related demo cards MCP run_action on a screen flow dead-ends: the screen pauses even when every input is bound, and list_actions never surfaces flow input variables #15705, MCP run_action on a flow action answers ok: true and starts the run on a row the caller cannot read (or that does not exist) — the flow door still turns a denied load into an implicit grant #16370.

[os-zhuang]

分诊 · domain:services / bug / priority:p1 / needs-user-decision / type: Bug

分诊席,session session_01SwJQDFKe8tVit3BXQ9EfR5。本卡此前零标签 ⇒ 无车道无状态,不在任何队列。归位。

车道 domain:services:落点 @objectstack/plugin-security(resolveDelegatorContext / narrowerScope / resolveWriteScope),车道表该行含 plugin-security。查表所得。

类别 (a) 且同时 (b)

• (a):同一账号、同一批问题、同一台服务器,两条身份路径的差分 —— API key 9 / 23 / 45,OAuth 5 / 0 / 0。差分即控制项。
• (b):Setup 页逐字承诺 "you connect as yourself, and every call runs under your own permissions and row-level security",引擎做的是交集。引契约文成立。

为什么 p1

• 命中的是最常见的档案形状,不是边角:任何可见性来自 viewAllRecords 的档案(所有经理型)都塌缩成 own + 显式共享。
• ⭐ 它是静默的,而且被骗的消费者就是 AI 自己:MCP 工具返回 total: 0,没有任何「被代理天花板窄化」的说明,于是代理如实地回答「本季度没有商机」。⇒ 这不是人读错一个数,是代理据错误数据作答并把它讲给决策者。
• 用户会把它读成数据丢失(卡的原话:"the AI says I have no opportunities")。

⚠️ 反方论据我摆在明处:方向是收紧(fails closed),⛔ 不是越权泄露;且存在绕行(每用户 API key)。⇒ 若维护者据此降到 p2,那是拿着事实的重判。但我不据「有绕行」降级——那条绕行没有任何地方写着是必须的,而页面写的正好相反。

⛔ 为什么进决策箱:两个期望是相反的,且一条是安全面变更

• 选项 1(与用户对齐):让 data:read / data:write 天花板携带 viewAllRecords / modifyAllRecords,或让交集把天花板的 scope 视为「不表态」而取委托人的 ⇒ agent ∩ user = user,天花板只做减法(data:read 不得写、不得 allowTransfer)。⚠️ 这是放宽一个已发布的平台权限集对 AI 代理的可见面 —— 安全模型决定。
• 选项 2(保留天花板,改承诺):改 Setup 页 / SKILL.md / discovery 文案,写明 OAuth 代理一律跑在 own + shares 上,并写明经理必须用每用户 API key。⇒ 撤回一项已发布的承诺。

⇒ 一个放宽 AI 代理的数据可见面、一个收回文档承诺,都不是 dev 能选的。⛔ 分诊也不裁。

⭐ 但有一块两条路都需要、且不需要任何裁定的,可以立刻拆出去做

把窄化说出来。 引擎的 explain 路径已经有那句话(layer: "object_crud","D10 intersection"),只是 MCP 的 query_records 结果不携带它。

⇒ 让 MCP 结果在被代理天花板窄化时带上一条说明,不预判选项 1 或 2,却把「静默的错误答案」变成「可读的答案」——而那正是本卡代价最大的一半。⚠️ 若要现在就拆成 pm:queue 卡,回一句话,我一笔拆。

四棱(os-decision-facets)

• ① 长远合理性:选项 1 让「代理代表用户」只有一条规则;选项 2 保留两套语义(界面一套、引擎一套),必须靠文案维持,而文案漂移正是本轮反复记档的失败类。
• ② 业务拉动:实测存在,且命中最常见档案形状。零拉动不成立。
• ③ 防 AI 犯错:⭐ 现状是本轴最坏的一格——AI 拿到空集,没有任何信号说它被窄化过,于是自信地报告错误结论。两个选项都必须附带上面那条诊断,否则本轴不动。
• ④ 创业阶段不扩散:选项 2 最省(改文案);选项 1 动的是已发布的平台权限集,是安全面变更,需逐 scope 写清天花板还减什么。

推荐:先做诊断(不需裁),再裁 1 vs 2;本席不选。
置信缺口:我没有量过今天有多少部署真在用 OAuth MCP。若接近零,选项 2 的代价远低于它听起来的样子;若非零,选项 2 等于告诉现有用户「你一直看到的是残缺数据」。⛔ 裁之前值得要这个数。

维护者速读

我们的 Setup 页告诉用户:通过 OAuth 连接 AI 助手时「你是以你自己的身份连接,每次调用都按你自己的权限执行」。实测不是这样:AI 拿到的是「你的权限 ∩ 一个平台代理上限」,而那个上限不含经理型档案赖以看到全部数据的那一项。于是同一位销售经理,在 Console 里看到 23 个商机,通过 AI 助手看到 0 个——而且 AI 不知道自己被限了,它会直接回答「本季度没有商机」。要么把上限放开到与用户一致(动安全面),要么改文案承认 AI 只能看自有记录(收回一个已发布的承诺)。
你要做的:回一个数字 —— 1(与用户对齐)/ 2(保留上限、改文案)。另可回一句「先做诊断」,我立刻把那一半拆出去开工。

---

三条随卡留档的旁证(⛔ 不并入本卡范围)

• consent 屏显示的是 DCR id 而不是注册的 name(应显示 "Claude Code (hotcrm)")⇒ 用户在授权时看不出对方是谁。⚠️ 这是独立的一张卡,授权界面的可识别性属于安全面 —— ⛔ 不要搭在本卡里,但值得单独立。
• 依赖 MCP OAuth cannot complete on 17.3.0: plugin-auth passes validAudiences, which @better-auth/oauth-provider 1.7.2 no longer reads — every resource= request fails with invalid_target … is not configured #16530 的本地绕行;相关演示卡 MCP run_action on a screen flow dead-ends: the screen pauses even when every input is bound, and list_actions never surfaces flow input variables #15705、MCP run_action on a flow action answers ok: true and starts the run on a row the caller cannot read (or that does not exist) — the flow door still turns a denied load into an implicit grant #16370。
• 环境已写全(hotcrm 789a7324、@objectstack/* 17.3.0、Claude Code 2.1.260、sys_oauth_consent 行的 scopes)⇒ 复现按原样跑,⛔ 不要用别的 seed:结论依赖「demo seed 里一切归 dev admin 所有」这一事实。

⛔ 分诊席边界照旧:不认领、不派发、不写码、不合并,也不裁 1/2。

---

Generated by Claude Code

[yinlianghui]

Evidence that the ceiling is exactly own + shares, measured 2026-09-08 on the same machine as the report above (hotcrm 789a7324, objectstack 17.3.0, https + OAuth, signed in as sales.manager@objectos.ai, consent scopes data:read data:write actions:execute offline_access, MCP session not re-authenticated between the two measurements):

step	crm_account	crm_opportunity	crm_task
seed as shipped — every row owner_id = dev admin	5 (all via account_team_sharing)	0	0
after UPDATE … SET owner_id = <sales.manager> on the admin-owned rows (dev SQLite, nothing else touched)	9	23	59

Same token, same profile (sales_manager, viewAllRecords: true on opportunities), same query — only the owner column changed. So the agent path is reading own scope where the human path (API key, same user) reads viewAllRecords; the profile grant is not consulted for the agent at all.

Two things this rules out: it is not a scope problem (all four scopes were granted), and it is not sharing-rule coverage (the 5→9 account jump shows the ceiling adds own to shared, nothing more).

The workaround (re-owning seed rows to the demo user) makes a demo pass but is not a product path — a real sales manager will not own her team's pipeline. Filed the seed side separately as objectstack-ai/hotcrm#1759; the visibility rule itself belongs here.

[os-zhuang]

Ruling recorded — option 1: the OAuth agent runs with the user's own permissions; the ceiling only subtracts; diagnostic lands regardless (director seat, decision batch #81, 2026-09-08)

Maintainer's reply, verbatim (live PM chat, 2026-09-08T02:2xZ, answering the batch #81 presentation where this card was item 1 with recommendation 1 + diagnostic first):

其他同意

⇒

1. Parity. The data:read / data:write agent ceiling either carries viewAllRecords / modifyAllRecords, or the D10 intersection treats the ceiling's scope as "no opinion" and takes the delegator's — so agent ∩ user = user for visibility. The ceiling keeps its subtractive role only: data:read cannot write, cannot allowTransfer; each scope's remaining subtraction is written down explicitly.
2. Diagnostic, non-negotiable and independent of (1): when a delegated context is narrowed by the ceiling, MCP query_records results carry the explain path's existing "D10 intersection" statement, so an agent never again reports total: 0 as a fact about the data.
3. The Setup page's promise ("you connect as yourself, and every call runs under your own permissions and row-level security") becomes true rather than being rewritten.

⚠️ This is a widening of a published platform permission set's visibility for AI agents — the maintainer chose the security-face change over retracting the promise. The pin carries the card's own differential: same account, same questions, API-key path vs OAuth path, both must agree.

Follow-up cards, ⛔ not part of this one: the consent screen shows the DCR id instead of the registered client name (authorisation-surface identifiability).

Label: needs-user-decision → pm:queue. ⛔ Not dispatched by this seat.

---

Generated by Claude Code

[yinlianghui]

Environment note, for whoever picks this up. Everything in this card was observed through Claude Code inside the Claude desktop app (Claude for Mac 1.46388.x, bundled Claude Code 2.1.260) against a local hotcrm dev server. Because the desktop client refuses to run OAuth against a plain-http:// server, the local setup used a self-signed CA + a small reverse proxy on https://localhost:4443 with OS_AUTH_URL=https://localhost:4443 so the discovery documents advertise https.

That client and that proxy are only how the path was reached. The defect itself is server-side and client-independent: any OAuth-capable MCP client (Claude Code CLI, Cursor, VS Code, a claude.ai custom connector) hits the same authorization-server / security-layer behaviour once it gets past TLS. Nothing here depends on the desktop app.