feat: allow API keys to log into admin panel with limited scope

[darkspadez]

The following PR allows for users to login with their api key and view their logs, statistics, and enable/disable trace. Also allows them to rotate their key.

[mcowger]

Thanks for this PR — the overall approach is solid and the self-service UX for limited users is well thought out. I've rebased the branch onto main and regenerated the migrations properly (SQLite 0027_green_emma_frost, PG 0031_last_wallow) to resolve the numbering collision with 0030_acoustic_katie_power. No logic changes — just clean drizzle-kit output.

Two things need to be addressed before this can merge:

---

1. Events SSE endpoint leaks all keys' activity to limited users

File: packages/backend/src/routes/management/usage.ts — the GET /v0/management/events endpoint

The endpoint sits inside the authenticate-scoped plugin, so it correctly rejects unauthenticated requests. However, it attaches global listeners on usageStorage (started, completed, error) and forwards every event to the SSE client without filtering. A limited user who subscribes to this stream sees real-time request activity — model, provider, token counts, latency — for all API keys in the system, not just their own.

This breaks the isolation guarantee that is the whole point of limited-principal scoping. An adversarial key holder could passively monitor the usage patterns, provider availability, and error rates of every other key.

Fix: Call scopedKeyName(request) (already exported from _principal.ts) when the handler sets up its listeners, and skip emitting any event whose apiKey field doesn't match the scoped key. Admin principals (where scopedKeyName returns null) should continue to receive all events unchanged.

---

2. Cooldown clear is accessible to all limited users regardless of allowedProviders

File: packages/backend/src/routes/management/cooldowns.ts — the DELETE /v0/management/cooldowns/:provider endpoint

The current guard is:

if (allowed.length > 0 && !allowed.includes(provider)) {
  return reply.code(403)...
}

When allowedProviders is an empty array (meaning "no provider restriction"), allowed.length > 0 is false and the check is skipped entirely — so the limited user can clear the cooldown for any provider. But clearing a provider cooldown is a system-level action with real blast radius: it forces the router to retry a provider that may be cooling down for good reason (rate limit, outage, quota exhaustion). This is not a safe self-service operation for key holders.

Fix: Make both cooldown-clear endpoints (DELETE /cooldowns/:provider and DELETE /cooldowns) admin-only by adding requireAdmin to those specific routes, or by moving them into the adminOnly plugin in management.ts. The limited-user scoping logic in the handler body can then be removed entirely.

---

Everything else looks good. Happy to re-review once these two are addressed.

[darkspadez]

@mcowger all ready for ya!

[mcowger]

@claude review this please, with a valley girl style.

[claude]

Claude finished @mcowger's task in 2m 29s —— View job

---

Valley Girl Code Review™ ✨

Like, omigod, I am SO done reading all 36 files. Here's my full take bestie:

• Read the changed files and gather context
• Review backend security changes (the SSE endpoint + cooldowns fix)
• Review new files (_principal.ts, self.ts, MyKey.tsx)
• Review frontend changes
• Post the most fetch review you've ever seen

---

Overall Vibe ✨

Okay so like, this PR is giving MAJOR energy and the concept is totally cute? Limited users being able to see their own stuff is SO self-service-core and I am here for it. But bestie, 7,356 additions and 355 deletions across 36 files is literally giving me anxiety. That is a LOT of glow-up for one PR. Like, we could have totally split this into smaller looks and it would have been SO much more reviewable. Just saying.

---

The Security Tea ☕ (This is, like, the most important part???)

Issue 1: The SSE Gossip Leak — packages/backend/src/routes/management/usage.ts:385

Oh. My. God. The original GET /v0/management/events endpoint was literally broadcasting EVERYONE's tea to every limited user who connected. Like imagine walking into a room and hearing all of someone else's receipts — model names, token counts, provider errors — for ALL the keys?? That is SO not okay and literally breaks the whole point of scoping. It's giving "accidentally replied-all to the company listserv" energy.

mcowger called this out and darkspadez said it's fixed. I cannot verify the fix is perfect from here since the actual PR diff isn't in this checkout, but the fix pattern mcowger described — filtering by scopedKeyName(request) and passing all events through when the result is null (admin) — is like, the obvious correct answer here, for sure. Make sure the filter is applied to ALL three event types (started, updated, completed, created) and not just, like, one of them. That would be SO embarrassing.

Issue 2: The Cooldown Power Trip — packages/backend/src/routes/management/cooldowns.ts

Okay so the base code here is literally 23 lines and it's giving "open bar to everyone" vibes — no restriction whatsoever on the DELETE endpoints. mcowger's review said the PR added an allowedProviders check but with a bug where an empty array meant "allow everything." Like, as IF! The empty-array edge case is such a classic gotcha and I'm glad it got flagged.

The correct fix (making DELETE /cooldowns and DELETE /cooldowns/:provider admin-only) is the right call. Clearing cooldowns is a system-level power move — it's not a self-service snack, it's a whole meal that only admins should be ordering. Verify the fix →

---

Architecture Glow-Up 💅

The _principal.ts pattern (155 lines, new file) is actually giving really solid separation-of-concerns energy. Like, having one place that answers "who is this user and what are they allowed to see" is SO much cleaner than scattering auth checks everywhere. That's the kind of abstraction that doesn't feel forced — it's literally being used in multiple places right away. Iconic.

The new self.ts endpoint (264 lines) for self-service key management (view logs, rotate key, toggle trace) is a cute feature and makes total sense. One note though: key rotation is a MAJOR power move — make sure it's not just authenticated but also rate-limited or requires the current key as confirmation. Like, you wouldn't want someone who briefly had access to a tab to rotate someone's key. That would be, like, a whole incident.

---

Frontend Notes 💄

MyKey.tsx at 291 lines is serving the feature but that's getting kinda chunky? If it's doing both stats display AND key management (rotate + trace toggle), those might want to be split into components eventually. Not a blocker, just giving future-you a heads up.

OverallTab.tsx at 518 lines is... a lot, bestie. That component is doing heavy lifting and could probably use some decomposition into smaller chart/card components. But again — not blocking, just a vibe check.

AuthContext.tsx getting modified to support both admin-key and API-key login is the right call, but make sure the login flow clearly signals to the user which mode they're in. Like, "you're logged in as a LIMITED user" should be super obvious in the UI so they don't wonder why they can't see the Config tab. The Sidebar.tsx changes (+75/-40) hopefully handle this — make sure routes that limited users can't access are hidden, not just 403'd.

---

Minor Notes That Are Still Giving Me Concern 🤔

• request.query as any appears multiple times in usage.ts — that's fine for now but you're throwing away all the type safety Fastify gives you for free. Like, why have TypeScript if you're just gonna as any it? Consider adding Fastify schema validation with schema: { querystring: { ... } } for at least the main query params.

• The migrations (0027_green_emma_frost, 0031_last_wallow) look clean since mcowger already rebased them. No notes there, those are totally serving correct.

• packages/backend/src/utils/auth.ts got 4 lines added. Would love to know what those 4 lines are doing — hope it's not just a comment, lol.

---

The Verdict 💋

This PR is mostly giving what it's supposed to give. The concept is solid, the scoping design is thoughtful, and the self-service UX is a real improvement. The two security issues mcowger flagged were the real tea here, and they appear to have been addressed.

Before merging I'd just wanna triple-check:

1. SSE filter covers ALL event types — not just completed
2. DELETE cooldown endpoints are truly admin-gated — not just "filtered" for limited users
3. Key rotation has some rate limiting or confirmation — to prevent foot-guns

Like, once those three things are verified? This is SO ready to ship. For sure. ✨