[ROSETTA] Authorizer team policy checks any owner team, not the dataset's owner

[isolomatov-gd]

`Authorizer.check_team_membership` in `src/rosetta-mcp-server/rosetta_mcp/services/authorizer.py` (lines 68-94) receives `dataset_name` but discards it (` = dataset_name`, line 76). Under `ROSETTA_READ_POLICY=team`, the docstring says access requires membership in the dataset's owner team, but the implementation grants read access if the user is in ANY team visible to the API token with role "owner" — with no correlation to which team actually owns the requested `project-*` dataset.

`tests/test_authorizer.py` only ever exercises a single dataset against a single team, so this per-dataset scoping gap is untested. Effect: under team policy, any team member could read any other team's project dataset. Where: `src/rosetta-mcp-server/rosetta_mcp/services/authorizer.py`.

[github-actions]

Rosetta Triage

Classification: bug, security — confirmed authorization logic flaw, not just a documentation gap
Priority assessment: High — under ROSETTA_READ_POLICY=team (a supported, documented policy), any member of an owner-role team can read any other team's project-* dataset via MCP. Not exploitable under the default policy (all), and aia-* datasets are unaffected, but it defeats the purpose of choosing team policy for multi-tenant deployments.

Findings:

• Confirmed in src/rosetta-mcp-server/rosetta_mcp/services/authorizer.py:76: _check_team_membership receives dataset_name and immediately discards it (_ = dataset_name). It then checks membership across all owner-role teams visible to the API token (falling back to all teams if none have role owner), with no correlation back to which team actually owns the requested dataset.
• tests/test_authorizer.py's TestProjectDatasetsTeamPolicy cases all use a single dataset (project-myapp) against a single team (tenant-1) — a fixture shape that cannot surface cross-dataset scoping, so the gap is untested by design rather than by oversight in one test.
• RAGFlowTeamAPI (_ragflow_team_api.py) exposes list_teams/list_team_members but nothing that maps a dataset name/id to its owning tenant — the missing correlation isn't just unused in authorizer.py, the lookup itself doesn't exist yet anywhere in this client.

Caveats:

• Fixing this requires a dataset→owning-tenant lookup that doesn't currently exist in RAGFlowTeamAPI or DatasetLookup — this is more than a one-line correlation fix; it likely needs a new RAGFlow API call (or metadata field) to resolve a project-* dataset's owner tenant before comparing against user_email's teams.

Suggestions:

• Add a method resolving dataset_name → owning tenant_id (RAGFlow dataset metadata likely carries this), then in _check_team_membership restrict the membership check to that single tenant instead of iterating every owner-role team.
• Extend test_authorizer.py with a multi-dataset/multi-team fixture (e.g. team A owns project-a, team B owns project-b) asserting a member of team A is denied read on project-b.

Next steps: Actionable as reported — root cause and fix location are both identified above; awaiting a maintainer/assignee to implement the dataset→tenant correlation.

Automated triage by Rosetta agent