[finding] API keys carry no organization — under the isolated posture a minted key reads no org data at all (no leak, but the key surface is inert)

[baozhoutao]

Recording an observation for the platform to rule on.

Good news first: an API key does not leak across tenants. Every probe below stayed empty or 404 — there is no cross-organization exposure here.

The finding is the other side of that: on a deployment running OS_TENANCY_POSTURE=isolated, a minted key appears unable to read any organization's data, which makes the key surface effectively inert while the console still offers minting.

Measured

Minted as the owner of 测试组织甲, from a session whose active organization was that org:

POST /api/v1/keys {"name":"probe-key-orgA"}
→ 201 {"success":true,"data":{"id":"…","prefix":"osk_…","key":"osk_…"}}

Then, credentials: 'omit' so only the key authenticates:

request (header x-api-key)	result
no auth at all (control)	401 UNAUTHENTICATED
GET /data/sys_user	200, total 1 — only the key's own owner
GET /data/sys_team	200, total 0 (the org has 1 team)
GET /data/sys_team/<orgA team id>	404
GET /data/sys_team/<orgB team id>	404
GET /auth/me/permissions	200 with an empty body — no tenantId, no positions

Attempts to give the key an organization, all ineffective:

• minting with {"organizationId": "<orgA>", "organization_id": "<orgA>"} → key created, still sys_team total 0
• request headers x-organization-id, x-org-id, organization-id → still total 0

Why it lands this way

sys_api_key has no organization column at all — its declared fields are name, prefix, user_id, scopes, expires_at, last_used_at, revoked, key, id, created_at, updated_at (packages/platform-objects/src/identity/sys-api-key.object.ts). Key auth therefore establishes a user but no active organization, and the isolated wall is organization_id = activeOrganizationId (packages/spec/src/security/tenancy-posture.ts:15) — with no active org, no row can match. sys_user is the exception only because it is walled by an enumerated member-id list rather than by the org column.

The decision

1. Intended — keys are a user-level surface, org-scoped automation is meant to use something else. Then the console's API-keys entry should say so, because today a tenant admin can mint a key, get a valid-looking secret, and discover only at call time that it reads nothing.
2. Gap — keys should carry an organization (minted against the active org, or with an explicit org + membership check at mint time), and key auth should establish that org as the request's active organization.

Option 2 is the one that makes the existing UI honest, but it is a real security-surface decision (a long-lived credential pinned to a tenant), so it should be made deliberately rather than by patching the symptom.

Environment

objectos-ee-deploy (Caddy → app → postgres:16, NODE_ENV=production, OS_TENANCY_POSTURE=isolated) on http://localhost:8080, observed 2026-08-13. Two probe keys were minted during this test and are still present on the owner account (probe-key-orgA, probe-key-bound) — they carry no org access, but delete them if the environment is kept.

Related: #8286 (the same isolation wall, described back to callers in analytics SQL).

[hotlong]

Concentrated findings round (maintainer-directed, 2026-08-13): promoted finding → needs-user-decision (stays domain:identity, security added — the fork is a security-surface decision, on the human floor by rule).

Why promoted rather than held: the dead-end is user-visible today on a real EE deployment — a tenant admin can mint a valid-looking key that reads nothing, with no warning at mint time. The evidence is complete (probe table on-card, root cause located: sys_api_key has no org column; isolated wall needs an active org), and both exits change either the console's promise or the credential model, so no seat can settle it.

Four-prism block:

1. Platform long-term coherence — a user-level credential on an org-walled platform is the incoherence; option 2 (keys carry an organization, established as the request's active org) aligns the key model with the tenancy model. Option 1 documents the incoherence honestly but permanently.
2. Measured business pull — found by dogfooding, not a customer; but API-key automation against org data is table-stakes for any EE deployment, and today the surface is inert under isolated. The mint UI already exists, so the pull is "make an existing shipped surface truthful", not new capability.
3. AI-agent error-resistance — option 2 with an explicit org at mint + membership check is a closed structure; today's silent-empty reads are the masked-failure class (200 + total 0). Option 1 only helps if the console copy actually reaches the caller at call time, which it cannot.
4. Startup scope discipline — option 2 is real security-surface work (long-lived tenant-pinned credential: mint-time membership check, revocation-on-membership-loss question, audit). Option 1 is one console string + a docs paragraph.

Recommendation: option 2, scoped to v1 = key inherits the minter's active organization at mint time (no cross-org keys, no org parameter), with a mint-time membership check and org recorded on the row — that is the smallest truthful shape. Option 1 as the interim if appetite is zero this cycle (console copy: "API keys authenticate the user without an organization; under isolated tenancy they cannot read org data"). Prisms 1–3 point at 2; prism 4 is the brake — your call on appetite. Also note the on-card cleanup: two probe keys remain on the test environment's owner account.

---

Generated by Claude Code

[hotlong]

Maintainer ruling — Option 2, minimal v1 scope

Ruled in a live PM session, 2026-08-13, accepting the triage seat's four-prism recommendation in full (maintainer verbatim: 「接受你的全部建议」). Recorded by the triage seat as a ruling record.

Ruling: option 2 (keys carry an organization), scoped to the smallest truthful shape:

• A key is minted against the minter's active organization — inherited, ⛔ not an org parameter, ⛔ no cross-org keys in v1.
• Membership check at mint time; the organization is recorded on the sys_api_key row.
• Key authentication establishes that organization as the request's active organization, so the isolated wall can match.

⛔ Option 1 (document the inertness in the console) is rejected as the destination: it would freeze the incoherence into shipped copy. The console string may still be worth adding as a stopgap while the work lands, at the identity seat's discretion — but it is not the fix.

Prism basis: an existing shipped surface (the mint UI) currently hands a tenant admin a valid-looking credential that reads nothing — making it truthful is not new capability; a user-level credential on an org-walled platform is the incoherence; today's 200 + total 0 is the silent-empty class, while an explicit org + membership check is a closed structure. The brake was startup scope — a long-lived tenant-pinned credential is real security work — which the v1 narrowing above is chosen to keep small.

Follow-through the identity seat must decide explicitly during implementation (report as declared scope, do not silently skip):

• What happens to a key when its owner's membership in that organization ends.
• Whether revocation/audit rows need the organization stamped too.
• Whether existing org-less keys are migrated, refused, or left inert — ⛔ never silently upgraded to org access.

Housekeeping from the card: two probe keys (probe-key-orgA, probe-key-bound) remain on the test environment's owner account — delete if that environment is kept.

State: needs-user-decision → pm:queue, security retained. Blocked-by: none (checked live).

---

Generated by Claude Code