Appetite for multi-principal collaboration (implementing Tenets 6 & 7)?

[oirad03]

Type: Ideas / RFC pre-check — gauging maintainer appetite before I open an RFC PR.
TL;DR: I'd like to add shared-workspace membership + team-scoped knowledge to the
core. Before writing the RFC PR, I want a read on whether multi-tenancy is directionally
wanted, because it touches an area the project has a considered stance on.

What I'm proposing (in one paragraph)

Let a workspace's shared knowledge — its named memory store and its lessons — be made
accessible to a membership set of core-derived principals, gated mechanically at
context-assembly time, with every grant and access audited. Concretely: one new
capabilities.workspace_share SCOPE_CATALOG row (opt-in, capability_default=False),
a workspace-membership resolver alongside the existing project_scope_satisfied gate,
and a workspace-scoped lesson tier. This is the minimum implementation of Tenet 6
("Knowledge that flows, with boundaries… person → team → org") and Tenet 7
("Teammates, not tools"). Single-user behavior stays byte-identical.

Why I think it fits the grain

• It reuses shipped seams rather than inventing a subsystem: SessionPrincipal
  (platform/interfaces.py), the SCOPE_CATALOG data-row pattern (platform/governance.py),
  named MemoryStoreConfig (config/sections.py), and the mechanical project_scope
  lesson/skill gate. capabilities.agentcore is the precedent for "new capability as a
  data row, no evaluator edit, no CONTRACT_VERSION bump."
• The audit trail is free: every governance_permits decision already emits a
  governance_decision SEL row, which is Tenet 6's "auditable."
• The boundary is mechanical (admission at context assembly), not a prompt instruction —
  which is what "sensitive information must never spread" requires.

The tension I specifically want a read on

This cuts against the project's single-tenant identity philosophy — the README is
explicit that Kiro Crew "has no account system of its own" and reports "Daily Active
Crews, not users," with "no way to resolve a copy to a person." A membership model
introduces the notion of distinct human principals over shared state. My read is that
Tenets 6 & 7 already sanction the person→team direction and this is how you'd implement
it — but I'd rather hear "yes, that direction is wanted" (or "no, and here's why")
before an RFC PR, per GOVERNANCE.md's "open an issue and ask" guidance.

Scope I'd propose for v1 (to keep it reviewable)

• In: single host, many principals reaching one Gateway; a membership set with one
  owner who administers it; workspace-scoped lessons with authorship attribution;
  revocation that purges the leaving member's authored lessons (right-to-forget).
• Out / gated: non-owner session takeover and any adversarial containment (gated on
  the unbuilt rfc-app-sandbox-isolation — apps still run with full gateway-process
  privilege today, so v1 is cooperative sharing among trusted principals, not tenancy
  isolation); real-time co-presence; per-team physical memory isolation (this was
  reversed in workspace-config-evolution, so I would not re-propose it); multi-host
  teams and fleet-distributed membership (would compose with rfc-central-governance-ceiling).

Questions for maintainers

1. Is the person→team direction something you want built now, or deliberately deferred?
2. Does expressing membership as a governance SCOPE_CATALOG row match how you'd want
   identity/authorization to grow, or is there a different intended seam?
3. Is gating the containment-requiring parts behind rfc-app-sandbox-isolation the right
   dependency, or does cooperative-only sharing need its own guardrail first?
4. Any prior art or in-flight work I've missed? (I checked the RFC index and found no
   existing multi-principal/identity/team RFC, but agentcore-identity-gateway,
   central-governance-ceiling, and workspace-config-evolution all own adjacent ground.)

I have a full RFC drafted and pinned to main HEAD cc681abe ready to open as a PR to
docs/request-for-change/ if the direction is welcome. Happy to adjust scope based on
this thread first.

[aniruddhaadak80]

One concrete lesson from #7843: a shared authorization predicate is insufficient if each surface normalizes the subject differently. The autonomous paths still passed raw event fields while the dashboard passed validated names/parsed input, so the same deny rule could diverge. Normalize principal and scope once at the common boundary and pin parity across every delivery surface.

[mrpackethead]

Cross-linking a complementary discussion I just opened: #13785 ("Federated lesson-sharing between isolated crews").

It approaches the same person-to-team knowledge goal from the opposite topology to this proposal:

• This one (Appetite for multi-principal collaboration (implementing Tenets 6 & 7)? #10836) = share within one host. Many principals reaching a single Gateway over shared, membership-gated state.
• Federated lesson-sharing between isolated crews (event replication, not a shared brain) #13785 = propagate across many hosts. Keep each crew fully isolated (no shared state or control plane) and replicate lessons between them as events, with a durable log so a new teammate's crew replays the team's accumulated lessons on day one.

The reason I think they pair well: this proposal explicitly scopes v1 to a single host and lists "multi-host teams and fleet-distributed membership" as out of scope. #13785 is precisely that out-of-scope case, handled by federation (copying lessons) rather than by shared state, so it sidesteps the single-tenant-identity tension you flag here while still delivering cross-crew learning. Between the two, maintainers get both topologies (share-within-a-host vs. replicate-across-hosts) for the same underlying goal.