Metadata `type: 'api'` actions send the Bearer token and X-Tenant-ID to absolute third-party URLs — the #2725 `sameOriginOnly` mitigation was never applied to this lane

[os-sales]

Found while documenting the X-Tenant-ID edge contract for #5279 (PR forthcoming on that card). Not fixed there — different package, different fence.

What was measured

createAuthenticatedFetch({ sameOriginOnly: true }) exists because of #2725: a fetch whose target URL comes from view metadata may name a third-party host that must never see the platform bearer token. Reading every construction site in the repo, exactly one passes the option:

• packages/app-shell/src/console/ConsoleShell.tsx:213 — const apiProviderFetch = withSettleSignal(createAuthenticatedFetch({ sameOriginOnly: true }));, the provider: 'api' data-source lane.

Every other site builds the bare wrapper, including the one that takes a URL from metadata just as freely:

• packages/app-shell/src/hooks/useConsoleActionRuntime.tsx:300 — const authFetch = useMemo(() => createAuthenticatedFetch(), []);

That wrapper is what apiHandler calls, and apiHandler accepts an absolute target straight from the action metadata (useConsoleActionRuntime.tsx:315-337):

const isAbsolute = targetStr.startsWith('/') || /^https?:\/\//i.test(targetStr);
...
const url = resolvedTarget.startsWith('http') ? resolvedTarget : `${baseUrl}${resolvedTarget}`;

So a metadata type: 'api' action whose target is https://third-party.example/... is fetched through the bare wrapper. Two headers ride along:

Header	Gate in createAuthenticatedFetch	Sent to a third-party host?
Authorization: Bearer <session token>	isApiCall = /\/api\//i.test(url)	Yes, whenever the third-party URL happens to contain /api/ — which is the common shape for one
X-Tenant-ID: <active organization id>	none at all	Yes, unconditionally

The bearer half is already pinned as intended-for-the-other-lane by an existing test — packages/auth/src/__tests__/createAuthenticatedFetch.test.tsx, "without sameOriginOnly, cross-origin /api/ URLs keep the legacy attach behaviour". That test records the wrapper's behaviour; it says nothing about whether this call site should be using the bare wrapper.

Why it looks like an oversight rather than a decision

#2725's fix hardened the lane it was reported on. Both lanes take their URL from author-supplied metadata, and nothing in the code or comments distinguishes them on that axis — apiHandler's own comment describes the wrapper as "Bearer + X-Tenant-ID + same-origin cookies" without noting that the target may be off-origin.

Not covered by this report

Whether the tenant stamp should be gated on isApiCall at all (it is the only one of the three headers that is not) is a separate question raised on #5279. It is listed here only because it changes what a third-party host receives from this call site.

Suggested repair, for triage rather than as a decision

useConsoleActionRuntime.tsx:300 builds createAuthenticatedFetch({ sameOriginOnly: true }), matching ConsoleShell. That would stop attaching credentials to off-origin action targets while leaving every same-origin action untouched. It is a behaviour change for any deployment that today relies on the bearer reaching an off-origin /api/ target, so it needs a deliberate call, not a drive-by.

[os-sales]

Seat triage — labelled needs-user-decision and escalated. Not dispatchable as filed, and that is the right call, not a delay.

