Problem
Agents API conversation-session abilities currently treat a WordPress user ID as the ownership boundary. That works for logged-in users, but it does not support non-user principals such as an anonymous browser session, audience:public, or a proxy-authenticated audience.
Public frontend chat now has explicit audience access grants, but session history cannot safely persist because agents/list-conversation-sessions, agents/get-conversation-session, and related abilities resolve to an acting_user_id and reject anonymous principals.
Required shape
- Conversation-session abilities operate on
WP_Agent_Execution_Principal, not only acting_user_id.
- Store contracts can identify ownership by a stable principal key derived from the principal, including non-user principals.
- Existing user-owned session behavior remains backward compatible.
- Public/audience access to an agent does not imply access to all sessions for that audience or the agent owner.
Acceptance criteria
- A host can resolve a browser principal and list/get/delete only sessions owned by that principal.
- Existing logged-in user session listing/get/delete behavior still works.
- Existing
WP_Agent_Conversation_Store implementations have a compatibility path.
- The API keeps runtime authorization separate from transcript ownership.
Related work
Problem
Agents API conversation-session abilities currently treat a WordPress user ID as the ownership boundary. That works for logged-in users, but it does not support non-user principals such as an anonymous browser session,
audience:public, or a proxy-authenticated audience.Public frontend chat now has explicit audience access grants, but session history cannot safely persist because
agents/list-conversation-sessions,agents/get-conversation-session, and related abilities resolve to anacting_user_idand reject anonymous principals.Required shape
WP_Agent_Execution_Principal, not onlyacting_user_id.Acceptance criteria
WP_Agent_Conversation_Storeimplementations have a compatibility path.Related work