Problem
Agents API access currently assumes agent visibility and execution are tied to a logged-in WordPress user. The access abilities default to is_user_logged_in(), and WP_Agent_Access::get_current_principal() only falls back to a WP user-session principal. That blocks legitimate non-user execution contexts such as public visitors, proxy-authenticated organization members, and signed external audiences.
Concrete scenario
A WP Cloud site is private/proxied at the edge, so any request that reaches WordPress can be treated as an authenticated internal audience. We need a generic way for a host plugin to resolve that request as an audience principal, then grant selected agents an operator role for that audience. Today downstream code would need to bypass access checks, which is the wrong contract.
Proposed shape
- Allow
agents_api_execution_principal resolvers to return non-user/audience principals intentionally.
- Make access abilities pass when a valid principal exists, not only when
is_user_logged_in() is true.
- Extend the authorization policy/access-store contract so grants can target user principals and audience principals.
- Preserve existing WP-user behavior and keep anonymous/public access opt-in.
Acceptance criteria
- A host can resolve a request to an audience principal, e.g.
audience:public or audience:automattician.
agents/can-access-agent and agents/list-accessible-agents work for that principal without requiring a logged-in WP user.
- Grants remain role-based (
viewer, operator, admin) and explicit.
- Existing user grant behavior remains backward compatible.
Related downstream need
Data Machine and Frontend Agent Chat need to expose selected brain agents to a proxy-private audience without a site-specific authorization bypass.
Problem
Agents API access currently assumes agent visibility and execution are tied to a logged-in WordPress user. The access abilities default to
is_user_logged_in(), andWP_Agent_Access::get_current_principal()only falls back to a WP user-session principal. That blocks legitimate non-user execution contexts such as public visitors, proxy-authenticated organization members, and signed external audiences.Concrete scenario
A WP Cloud site is private/proxied at the edge, so any request that reaches WordPress can be treated as an authenticated internal audience. We need a generic way for a host plugin to resolve that request as an audience principal, then grant selected agents an operator role for that audience. Today downstream code would need to bypass access checks, which is the wrong contract.
Proposed shape
agents_api_execution_principalresolvers to return non-user/audience principals intentionally.is_user_logged_in()is true.Acceptance criteria
audience:publicoraudience:automattician.agents/can-access-agentandagents/list-accessible-agentswork for that principal without requiring a logged-in WP user.viewer,operator,admin) and explicit.Related downstream need
Data Machine and Frontend Agent Chat need to expose selected brain agents to a proxy-private audience without a site-specific authorization bypass.