Security model

The host authorises. Clients present state.

Every action is checked by the host against the session’s current state, not against what a client believes the state to be. A client renders what it was given and submits an intent. The worker then validates the scope of that action and the state it applies to, independently.

Two consequences carry most of this model: relay traffic creates no permission, and model output creates no permission. A relay forwards encrypted bytes: it cannot read your terminal, and admitting a connection grants nothing on your host. Text generated by a model, including text that looks exactly like an approval, is text.

Encryption protects content, not the fact of a connection. A service in the path can still observe addresses, which endpoints are talking, when, how often and how much. Discovery records are public by design. Treat that metadata as visible to whoever operates the path, and use a direct or self-hosted route where it matters.

Identity and keys

Machine groups, execution environments, network endpoints, devices and managed accounts are kept as separate identities. Each installed device creates independent keys for transport, authorisation signatures, stored-envelope encryption and notification previews. A private key is never converted or reused for a second purpose. Pairing binds those public keys and their declared purposes to one device record, through an authenticated exchange.

A device name is display text. It is never authority. Roles compile down to explicit action and resource grants, and the host never authorises from a role label on its own.

Owner confirmation

Some changes enlarge what is possible later, so they need a fresh confirmation on the owner’s machine, bound to that exact action digest, the destination keys and rights, the host, a nonce and a short expiry:

• issuing a persistent pairing invitation, or confirming a new device
• enlarging a persistent grant
• trusting a new repository root
• granting executable or native-bridge capabilities
• changing who may manage the host

An agent’s process label, operating-system peer credentials, terminal output and a freshly created invitation context are not that confirmation.

Local credentials prove an account, not intent

The command-line client authenticates through operating-system peer credentials. That proves which account the request came from. It does not prove that a person meant it. This is why rights-enlarging operations need the separate confirmation above: it reduces accidental persistence through KalaReach’s own interfaces.

Terminal input is account-level authority

Granting a device the right to send terminal input gives it the reach of the account the shell runs as. There is no smaller version of that: anything you could type, it can type. The same applies to text that reaches a shell indirectly, so a repository name, a file path or a label is never assembled into a command.

Answering an agent’s question carries the same weight. The answer is input the agent may act on under the permissions it already holds, and a form does not reduce that.

Sharing a session

Session invitations are single-use and expire. They default to view-only for one hour, and they can never grant rights the issuer does not hold. Earlier history is opt-in, not included by default. Sharing a live screen shows the issuer a preview of what is being shared, because a live screen can hold text printed before the invitation existed. New recipients do not automatically receive historical attachment keys.

Only the controller and owner roles include the right to answer a question by default. A viewer or reviewer can be given it through an explicit option that explains the consequence, because any answer, including free text, is input the receiving agent may act on under the permissions it already has.

Organisations and offline hosts

Single sign-on identifies a member. It does not decrypt session content and it does not establish authority over a host. A signed membership lease lasts at most fifteen minutes and is refreshed every five, so a disabled member loses new leases immediately and a cloud outage blocks organisation-mediated access once the last lease expires. Personal owner access on your own machine continues regardless, unless the host was deliberately enrolled as exclusively organisation-managed.

Administrators who manage billing or membership do not receive content keys as a consequence. Optional organisation recovery requires a named encryption recipient and visible enrolment. Grant changes, policy revisions and action metadata are written to an immutable audit log; terminal output and prompt bodies stay out of it.

Transport

Connections are authenticated and encrypted end to end between endpoints, over direct paths where they exist and through a relay where they do not. Signed discovery records are public by design and carry endpoint metadata, never session content; current direct addresses are exchanged through the protected pairing exchange and authenticated peer updates instead. Endpoint authentication and grants remain mandatory on every path.