Cloud Development Environment Platform  ·  View 21 of 21  ·  Assurance

Identity Flow — A Token Into a Root-Owned Machine

Fourteen messages, of which the last two are the point.

Editable source SVG draw.io All views
Code in guest Guest agent Host agent Secret broker Control plane Git forge Audit log 1. git push 2. need repo token (vsock) 3. attach workspace identity 4. request, workspace-scoped 5. check repository binding 6. one repo, push scope 7. mint installation token 8. token, 15 min 9. issuance recorded 10. token, in memory only 11. push, through the proxy 12. accepted 13. direct request 14. replay from another workspace Identity Flow — Getting a Token Into a Root-Owned Machine The last two messages are the point of the view: the guest has no network path to the broker, and a leaked token is scoped to the workspace that asked for it. v 1.0 · owner Platform Architecture · date 2026-10

Decisions

  • Nothing long-lived is ever placed in a workspace. A token is minted on demand, scoped to one repository and one workspace, and expires in minutes (ADR-05).
  • The host agent attaches the workspace identity; the guest cannot assert who it is, which is what makes the scope trustworthy when the guest's user is root.
  • Every issuance is recorded in the audit log, so a leaked token has a known scope, a known owner and a known window.

Assumptions

  • Forge tokens live 15 minutes and carry push scope for a single repository binding.
  • Pushed content is scanned for credentials on the egress path, failing the push on a high-confidence match.

Risks

  • Short-lived tokens are still exfiltratable within their window; the mitigation is scope and audit, not secrecy, and the residual risk is accepted explicitly.
  • Proxying privileged operations instead of issuing tokens would shrink the blast radius further, at the cost of the platform sitting in the path of every authenticated call its users make — the alternative weighed and rejected in ADR-05.