Share and Revoke Without Leaking Authority
Let a customer share one generated application without confusing platform membership, runtime identity, and application access.
Whole-system design
5 stable layers. Today's work is expanded and linked; the rest stays in context.
Product and authority
People and product entry points
Lets an owner share a provider project with a collaborator and observe the resulting bounded access.
Identity and policy
Rejects authority beyond the explicit grant and preserves owner-only lifecycle operations.
HelixWorks control plane
Creates and revokes the collaborator grant while retaining the project as the authoritative scope.
Delivery and desired state
Cloud and orchestration
Compute and traffic
Storage and evidence
Evidence and observability
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