feat: add agent selection to MCP authorization challenge

[danielkov]

Summary

Adds a feature-gated picker for eligible existing agents in the MCP authorization challenge. Agent approval is bound to the challenged endpoint's fixed mcp:connect policy and rechecks the human authorizer, agent lifecycle and ownership, direct agent policy, and owner policy before producing the authorization handoff.

Technical details

Stacked dependency

Targets main; the prerequisite #6055 is merged.

Authorization boundary

The picker lists same-organization agents that the caller may authorize and whose direct policy permits the requested endpoint. Approval creates no agent, reusable consent, credential, or admission decision; the downstream agent-session minting path consumes the isolated authorization handoff, and token redemption fails closed until that path is available.

Agent approval uses distinct consent actions and cache namespaces so older servers cannot silently reinterpret it as human approval during a rolling deployment.

---

Summary by cubic

Implements AIM-196 by extending the MCP authorization challenge from human-only approval to a feature-gated choice between the human and an eligible existing same-organization agent. Agent approval uses a fixed endpoint-scoped mcp:connect handoff; it creates no agent, reusable consent, credentials, or session, and token redemption fails closed until agent-session support exists.

Authorization safeguards

• Lists only active, unblocked agents whose owner is active and whom the caller owns or may authorize with exact agent:authorize; live direct-agent policy must allow the challenged endpoint.
• Rechecks the authorizer, tenant, lifecycle, ownership, endpoint, direct agent policy, and owner policy at final approval; meta endpoints cannot select agents.
• Records the human authorizer at the first IDP callback and rejects identity replacement, including legacy agent-consent states.
• Uses separate consent actions and grant-code namespaces so mixed-version servers cannot interpret agent approval as human approval.
• Presents actor radio cards, fixed-policy details, the selected agent name, and an Agent management link when no eligible agent exists.

Rollout

• Keep gram-agent-management-m1 and gram-agent-mcp-authorization-m2 disabled for production cohorts until AIM-199 passes; existing human-only and in-flight challenges remain unchanged.
• Treats Stripe checkout compare-and-swap conflicts as HTTP 409 and stabilizes concurrent server test checks.

^{Written for commit 0e4dd56. Summary will update on new commits.}

[linear-code]

AIM-196

[changeset-bot]

⚠️ No Changeset found

Latest commit: 0e4dd56

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[cubic-dev-ai]

Running ultrareview automatically — This change introduces a new agent authorization path in the MCP consent flow, touching authorization logic, new SQL queries, cache namespaces, feature flags, and token redemption with security-sensitive fail-closed behavior.... I'll post findings when complete.

[danielkov]

Demo

What it shows:

1. The MCP consent starts with the synthetic human authorizer selected.
2. Choosing the eligible existing Release assistant switches the consent to agent authorization.
3. The endpoint-scoped mcp:connect explanation appears, the summary changes to Authorizing, and the action becomes Authorize agent.

[cubic-dev-ai]

Ultrareview completed in 13m 20s

All reported issues were addressed across 20 files

Not reviewed (too large): server/internal/mcp/consent_assets/consent-tools.js (~2 lines) - if these are generated or fixture files, add them to ignored paths to exclude them from future reviews.

Linked issue analysis

Linked issue: AIM-196: feat: add agent selection to the existing MCP authorization challenge

Status	Acceptance criteria	Notes
✅	Allow an authenticated human to choose self or an eligible existing agent.	The consent screen adds an agent selector for resolved human sessions, with same-organization candidate filtering and support for owners or callers with exact agent:authorize permission.
✅	Show only active, unblocked agents whose live direct policy allows endpoint-scoped mcp:connect.	Candidates are filtered for lifecycle, deletion, owner membership, organization, and live agent policy using the challenged endpoint and fixed mcp:connect check.
✅	Repeat authorizer, tenant, lifecycle, ownership, endpoint, direct-policy, and owner-policy checks at final authorization.	The final approve_agent path reloads the endpoint and reruns target matching, human membership/policy, agent lifecycle and ownership, direct agent policy, and owner policy checks.
✅	Fix the requested policy to endpoint-scoped mcp:connect without broadening scope, switching endpoints, mutating direct agent policy, or creating an agent.	The authorization target snapshots the endpoint and mcp:connect scope, validates it against the final endpoint, and the flow only records a handoff; it does not create agents or update policy.
✅	Require explicit agent authorization, disable reusable consent for agent subjects, and fail closed until agent-session minting exists.	Agent approval uses a distinct approve_agent action, skips reusable consent persistence, stores an isolated agent grant namespace, and token redemption rejects the handoff until the downstream session lane is available.
✅	Keep existing human-subject MCP authorization behavior unchanged.	Agent-specific UI and processing are gated behind resolved human authorization and selected-agent state; self approval continues through the existing consent and tool-selection paths.
⚠️	Keep agent selection disabled for production cohorts until the AIM-199 safety gate passes.	The PR adds independently default-off M1 and M2 feature gates and documents the safety-gate dependency, but the diff does not show an explicit AIM-199 evaluation or enforcement beyond operational flag configuration.

<sub>Tip: instead of fixing issues one by one fix them all with cubic

Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 13 files (changes from recent commits).

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>