- Shipped
- October 28, 2026 at 6:50 AM UTC
- Author
- Kamo
- Commit
- b54c796
TPONBEHALF (owner 2026-10-28): Sage asked Luna how many notifications HE got today and she could only read her own. On an authenticated request from anyone up the SI's chain of command, a tool's AI copy now takes onBehalfOf: "requester" (offered in that run's tools/list, naming them): the planner and handler run on a short session of the requester's own account that SecurityService mints for the run and tool, so every service answers with their notifications, mail, calendar, tasks. Every gate still judges the SI (charter, union rights, limits, taint, identity guard, PHI, outreach). - Reads need only their authenticated question; changing anything on their account needs a direct order. - The account is always the order's author (the only value is "requester"): never another member's. - Refused in plain words: no authenticated request (NO_ORDER), a question for a write (NOT_AN_ORDER), not in the chain of command, another SI, the SI's own work (identity, self, collab, memory, workstation, approvals, disclosure, oversight, wakeup, iot). - Audit: authority_basis SI_ON_BEHALF_OF_MEMBER on mcp_tool_call_audit, and a si_on_behalf_actions row written BEFORE the action (no row, no action) and completed with its outcome. - A read through their own account for them alone is a SELF read (OrderPrincipal.ownAccount). - An on-behalf session presented to the Tool Plane itself is refused. - NotificationsPack: SI_ASSISTANT_REPLY (Voice Assistant's new kind) decided as not offered to SIs. Tests: ToolCallPipelineOnBehalfTest 12, OrderPrincipalOwnAccountTest 2; full suite 2038 green but the two notification-kind guards, fixed here.