Identity, trust, and command authority
Cheetah carries a request from application code into a client-owned environment and accepts evidence through a second network path. No single login, connection, or permission check can establish everything that journey needs. The system keeps identity, transport trust, command authority, local control, and operator access separate so that each decision proves only what its owner can know.
Consider an application that asks a browser extension to read a signed-in page. The application knows why the data is needed and which account requested it. The browser knows which page is open, which permissions are active, and whether local policy permits the read. The returned data may enter through a different server process from the one that sent the command. An operator may later inspect the journey through a surface that is more privileged than either ordinary endpoint.
One relationship carries several identities
| Identity | Lifetime | What it is for |
|---|---|---|
| authenticated principal | user, or tenant plus user | isolates routing, history, correlation, and application access |
logical client_id | installation or deliberately stable client identity | addresses work across reconnects and runtime replacement |
runtime instance_id | one constructed running client | fences acknowledgement and returned evidence to the execution lifetime that received the attempt |
| command and message IDs | one application request and its returned records | join delivery, progress, terminal outcomes, history, and diagnostics |
| execution-context IDs | current platform resources such as tabs, windows, or console flows | target and coordinate resources that can disappear independently of the client |
A reconnect can preserve both the principal and logical client while changing the socket owner. A destroyed browser service worker constructs a new runtime instance. A page or console flow may vanish while both client identities remain valid. These distinctions let Cheetah preserve the identity that should survive and fence the lifetime that should not.
Identity is not inferred from convenient text. The WebSocket and returned-HTTP edges establish their principal through trusted host authentication. The body of a returned message can describe its client and runtime, but it cannot choose the user or tenant scope in which it will be stored.
Trust changes at several boundaries
| Boundary | Decision | What passing it does not prove |
|---|---|---|
| transport | the connection has the required external security posture | who the peer is or what it may do |
| WebSocket authentication | the connecting runtime belongs to an effective principal | permission for every advertised action |
| central authorization | this application invocation may be offered to the client | that the current device, page, or person permits execution |
| client-local authorization | this runtime permits the concrete invocation in its present environment | that an external side effect completed |
| returned-data authentication | the HTTP sender belongs to the principal whose scope will receive the evidence | that the payload is a successful terminal result |
| administrative authentication | an operator may inspect or control a broader surface | ordinary client or product authority |
Strict transport requires secure externally advertised WebSocket and HTTP endpoints. When a proxy terminates TLS, the host must provide trustworthy external-scheme information; Cheetah cannot infer the public boundary from an internal plaintext hop. Development transport is a deliberate mode selected at both ends, not a fallback.
The WebSocket and HTTP directions may terminate in different processes, but they must derive the same principal semantics. Otherwise routing, correlation, history, and isolation acquire incompatible answers to the most basic ownership question.
A command is judged before delivery and at execution
Application code may provide an ICentralPolicySource. Before presence is exposed and before the dispatcher receives work, the App role asks that source for a policy for the effective routing and command. No policy means that the central scope does not participate. A denial or an evaluation that cannot be completed safely stops the command at this boundary.
An allowed or approval-requiring central decision travels as a normalized snapshot on the command. The client does not receive the application's policy database. It receives the decision for this invocation so that its own authority can compose with it.
The shared client runtime then evaluates the concrete invocation against local policy. Payload references and supported encrypted envelopes are resolved before this decision, so local constraints can apply to the values intended for the handler rather than to opaque placeholders. With no local policy source, the current core default is open; products that need a restrictive device boundary must supply one explicitly.
The composed decision is monotonic: a later boundary can narrow permission but cannot turn an earlier deny into an allow. If the result requires approval, an IApprovalProvider decides the single invocation. Missing, denied, timed-out, canceled, or failed approval becomes a terminal command error. Approval does not rewrite the policy for the next command.
Capability, validation, permission, and completion differ
An advertised action says that a handler was registered when the runtime started. It helps an application choose a compatible client, but it is not permission. Argument validation says that the invocation has an accepted structure; it is not permission either. Central policy, local policy, and approval decide whether this invocation may proceed.
The client sends an ACK after it accepts a valid command frame into the dispatch path and before local policy and handler execution. A later refusal therefore returns as application evidence without rewriting the earlier delivery fact. Even an applied handler result proves only the action contract defined by that handler. External systems still need product idempotency and reconciliation when their effects matter.
Shared tenancy and operator access add separate scopes
Shared-tenancy composition derives a canonical tenant and user at trusted ingress and carries the effective principal through audited routing, history, correlation, notification, deduplication, and topology components. It validates known component behavior because satisfying an interface alone does not prove tenant isolation.
This data-plane scope is not a hosted control plane. Provisioning, application-database isolation, support access, billing, compliance deletion, and per-tenant infrastructure limits remain product and platform responsibilities.
Diagnostics and command-capable operator interfaces also sit outside ordinary client authority. A client credential should not reveal cross-user histories or permit administrative dispatch. Protect those surfaces with a separate administrative identity and network policy, and treat enabling control as a larger security boundary than mounting read-only observation.
Review one complete relationship
For each product action, name the principal, stable client, runtime lifetime, and target context. Then identify the transport and authentication decision on both network directions, the central and local authorities that participate, whether approval can actually be obtained, and the administrative surface that can observe the result. Test an allowed invocation and a denied invocation at the boundary that is expected to decide.
If one credential or component silently answers several of those questions, the design probably has an implicit trust boundary. Cheetah's model is useful precisely because the boundaries remain visible.
Continue to commands and returned evidence