Share and Revoke Without Leaking Authority
Let a customer share one generated application without confusing platform membership, runtime identity, and application access.
System map · Day 11
Whole-system design
Five stable layers. Today's work is expanded and linked; the rest stays in context.
Product and authority
Covered — Generated application plane
People and product entry points
Source-backed today
Lets an owner share a provider project with a collaborator and observe the resulting bounded access.
Identity and policy
Source-backed today
Rejects authority beyond the explicit grant and preserves owner-only lifecycle operations.
HelixWorks control plane
Source-backed today
Creates and revokes the collaborator grant while retaining the project as the authoritative scope.
Delivery and desired state
Covered — CI and immutable artifactsAhead — Git desired state · Argo CD reconciliation
Cloud and orchestration
Covered — Terraform and AWS APIs · Accounts, VPC, DNS, and private paths · Kubernetes or EKS control plane
Compute and traffic
Covered — Worker compute · Platform service workloads · Generated app workloadsAhead — Ambient mesh data plane
Storage and evidence
Covered — Product data and artifactsAhead — Infrastructure state · Cluster desired and live state
Evidence and observability
Source-backed today
Records grant, use, denial, and revocation evidence so cached or lingering access is detectable.
The enterprise problem and today’s slice
Enterprise problem: A workspace owner needs to share a HelixWorks application, but copying a URL or reusing workspace membership can expose another tenant’s data and leave no reliable way to revoke access. Whole-course context: The current platform has provider identity, project state, artifact preview, and connector metadata; today adds a named provider collaborator. Today’s slice: We implement and test provider-plane share/revoke while preserving separate hosted-runtime and generated-app grant designs that do not yet exist in code. End-of-day evidence: Durable collaborator state, owner-only mutation, revoked-collaborator denial, unaffected owner access, and share/revoke audit actions prove the implemented boundary. Still unsolved: App-local roles, expiry, session invalidation, immutable publication, public release policy, and rollback remain deferred.
Customer outcome and implementation focus
The customer outcome is a reviewable share and revoke without leaking authority change, not a collection of requirements. This day starts with the implementation boundary, then uses the command or manifest below to produce positive, denied, and recovery evidence.
Components in focus
Collaboration API, policy evaluator, notification worker, and audit service; application pods; grant database and immutable evidence storage; cache: not involved for grant decisions.
This map names the implementation boundary for this day. The service or controller changes only the state it owns; runtime and audit evidence let the operator distinguish a declared change from an effective one.
Apply, observe, and revoke a sharing grant
Run the grant evidence loop
A configuration that looks scoped can still be implemented as a permissive check, so exercise both sides of the boundary. The current Python model implements owner-controlled provider collaboration, including the rule that the owner cannot be revoked; it has no generated-app role, expiry, or session service. Read the exact methods in services/control_plane/domain.py.
def share(self, project: Project, actor: str, collaborator: str) -> None:
self._owner(project, actor)
project.collaborators.add(collaborator)
self._save_and_audit(project, actor, "collaborator.shared")
def revoke(self, project: Project, actor: str, collaborator: str) -> None:
self._owner(project, actor)
if collaborator == project.owner:
raise ValueError("owner cannot be revoked")
project.collaborators.discard(collaborator)
self._save_and_audit(project, actor, "collaborator.revoked")
Key takeaways
Sharing is an explicit, revocable mapping among three independently authorised planes, not a copied URL or inherited role.
- Provider membership does not grant runtime or generated-application access.
- Revocation needs a negative probe and an unaffected positive control.
- Opaque references connect owners without transferring ownership.
Checklist
An access change is complete only when its scope and removal are observable.
- [ ] Grant names application, tenant, role, subject, grantor, and expiry
- [ ] Outsider denial and collaborator allowance are recorded
- [ ] Revocation invalidates future requests without disabling the owner
- [ ] Evidence contains actor, resource, scope, environment, time, run, and trace IDs