fix: View as Agent must enforce the target user's data policy

[venkateshsakamuri-lab]

What was going wrong

A new Agent chat thread while Viewing as marts-editor still returned crm.customers rows (including amount). SQL Editor already blocked crm. Direct MCP API calls with a marts-editor token also blocked crm. The Agent path did not.

End-to-end logs for the failing turn (session=fca723ca8171, 14:14 UTC):

1. /api/agent/session minted MCP token 257 for marts-editor and provisioned u-marts-editor.
2. Hermes POST /api/profile/switch returned 200 three times; the session JSON is tagged "profile": "u-marts-editor".
3. mcp__deepsql__get_brain_context and mcp__deepsql__execute_sql authenticated as admin token 253.
4. Audit: EDITOR_QUERY_EXECUTED / clientType=mcp / user_id=1 (admin@demo.local) / SELECT … FROM crm.customers / rowCount=2.
5. Token 257 last_used_at is only the Spring probeMcpAuth right after mint — Hermes never sent it.
6. u-marts-editor has no mcp-stderr.log; u-admin MCP was started on Aug 18 and reused.

Hermes keeps one DeepSQL MCP stdio process, started from the first loaded profile (u-admin). POST /api/profile/switch is explicitly process_wide=False (cookie / thread-local only). A new chat does not respawn MCP. resolveEffectivePolicy(..., actorIsAdmin=true) returns none(), so schema and column policy never run.

probeMcpAuth only proves the minted token works against Spring, not that the live MCP process will use it.

Fix

scripts/local-agent-provisioner.py (the Agent container's /provision handler) now mirrors the minted token onto $HERMES_HOME/deepsql.token and every profiles/*/deepsql.token. The long-lived MCP client re-reads DEEPSQL_TOKEN_FILE per request (mtime cache), so the next execute_sql authenticates as the viewed-as user and policy applies.

Chat-path policy is also fail-closed for unparseable/unhandled SQL and missing actors, and walks CTEs, UNIONs, and nested FROM/WHERE selects.

Merge with main

Resolved conflicts with main (#70 whole-statement schema allowlist + nested protected-table inspectability, #72 brain endpoint authz).

Kept this branch's recursive SELECT walker and fail-closed parse/actor rules. Took main's assertProtectedTablesAreInspectable / namesMatch so a qualified protection (public.customer_profiles) does not catch the same table name in another schema, while an unqualified nested reference still fails closed.

UserDataAccessPolicyServiceTest (24) and BrainControllerAuthorizationSafetyTest (2) pass after the merge.

How to verify

1. View as marts-editor, Agent tab, New chat.
2. Ask: show me all customer information from crm tables.
3. Expect a policy block, not Acme/Globex rows. security_event.user_id for that SQL must be the editor, not admin.

Rebuild/restart deepsql-agent so the container picks up the provisioner change, or copy scripts/local-agent-provisioner.py onto /opt/deepsql-agent/provisioner.py and restart the provisioner process, then reopen the Agent tab (triggers /provision).

Re-test after the fix

Same prompt in a new Agent thread while Viewing as marts-editor. Agent refused CRM; audit user_id=2 / clientAgent=marts-editor.

Agent refuses CRM while viewing as marts-editor
agent_view_as_crm_policy_block.mp4

_{To show artifacts inline, enable in settings.}