feat(seer): Gate agent writes behind short-lived capability tokens

[gricha]

The Seer agent now uses a short-lived, scope-bound JWT to call Sentry without receiving the user's full authority. Sentry mints a raw JWT identified by the protected typ: sentry-agent+jwt header, validates its required identity/session/lifetime claims, and derives access from the delegating member capped by the token's scopes.

The core flow is intentionally narrow: minting starts with Sentry's read-only scopes, an under-scoped write returns RFC 6750 insufficient_scope, and a first-party browser session can approve one user/org/Seer-session grant. Reminting then includes the approved write scope. Tokens expire after five minutes; grants expire independently and never exceed the user's current authority. The organization feature flag is checked on every authenticated agent request, so disabling it immediately invalidates already-issued tokens as well as blocking mint and approval. Existing user, organization, and integration tokens continue routing through their existing authenticators.

This PR owns only the token format, authentication/access boundary, grant model and migration, mint/approval endpoints, and core scope enforcement. Release-specific compatibility is stacked in #120173, and audit/action/viewer attribution is stacked above that in #120172.

Design: Seer Agent Write Access

[github-actions]

🚨 Warning: This pull request contains Frontend and Backend changes!

It's discouraged to make changes to Sentry's Frontend and Backend in a single pull request. The Frontend and Backend are not atomically deployed. If the changes are interdependent of each other, they must be separated into two pull requests and be made forward or backwards compatible, such that the Backend or Frontend can be safely deployed independently.

Have questions? Please ask in the #discuss-dev-infra channel.

[github-actions]

This PR has a migration; here is the generated SQL for src/sentry/seer/migrations/0024_add_agent_write_grant.py

for 0024_add_agent_write_grant in seer

--
-- Create model SeerAgentWriteGrant
--
CREATE TABLE "seer_agentwritegrant" ("id" bigint NOT NULL PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY, "date_updated" timestamp with time zone NOT NULL, "date_added" timestamp with time zone NOT NULL, "user_id" bigint NOT NULL, "agent_session_id" varchar(128) NOT NULL, "scope_list" text[] NOT NULL, "expires_at" timestamp with time zone NOT NULL, "organization_id" bigint NOT NULL);
--
-- Create constraint seer_agentwritegrant_unique_session on model seeragentwritegrant
--
CREATE UNIQUE INDEX CONCURRENTLY "seer_agentwritegrant_unique_session" ON "seer_agentwritegrant" ("organization_id", "user_id", "agent_session_id");
ALTER TABLE "seer_agentwritegrant" ADD CONSTRAINT "seer_agentwritegrant_unique_session" UNIQUE USING INDEX "seer_agentwritegrant_unique_session";
ALTER TABLE "seer_agentwritegrant" ADD CONSTRAINT "seer_agentwritegrant_organization_id_fef7e9ff_fk_sentry_or" FOREIGN KEY ("organization_id") REFERENCES "sentry_organization" ("id") DEFERRABLE INITIALLY DEFERRED NOT VALID;
ALTER TABLE "seer_agentwritegrant" VALIDATE CONSTRAINT "seer_agentwritegrant_organization_id_fef7e9ff_fk_sentry_or";
CREATE INDEX CONCURRENTLY "seer_agentwritegrant_user_id_f7f8d1c5" ON "seer_agentwritegrant" ("user_id");
CREATE INDEX CONCURRENTLY "seer_agentwritegrant_organization_id_fef7e9ff" ON "seer_agentwritegrant" ("organization_id");

[sentry-warden]

update_or_create on SeerAgentWriteGrant without a database unique constraint causes MultipleObjectsReturned on concurrent approvals

In sentry/seer/agent_token.py::grant_from_challenge_claims, update_or_create relies on (organization_id, user_id, agent_session_id, scope_list) to deduplicate grants, but no unique_together or UniqueConstraint exists in the model or migration — only a non-unique index. Concurrent approval requests (e.g., a user double-clicking) will both pass the SELECT phase, both INSERT new rows, and a subsequent update_or_create on the same lookup will find multiple rows and raise an unhandled MultipleObjectsReturned, surfacing as a 500.

Evidence

• grant_from_challenge_claims calls SeerAgentWriteGrant.objects.update_or_create(organization_id=…, user_id=…, agent_session_id=…, scope_list=…, defaults={…}) (agent_token.py line 297).
• Migration 0024_add_agent_write_grant.py creates seer_agentwritegrant with only a non-unique Index on (organization, user_id, agent_session_id) — no unique_together or UniqueConstraint on any combination of fields.
• Without a DB-level unique constraint, Django's update_or_create cannot atomically prevent two concurrent INSERTs; both callers will succeed in inserting separate rows.
• On the next call, Django's internal get() inside update_or_create finds multiple matching rows and raises MultipleObjectsReturned, which is unhandled and propagates as an HTTP 500.
• Adding constraints = [models.UniqueConstraint(fields=['organization', 'user_id', 'agent_session_id', 'scope_list'], name='…')] (and a corresponding migration) and catching IntegrityError with a fallback to update() would fix this.

_{Identified by Warden sentry-backend-bugs}

[sentry]

Sentry Snapshot Testing

Name	Added	Removed	Changed	Renamed	Unchanged	Skipped	Status
sentry-frontend sentry-frontend	0	0	0	0	451	0	✅ Unchanged

⚙️ sentry-frontend Snapshot Settings