Three parties. One grant. One Service.

The vendor owns the Organization and operates its product. Each customer deployment is a separate Environment. The customer Approver is scoped only to that Environment and controls whether every request needs their approval or the vendor may approve under an express, audited delegation.

What is authorized

The outbound Agent registers only the Services the customer has authorized. A vendor operator requests access to one exact Service. An active grant permits thirp connect to expose a loopback port for the operator's tools. Expiry or revocation terminates the affected stream promptly. The audit records the control event without retaining application data.

Direction and authority

A vendor operator sends an access request. By default the customer Approver issues the grant. The customer may instead expressly delegate bounded approval to the vendor with audit. That grant permits the Managed Broker to connect the vendor CLI to the outbound Agent. The Agent dials out to the Broker and reaches only the named Service. The customer does not join the vendor network. Expiry or revocation ends the live stream.

In words...

  1. The vendor operator sends an access request.
  2. The customer Approver issues an active grant for one named Service, for a bounded window, unless they have expressly delegated that decision to the vendor with audit.
  3. That grant permits the Managed Broker to connect the vendor CLI to the outbound Agent.
  4. The Agent dials out to the Broker and reaches only the named Service. The customer does not join the vendor network.
  5. Expiry or revocation ends the live stream as well as blocking a new connection.

What this is not

A grant is not a machine, a subnet, or a customer network.

As a pilot, Thirp Cloud Broker is not implemented as high availability. A restart drops live streams; Agents will reconnect and re-register automatically for later connections. Session continuity, however, is not promised.

Request a pilot Forward this to a customer