Security, identity and user authority
A capability system that supports cautious defaults without making user-configured power impossible.
Identity hierarchy
Root user identity signs device identities. Torsion Node and each browser profile have separate keys. Project memberships and endpoint credentials delegate defined authority and can be revoked independently.
Authority is visible
Policy decisions include deny, ask, allow-once, operation, session, project, peer, endpoint and always-allow. A user may create an unrestricted owner profile; the software records and displays that decision rather than silently replacing it with a narrower policy.
Security invariants
- Participant model credentials and browser cookies remain local.
- Messages carry sender, recipient, operation, sequence, expiry, nonce and signature.
- Non-idempotent effects are never retried blindly.
- Remote diagnostics exclude prompt, response, credentials, files and full DOM by default.
- Extension-to-daemon pairing uses mutual proof and pinned identities.
- Incorporated code carries source revision, license decision and attribution.
Power and safety are not opposites. The product must make consequences observable, authority inspectable and recovery reliable while retaining the user’s ability to authorize broad automation.