Digest identity mismatch: rebind cross-wired Edge City village credentials + hardening

[yanekyuk]

Follow-up to the daily-digest "self-opportunity" investigation. The guardrails (defense-in-depth for the self-match / wrong-caller data classes) shipped in #910. This issue tracks the actual root-cause fix and related hardening, which are operational / out-of-scope for that hotfix.

Background

A user (Seren) saw a daily-digest opportunity (list_opportunities MCP call) that appeared to match her with herself. Clicking the connect URL opened a conversation seeded with an intro written in someone else's first-person voice:

"Hi Seren, I came across your profile … Given my involvement with Edge City … I'd love to connect …"

Confirmed mechanism

The greeting is always built from getProfile(viewerId) (opportunity.presenter.ts:608,750), and the digest mints the connect link with viewerId = context.userId (opportunity.tools.ts). The message being addressed to Seren but written in the Edge City user's voice means the card was rendered with viewerId = the Edge City user, counterpart = Seren.

AgentVillage's Edge — daily digest cron runs list_opportunities using the single INDEX_API_KEY baked into that village's config.yaml → mcp_servers.index.headers["x-api-key"] (packages/agentvillage/install/install_index.ts:64). MCP resolves that key to one user via apikeys.referenceId ?? apikeys.userId (backend/src/controllers/mcp.controller.ts:387).

Conclusion: Seren's village agent authenticates to Index as the Edge City user — her morning brief is (partly) that user's opportunity feed, so a connection that user has toward Seren surfaces in Seren's brief as "an opportunity with herself," with the other person's identity + greeting on the connect link.

Ruled out (verified in code)

• Discovery self-match — a true [Seren, Seren] opp is skipped in digest mode (opportunity.tools.ts:1514).
• Connect-link reuse / delivery-card cache leak — keyed by (opp, userId, kind) and viewerId respectively.
• MCP request-context concurrency clobber — AsyncLocalStorage, per-request userId.

---

Tasks

1. Verify the binding (do first)

• connect_links row for the clicked code → confirm userId is the Edge City user (not Seren) and the opportunity actors are a legit [EdgeCity, Seren] pair (not a degenerate self set).
• Hash the x-api-key from Seren's village config.yaml (SHA-256 → base64url) and SELECT userId, referenceId FROM apikeys WHERE key = <hash> → does it resolve to the Edge City user?
• Confirm Seren's email maps to a single distinct Index user (rule out a ghost-contact / email collision at network-invitation.service.ts:217 having merged her with the Edge City account — that would be a data fix, not a key swap).

2. Immediate rebind (one resident)

• Mint Seren a correct key bound to her account: networkInvitationService.resendInvite({ networkId, memberId: <serenUserId> }) (adapter sets referenceId = userId = Seren, so it resolves correctly — agent-token.adapter.ts:101).
• Re-point her village at the new key (re-run install_index.ts, or update config.yaml + .env and let the 08:00 cron pick it up).

3. Systemic fix (the cohort)

• Find how her village got the wrong key — the provisioning/control-plane that ran each install_index.ts with --index-api-key. (Lives outside indexnetwork/index and Edge-City/agentvillage; needs a pointer to the entrypoint or the resident→key map.)
• Audit the Edge City import cohort for other cross-wired villages and rebind any found.

4. Hardening (optional, separate PRs)

• Telegram-handle ↔ userId consistency guard: village installs pass --telegram-handle → MCP request carries x-index-telegram-username. Assert the authenticated key's user actually owns that handle; reject/log on mismatch. This is the one server-side signal that would have caught this incident.
• mcp.controller.ts:387 precedence: referenceId ?? userId is benign today (adapter sets them equal) but resolves to the wrong principal if any key ever has referenceId ≠ userId. Prefer the verified session userId, or assert referenceId === userId for agent keys.

---

Done (for reference)

• fix(protocol): guard against self-match opportunities (hotfix) #910 — fix(protocol): guard against self-match opportunities (hotfix) → main. Persist-time self-match rejection + read-time "caller must be an actor" skip/log in list_opportunities. @indexnetwork/protocol 1.26.6 → 1.26.7.

https://claude.ai/code/session_0157jBxKSVKaJG43XAWJNsGU

[yanekyuk]

Opened PR #912 for the in-repo hardening portion: Telegram-surfaced MCP requests now reject/log when the request Telegram handle does not match the authenticated user or belongs to another user, and MCP agent API keys with divergent userId/referenceId are rejected. Verified with targeted MCP surface tests, backend build, and targeted ESLint.

Operational verification/rebind tasks still require the clicked connect code, Seren village config/API key hash, and DB access to inspect live rows.

[yanekyuk]

Task 4 (Hardening) — done via #912 (merged to dev, merge a369d4a783)

Both hardening items are implemented and merged:

• Telegram-handle ↔ userId consistency guard — finalizeMcpIdentity now verifies, for telegram-surface MCP requests, that the request's x-index-telegram-username/-handle matches the authenticated user's stored telegram handle and isn't owned by another user, rejecting on mismatch. This is the server-side signal that would have caught this incident. Stored @h / t.me URL variants (incl. trailing slash, ?start= query params, and uppercase HTTPS://T.ME/) are normalized to the bare handle in SQL (findTelegramHandleOwners).
• mcp.controller.ts precedence — API-key principal resolution is now centralized in src/lib/apikey/principal.ts (resolveApiKeyUserId), shared by the MCP auth resolver and AuthOrApiKeyGuard so a key can no longer resolve to different users across codepaths. It prefers a verified session, then userId, then referenceId, and rejects (fails closed) any key whose two principal columns are both set but disagree. Agent keys must additionally carry both columns.

Verified: unit + integration tests (incl. divergent-column rejection and telegram URL-variant ownership), CI green, five Copilot review rounds resolved.

Still open (operational — tasks 1–3)

The root-cause rebind is not addressed by #912. Outstanding:

• Verify the binding (DB checks for the clicked connect_links / hashed x-api-key → which user).
• Rebind Seren to a correct key + re-point her village.
• Find how the wrong key was provisioned (control-plane, outside this repo) and audit the Edge City cohort for other cross-wired villages.

⚠️ Deployment note: now that the telegram guard is live on dev, any user whose stored telegram handle is fabricated (see Linear IND-352 — the agent hallucinating handles at onboarding) will be rejected when their real inbound handle differs from the stored one. Auditing user_socials.telegram for bad values should precede relying on this guard in production.