[Epic]: Project-based AI governance — delegated model access & quota control via project leads

### Type

Epic

> **History:** This started as an experimental spike ("Extend RBAC to control which models a user can access"). The feature has since been **officially requested** — promoted to an Epic. The original spike's investigation is folded into the ADR task below. Intended labels: `epic`, `governance`.

### Summary

Introduce **projects** and **project leads** as a first-class delegated-administration layer in the AI governance system. Project leads — who are not necessarily members of the AI governance team — can regulate the AI resources of their team: manage project membership, assign per-member quota tiers, and control which models their members may call. The governance team retains the outer envelope (tier menu, per-project ceilings, global model catalog); leads allocate within it.

This subsumes the original per-model RBAC question: model access becomes a **project-level allowlist**, enforced per-request at the gateway.

### Intent

- Say "this member of project P may use models X and Y at tier `t-m`, not Z" and have the gateway enforce it — with the *project lead*, not the governance team, making that call.
- Changes take effect in seconds (bounded by Authorino metadata cache TTL), not token lifetime.
- Works across IDPs: Keycloak humans, forwarded LibreChat users, service accounts, and GitHub-OIDC CI callers — anything that resolves to an `x-account-id`.

### Architecture (agreed direction)

Keycloak alone cannot do this (GitOps'd realm via keycloak-config-cli vs. runtime self-service; no quantitative policy; claim staleness; multi-IDP callers that never touch Keycloak). The design generalizes the **ADR-0047 resolve pattern**:

1. **LightBridge Postgres** is the project registry: `projects`, `project_members(account_id, project_id, role, quota_tier)`, `project_model_allowlist`. Leads manage via the LightBridge API/MCP under project-scoped RBAC.
2. **Authorino** (both plane AuthConfigs) adds a `when`-gated, TTL-cached **metadata** call to a LightBridge resolve endpoint keyed on the resolved `x-account-id`; an **authorization** CEL rule denies models outside the project allowlist; response headers stamp `x-project-id`, `x-project-role`, `x-quota-tier` (extends the ADR-0011 contract).
3. **Envoy `BackendTrafficPolicy`** enforces quota via **discrete tiers** (static tier menu in `ai-helm-values`, per ADR-0021/0035 rule composition): per member-in-project rule + per-project envelope rule.
4. **No standalone OPA**: the old `authz-opa` component was never Open Policy Agent — it was the external validation endpoint, and that surface is what returns (renamed). Complex logic, if ever needed, uses Authorino's embedded OPA. The `usage` service stays dead (Mimir owns metering, ADR-0058).

### Source of truth (links)

- Identity/access epic: #140 (relates).
- ADR-0011 (`x-oidc-*` contract), ADR-0021 (dual-plane AuthConfigs + descriptors), ADR-0035 (per-person budget), ADR-0047 (`lightbridge-repo-auth` resolve pattern — the template), ADR-0026 (why `opa`/`usage` were dropped — partially superseded by this epic's ADR).
- Repos: `ADORSYS-GIS/lightbridge-authz` (Accounts → Projects → API keys schema + `/v1/authorino/validate` already exist; membership model is the gap), `charts/kuadrant-policies` / `security-policies` values, `charts/ai-model` BTP, `charts/ai-models` `rateLimitBudgeting`.

### Acceptance Criteria (epic-level)

- [ ] ADR accepted defining the project model, descriptor contract, and GitOps/runtime data boundary.
- [ ] A project lead (non-governance user) can add/remove members, assign quota tiers, and edit the project model allowlist — self-service, within the governance envelope.
- [ ] A member restricted to a model subset is denied the others at the gateway (demonstrated on both planes).
- [ ] Quota tiers enforce per-member-in-project and per-project monthly ceilings; rules compose with existing plan budgets.
- [ ] Membership/tier changes take effect ≤ metadata cache TTL (target ≤60s); revocation demonstrated.
- [ ] Per-project attribution visible in Grafana (labels + budget-burn), fed from the existing Mimir path.
- [ ] Failure mode of the resolve service (fail-open vs fail-closed) is decided, documented, and tested.

### Out of Scope

- Arbitrary per-member dollar amounts (exact-budget enforcement via Authorino-side denial) — captured as a possible follow-up ADR if the discrete tier menu proves too coarse.
- Resurrecting the LightBridge `usage`/TimescaleDB service.
- Self-serve project *creation* by arbitrary users (governance team provisions projects; cf. ADR-0049's operator-first stance).

### Risks

- Resolve endpoint becomes a synchronous dependency on the auth hot path — mitigated by Authorino metadata caching; fail-mode must be explicit.
- Descriptor/label cardinality: `project_id` is bounded (≈ tens), safe as a Loki/Mimir label; keep per-member keys out of labels per ADR-0011 discipline.
- GitOps boundary blur: tier menu + envelopes in `ai-helm-values`, memberships in Postgres — the ADR must pin this down.

### Tasks

- [ ] ADR: project-based delegated governance (see sub-issues)
- [ ] LightBridge: membership/tier/allowlist schema + lead RBAC
- [ ] LightBridge: Authorino-facing resolve endpoint
- [ ] Authorino: metadata step + model-allowlist authz + project descriptors
- [ ] Envoy: tier-keyed BTP rules + project envelope
- [ ] Lead self-service surface (API/MCP/UI)
- [ ] Observability: per-project attribution + dashboards
- [ ] E2E verification & docs

(Sub-issues linked below.)

### Human accountable owner

@Koufan-De-King

### AI Usage Declaration

- [x] Drafting the ticket
- [ ] Not used
- [x] I have declared AI usage above (ticked the relevant items, or "Not used").

### Human verification completed

- [ ] I understood the intent
- [ ] I checked the source of truth
- [ ] I reviewed all AI-generated text/code
- [ ] I verified the implementation manually
- [x] I checked for hallucinated assumptions
- [x] I am the accountable owner and accept responsibility for this ticket.