Labelled pm:queue + needs-user-decision + domain:ui by the domain:ui execution seat (seat post #5560). It arrived unlabelled from the #5279 dispatch that found it.

Why it stops here rather than going out with the next batch: the suggested repair — passing sameOriginOnly: true at useConsoleActionRuntime.tsx:300 — is a behaviour change any deployment could be relying on today. The report says so itself and declines to decide it, which is correct. An agent dispatched on "make it match ConsoleShell" would be making a compatibility call the seat has no standing to make.

What makes this worth a fast look rather than an ordinary queue position:

• The exposure is not conditional on a misconfiguration. X-Tenant-ID has no gate at all in createAuthenticatedFetch, so it reaches an absolute third-party target unconditionally.
• The bearer half is gated only by /\/api\//i.test(url) — a test on the string, not on the origin. A third-party URL containing /api/ is the common shape for one, so the gate that reads like a safety check is close to a coin flip on exactly the URLs that matter.
• The mitigation already exists and is already used one line-of-sight away (ConsoleShell.tsx:213), which is what makes the oversight reading credible: both lanes take their URL from author-supplied metadata, and nothing in the code distinguishes them on that axis.

Three things a decision needs, none of which this seat should answer:

1. Is there a supported deployment shape where a metadata type: 'api' action legitimately targets an off-origin host and expects the platform bearer? If yes, sameOriginOnly at this site breaks it and the repair needs an opt-in instead.
2. Should X-Tenant-ID be gated on origin independently of the bearer? It is a routing hint rather than a credential, but it still names the tenant to a third party. (This is the same question Confirm whether X-Tenant-ID has a reader: the framework derives the tenant from the session, not the header #5279 raised from the other end; that card's dev recommended settling this card first and re-asking the gating question afterwards, on its own evidence.)
3. Does this warrant a release note / advisory, or is it a quiet fix? That is a disclosure call, not an engineering one.

Adjacent, from the same dispatch: #5703 (the ActiveOrganizationStorage in-memory fallback is unreachable when localStorage exists but rejects writes, so the tenant header is never stamped for the whole session) and #5704 (skills/objectui/guides/auth-permissions.md teaches that X-Tenant-ID is what makes tenant scoping work — the framework scopes from the session, and treating the header as identity is the vulnerability plugin-sharing already removed once). #5704 is the same misconception as this card, written down as guidance.

---

Generated by Claude Code

[huangyiirene]

Triage (decision-inbox duty): dropped pm:queue — a needs-user-decision card is by definition not dispatchable, and the coexistence is exactly the half-state the state machine forbids (the ui seat's escalation itself is correct and stands). Standard facets block added below so the inbox digest can grep it; the seat's comment above carries the full analysis.

[facets-block]

• 实际业务需求:泄漏是无条件的(X-Tenant-ID 无任何门)+ 掷硬币的(/api/ 字符串测试决定 Bearer)——元数据动作指向第三方 URL 是真实集成场景,今天每一次都把租户名与(常常)凭证交给对方。
• 项目长远合理性:缓解机制已存在且同文件一行之遥(ConsoleShell.tsx:213 的 sameOriginOnly)——两条 lane 同源(URL 都来自作者元数据)却一硬一软,是漂移不是设计。
• 防 AI 写代码犯错:AI 写的元数据 app 会大量生成 type:'api' 动作;默认不外送凭证、越权外送需显式声明,才是让 AI 结构上写不错的形状。
• 创业阶段不扩散需求:A 复用既有选项零新面;为兼容假想部署而造 opt-in 键(B)是在无证据处扩面。

一句话问题:元数据 type:'api' 动作的 fetch 要不要默认停止向第三方绝对 URL 附带 Bearer 与 X-Tenant-ID?

选项	客户可感知代价
A useConsoleActionRuntime 同样传 sameOriginOnly: true	若存在依赖「off-origin 目标收平台 Bearer」的部署,该集成断开(需显式改造)
B A + 元数据新增显式 opt-in 键(声明凭证外送)	保住异常集成,但新增公开面 + 一个危险键
C 现状	泄漏持续

推荐 A(置信度中高):安全默认收紧优先;断开的那类集成本就该显式声明。本分析看不见什么:①是否真有部署依赖 off-origin Bearer 转发(两席都无法测量真实部署);②是否需要披露/公告(disclosure 判断,工程席无立场)。裁决格式:回「A」/「B」/「C」,披露与否可附一个字(「公告」/「静默」)。裁后执行:A/B ⇒ 晋级 pm:queue 派 ui 席(带回归 pin:同源动作行为不变);同笔重估 #5279 提出的 X-Tenant-ID 门控问题。

---

Generated by Claude Code

[huangyiirene]

Maintainer ruling recorded — A: sameOriginOnly becomes the action-runtime default; quiet fix, no advisory

Provenance: maintainer, 2026-08-22, live session with the triage seat (「同意所有」, item 17 = A + 静默).

State: needs-user-decision → pm:queue (ui seat). Scope: useConsoleActionRuntime.tsx builds createAuthenticatedFetch({ sameOriginOnly: true }), matching ConsoleShell — credentials and the tenant header stop riding to off-origin action targets; same-origin actions pinned unchanged (regression test per the seat's escalation comment); changeset states the behaviour change plainly, no separate advisory per the ruling. An off-origin integration that legitimately needs the bearer declares itself explicitly or proxies same-origin — if the dev finds a shipped example relying on the old behaviour, report before landing. Same stroke: the X-Tenant-ID gating question raised on #5279 is re-read by the ui seat against this ruling (the header now stops at origin for this lane; whether the general wrapper gains an origin gate is #5279-side follow-up evidence, not this PR).

---

Generated by Claude Code

[os-zhuang]

Claim: domain:ui execution seat (seat post #5560), round 20, slot 2 of 3.

• Session: session_01EuPCi56cnGyykygi3z9w4m
• Branch: claude/issue-5702-action-runtime-same-origin
• Worktree: dedicated, one per repo, created off origin/main at 8689166f6
• Domain: domain:ui · Tier: claude-fable-5
• Clause-②: judged no on the contract face, dispatched at ceiling anyway on card content. Nothing in @objectstack/spec moves and no authoring key is added or removed — a metadata type: 'api' action with an absolute target stays valid metadata. What changes is which headers leave the browser, which is a security boundary the maintainer has already ruled on, with a compatibility branch that has to be measured rather than assumed. That is the class where tier buys something in this lane's record, so it goes out at ceiling under the maintainer's 2026-08-22 authorization (「你虽然是 opus，但是可以派 fable 的卡」).

File surface granted (write):

packages/app-shell/src/hooks/useConsoleActionRuntime.tsx
packages/app-shell/src/**/__tests__/** (regression pin only)
.changeset/*

Serial constraints — one hard fence, and it is the important line in this comment:

⛔ packages/auth/src/createAuthenticatedFetch.ts is HELD by #5664 (slot 1, same batch). It is read-only for you. The ruled repair is at the call site, not in the wrapper: useConsoleActionRuntime builds createAuthenticatedFetch({ sameOriginOnly: true }), matching ConsoleShell.tsx:213. If your measurement says the fix belongs inside the wrapper instead — for example that sameOriginOnly does not actually cover X-Tenant-ID — stop and report; do not cross the fence. That finding would be worth more than the patch.

⚠️ Also held: packages/auth/** in full (slot 1) and packages/sdui-parser/** (slot 3, #5709).

Two stale premises in the card, both measured on origin/main 8689166f6 before dispatch:

1. The card cites useConsoleActionRuntime.tsx:300. The construction site is at :308. Verify the line yourself; do not trust either number.
2. The card says "exactly one passes the option". That is true of sameOriginOnly, but there are twelve bare createAuthenticatedFetch() construction sites in the repo, not two — apps/console/src/AppContent.tsx:245, studioEntry.ts:163, FlowRunsPage.tsx:265, ApprovalsInboxPage.tsx:698, ExcelImportBar.tsx:65, CloudAiModelStatus.tsx:91, CloudOnboardingNext.tsx:88, provisionEnvironment.ts:60, ImpersonationBanner.tsx:56, AdapterProvider.tsx:67, and yours. ⛔ The ruling scopes this PR to yours alone. The other ten take their URL from code, not from author metadata, which is the axis the whole card turns on — that is the reason they are out of scope, and it is worth stating in the PR rather than leaving the reader to wonder why you stopped at one. If you measure that any of the other ten also takes a metadata-supplied URL, that is a finding: file it, do not widen this PR.

---

Generated by Claude Code