Surfaced by the whole-branch review of the connection-id guard slice (#56 follow-up). Not caused by that slice — it made an existing gap visible.
The gap
PluginAPI.connections.list() is personal-only. But sessions.open's findConnection and auditSeam.auditAgentAction both know about team connections. So for a team connection:
- The agent's
list_connections never returns it, so the model cannot learn its id.
- The new connection guard resolves ids against
connections.list(), so even a correct team connection id is rejected.
- Net effect: the AI agent cannot address a team connection at all.
This fails closed and safely — the guard's rejection is the conservative outcome, and deriveScope would refuse to scope such a connection anyway, so no grant is mintable for one. Nothing here is a security hole. It is a capability gap that will read as a bug to anyone on a team plan: their agent silently cannot see half their infrastructure.
Shape of the fix
Decide whether the agent's view of connections should include team connections, and if so:
- Extend the plugin-facing
connections.list() (or add a team-aware verb) so list_connections, the guard, and deriveScope all resolve from one source. They must agree — a guard that resolves an id deriveScope would refuse, or vice versa, reintroduces the display-vs-authority divergence slice 3e closed.
- Work out what allowlist scoping means for a team connection: grants are keyed on a connection id today, and a team connection id is shared across members. A grant one member creates would otherwise silently authorize another member's agent.
- Check the audit path:
auditAgentAction already handles team connections, so it is the one piece that would need no work.
The second point is the real design question and probably needs its own brainstorm — do not treat this as a one-line widening of a list call.
Reference
.superpowers/sdd/ whole-branch review for the connection-id guard slice, and spec §5.4 in docs/superpowers/specs/2026-07-26-ai-agent-connection-id-guard-design.md.
Surfaced by the whole-branch review of the connection-id guard slice (#56 follow-up). Not caused by that slice — it made an existing gap visible.
The gap
PluginAPI.connections.list()is personal-only. Butsessions.open'sfindConnectionandauditSeam.auditAgentActionboth know about team connections. So for a team connection:list_connectionsnever returns it, so the model cannot learn its id.connections.list(), so even a correct team connection id is rejected.This fails closed and safely — the guard's rejection is the conservative outcome, and
deriveScopewould refuse to scope such a connection anyway, so no grant is mintable for one. Nothing here is a security hole. It is a capability gap that will read as a bug to anyone on a team plan: their agent silently cannot see half their infrastructure.Shape of the fix
Decide whether the agent's view of connections should include team connections, and if so:
connections.list()(or add a team-aware verb) solist_connections, the guard, andderiveScopeall resolve from one source. They must agree — a guard that resolves an idderiveScopewould refuse, or vice versa, reintroduces the display-vs-authority divergence slice 3e closed.auditAgentActionalready handles team connections, so it is the one piece that would need no work.The second point is the real design question and probably needs its own brainstorm — do not treat this as a one-line widening of a list call.
Reference
.superpowers/sdd/whole-branch review for the connection-id guard slice, and spec §5.4 indocs/superpowers/specs/2026-07-26-ai-agent-connection-id-guard-design.md.