Human-team membership and native service-credential audiences for project VMs #1097

Use case

One organization will include several human teams (for example HOA and Tax). Every current and future HOA member needs the same read-only database capability, independent of operator/developer/admin role; future Tax members must not inherit it. Ordinary HOA projects are shared within HOA, with personal scratch sessions still allowed. Production-derived conversations must never be publicly shared. Database read-only privileges do not make cross-team disclosure safe.

This request covers centrally managed human membership and native service-credential grants for project VMs, not static MCP-server authorization.

Source-grounded gap

Inspected public upstream at commit 1161c837, separately from an installed private release. These observations are about public upstream, not a claim that private deployment additions exist here:

• Web turn actor construction sends externalId/displayName, not teamIds. Slack classifyUser likewise supplies no human-team memberships. Slack workspace team_id is used for guest classification, not as an organizational human-team directory.
• Identity classify/resolve classifies active/internal status; resolve only copies supplied actor.teamIds. Team scope access instead consults identity.classify(id).teamIds. There is no membership enrichment in these producer paths.
• Projects use group:web-project- scopes. Existing manual and linked-Slack rosters are useful: effective members, channel roster sync, and current project member resolution. They do not populate human-team identities.
• Admin service-credential grantee validation accepts org/personal/team/channel, but rejects group, including project scopes.
• Native service credentials use audience grants through principalEntitledToScope. A channel grant matches that exact session scope; linking the channel to a project does not turn its grant into authorization for the distinct group:web-project scope.

Together, these paths do not provide a supported end-to-end configuration for automatic human-team entitlement and project-VM service-credential access. Per-person grants need manual onboarding; an org grant is too broad; project roster sync alone does not bridge the credential grant mismatch.

Requested behavior / acceptance

1. Supported, centrally managed human-team membership with an authoritative source, consistently resolved for web, Slack, and current-member/resource authorization. Prefer extending existing identity, directory, managed-group/project-roster, and ACL abstractions; not a request for a new competing directory.
2. One team-level grant should cover every current and future team member automatically, regardless of QM administrative role. Onboarding adds entitlement; removal/deactivation removes future use across existing sessions, cached identity, and reused project VMs, with documented refresh/revocation bounds. Missing or unresolved membership must not silently widen access.
3. Support native service-credential grants for managed project groups, or an equivalent explicit supported binding between a project's current audience and the relevant team. Reuse existing credential delivery/broker machinery; do not merely relax grantee validation without the matching audience checks.
4. Define per-room semantics explicitly. Personal scratch uses the acting person's current entitlement. Shared-project use must account for everyone who can receive results or access the VM, not only the caller. Adding a non-entitled member must not leave team credentials usable in that room; require an explicit authorized grant or deny. Linking a Slack channel must not implicitly equate channel and project grants or silently expand their audiences.
5. Ordinary team projects can follow current team membership without repeated individual invitations/grants, while genuinely private scratch remains private. A different team's organization membership must not grant access. Keep raw credentials out of participant-visible configuration/prompts, retain actor/scope attribution, and define safe treatment of already-materialized credentials when membership changes. Revocation cannot undo information already disclosed.
6. Do not require public links or public conversation sharing as an access workaround. This policy prohibits public sharing of production-derived conversations. Database credentials remain database-enforced read-only for every role; QM membership controls who may use them and where results may be disclosed.

Related, not substitutes

• Team and room entitlements for shared-credential MCP servers #1094 owns static/shared-credential MCP server tool-discovery/invocation entitlements. This issue supplies the human-membership/project/native-service-credential side; fixing one alone does not fix the other.
• Channel-scope crons can never receive env-delivered service credentials (allInternal gate always false) #875 concerns cron env-delivery audience construction, not centrally managed human-team membership or the project grantee mismatch.
• Keychain credentials cannot be materialized for a non-agent session (SSH or browser IDE) on a shared-scope sandbox #550 concerns personal keychain materialization for non-agent SSH/IDE sessions, not native shared service-credential audiences.
• Triage: fix(slack): refresh identity caches on user_change/team_join events #761 concerns Slack identity cache refresh/profile events, not organizational human-team membership.

Evidence: source inspection and existing-issue search only. No database queries, cross-team access attempt, live QM operation, or functional test performed. No downstream core patch requested.