Fix connector permission defaults and approval recipient targeting

[Konan69]

Summary

Read-only Exa web search in Flow Research requested human approval, then member approval returned 403 Forbidden. A production DB patch unblocked Flow Research, but the systemic fix is not complete.

Postmortem: docs/known-gaps/connector-permission-defaults-postmortem-2026-06-20.md

Current status

• Flow Research DB patched:
  • Garden agent has auto grants for exa-search.web_search_exa and exa-search.web_fetch_exa.
  • stale Exa permission requests were marked approved.
  • stale approval inbox items were archived/read.
• Local commit exists: 7a20cde0 Fix default connector permission fallback.
• Not fully fixed until deployed and broader recipient/backfill gaps are addressed.

Root causes

1. MCP proxy defaulted missing permission_grant rows to ask instead of risk defaults (read -> auto, write -> allow, sensitive -> ask).
2. Old workspaces can miss default permission grants.
3. Permission approval inbox items are sent to all workspace members, including members who cannot approve.
4. The UI exposed an actionable approval card to a user whose role cannot resolve it.

Acceptance criteria

• Deploy the MCP proxy fallback fix so missing grant rows use defaultTrustLevelForRisk.
• Backfill missing permission grants for every existing (workspace agent, capability) pair.
• Change approval inbox targeting so only users with permission.approve / permission.grant receive actionable permission approval items.
• Render member-visible approval blockers as non-actionable if product still wants members to see them.
• Add integration coverage for read-only connector tools with no grant row.
• Add integration coverage for permission approval inbox recipients by role.
• Add an audit/health query for missing permission grants and stale approval requests after grants are repaired.

Verification notes from incident

Bashir remains a Flow Research member; he should not be able to approve/grant connector permissions. He should be able to use Garden chat with Exa read tools after the agent grant repair because the grant belongs to the Garden agent, not to the individual member.

[Umoren]

I’m taking the missing permission-grant backfill slice from this issue.

I checked the current implementation:

• 7a20cde0 added the missing-row runtime fallback.
• c4a2669b restricted actionable approval items to workspace owners/admins.
• Agent creation and capability sync now seed default grants for future records.
• Existing agents can still have missing (agent, capability) grant rows.

Scope:

• Add a read-only audit for missing grant pairs, grouped by workspace and risk class.
• Add an idempotent data migration that inserts only missing grants.
• Derive defaults from the existing risk mapping: read -> auto, write -> allow, and sensitive tools -> ask.
• Preserve existing grants and use the agent owner for granted_by.
• Add integration coverage that runs the backfill twice and verifies the second run creates no changes.
• Record the before, inserted, and after counts in the PR.