Granular Control over Organization Token Creation

### Problem Statement

Currently, any user within a Sentry organization can create an organization token. While these tokens are limited in scope, primarily used for CI/CD tasks like release creation and sourcemap/DIF uploads, the lack of granular permission control creates several issues:

* **Security Concerns (Perceived):** Organization owners receive notifications for every token creation, which can trigger unnecessary security reviews and raise concerns, even if the tokens are inherently limited in scope.
* **Lack of Access Control:** Organizations with strict security policies may want to restrict token creation to specific roles or users, preventing accidental or malicious token generation.
* **Confusion:** Users might create multiple tokens without proper management, leading to confusion and potential security vulnerabilities if tokens are not rotated or revoked when needed.

### Solution Brainstorm

Implementing a more granular permission system for organization token creation. Something like

1. **Project-Level Token Creation (With Org Level Admin Override):**
* Allow token creation on project levels, that way the scope of the token is more clear.
* Allow an organization admin to override this project-level scope.
* This would allow more control over the scope of the token.
2. **Approval Workflow:**
* Implement an approval workflow for organization token creation.
* When a user requests a token, an organization owner or designated approver would review the request and approve or deny it.
* This would provide an extra layer of security and ensure that tokens are created only when necessary.
3. **Token Management Interface:**
* Develop a dedicated interface for managing organization tokens, including features like token expiration, revocation, and usage tracking.
* This would provide a centralized location for organization owners to monitor and control token usage.

### Product Area

Settings

We want to define a set of [lightweight metrics]() that SDKs can automatically collect for e.g. framework, language or platform, focusing only on signals that **do NOT overlap with Tracing**. Ideally these metrics should give a quick sense of app or runtime health, … while deeper investigation will still rely on traces or profiles.

Examples**:**

* Node.js runtime metrics (e.g., event loop delay, heap usage)
* Prisma-related metrics in Next.js
* Mobile CPU / memory usage to help surface potential ANRs or app hangs

---

**Candidate Metrics (add more below)**

* …

*(please also add ideas, questions or examples in comments)*

The issue names no files, tests, or entry points and combines token-creation proposals with an unrelated metrics request. First clarify which organization-token control is in scope and define its acceptance criteria; done should be one agreed proposal with explicit permission behavior and validation requirements.

Written by the indexing model from the issue text.