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.

Naming a device doesn’t give it any rights; naming is only for display purposes. Assigning roles to a device doesn’t give it any rights on their own either; the roles simply compile down to the grants of actions on specific resources.

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 management rights for 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.

Delegating access

Grant: any grant a device makes to another device may not exceed the rights, resources, history or lifetime of the grant that device received. Revoking that grant will revoke this grant. Earlier history is available on an opt-in basis. A grant that names a live screen, a question or an approval is refused unless its issuer is shown the text being shared, because a live screen can hold text printed before the grant existed. New recipients will not receive any historical attachment keys.

This grant is written without being activated. It will be activated when the invited-to device redeems the invitation. A pairing invitation shows its issuer the rights it proposes and no preview of the screen, and a session share made with kr share invite --live includes the live screen and shows its issuer the lines on it first.

By default, only “controller” and “owner” have the right to answer questions. A grant for a viewer or reviewer includes it only through an explicit option that explains the consequence. This allows the invited-to device to answer any kind of question, including entering free text. This text will be treated as any other input to the accepting agent, and the agent can perform any action on it that it has permission to perform.

Organisations and offline hosts

Single sign-on is done by the website’s account system. The website will recognise that you are a member of some organisation, but it will not decrypt the contents of your session or grant you authority on any host. The website signs a short lease (maximum 15 minutes) for your membership. The website always re-reads the membership record when signing a new lease, so if your membership is disabled in a directory, a new lease will not be issued.

A host takes part in an organisation only when its owner enrols it, which requires the owner to provide the chain of keys that the organisation uses to sign policies. A member exports the chain from the service, the owner gives it to the host, and an owner device confirms exactly that chain. The host pins these keys after the owner confirms them. The host never asks the service for the chain, a lease or the policy. When a member tries to access an enrolled host, their device shows the host a lease that the website signed. The host checks this lease against the keys it has pinned and the rotations it has followed. The owner applies the organisation’s signed policy to the host. The only setting in that policy that a host will act on is the adapter allowlist. A host enrolled in several organisations admits only the adapters that every list they state allows. Grants from personal owners don’t involve leases, so if the cloud goes down, personal grants will continue to work (with one exception that the owner can choose). If the owner decides that they want a host to be managed exclusively by organisations, even their own devices will need to present leases like any other member. When the last lease ends, access to that host ends, but the owner can still reach what recovers the host: an owner device confirms the end of exclusive management or, where none is left, the host’s own terminal does.

Organisation administrators with billing or membership management do not receive content keys as a result of their administration. An organisation can name a recovery recipient in its policy, but no host wraps an archive for it, so an organisation cannot decrypt a personal archive. Changes to membership and roles, directory credentials, identity bindings and groups, and policy revisions are written to an audit log that the service’s store refuses to change. Note that terminal output and prompt bodies are not recorded in the audit log.

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.