Concept
Delegated Operations And Estate Visibility
How the SCA gives provider staff central visibility and a delegated, appliance-enforced way to act on customer and tenant appliances without becoming a data path.
Overview
The SCA gives provider staff central visibility across enrolled appliances and a delegated way to act on them. It adds provider capabilities without replacing the customer or tenant SHA, which remains the hub for each deployment, and without becoming a data path.
This surface is available in both the MSP and CSP editions. Delegated staff operations and fleet visibility are not exclusive to CSP; where the deployment model allows, they apply to MSP-managed customer appliances too.
The appliance, not the SCA, is the enforcement point for every delegated action. This doc is the canonical home for the estate-visibility description; other provider docs defer here rather than restating it.
Estate Visibility
Provider staff see fleet telemetry aggregated from enrolled appliances. This section is the single canonical description of estate visibility for the whole area:
Delegated Operations
A delegated operation is requested at the SCA and enforced against the appliance's own grant policy; the default grant denies all writes. Operations run asynchronously and their status is polled — there are no webhooks.
Lifecycle of a delegated operation
At the SCA
Request
Provider staff request a delegated operation at the SCA against a specific tenant or customer appliance.
Recorded
Pending
The operation is recorded and queued. Supplying an idempotency key makes a retry safe — replaying the same key returns the original operation instead of dispatching a second one. A request that omits the key is recorded as a distinct operation and is not deduplicated.
To the appliance
Dispatched
The request is handed to the customer or tenant SHA, which grant-checks the action against its own policy before acting; the default policy denies all writes.
On the appliance
Running
The appliance performs the work. A sensitive action may first enter the appliance's local approval queue.
Terminal
Succeeded or Failed
The operation reaches a terminal outcome. The SCA polls for status and reconciles it back onto its record; there are no webhooks.
Approval And Step-Up
A sensitive operation enters an approval queue and requires step-up re-authentication scoped to both the action and the user before it proceeds.
Approval and step-up are enforced at the appliance — the customer or tenant SHA. The SCA records the operation and attributes an advisory grant note based on the appliance's last-known grant, then reconciles the appliance's decision back onto its own record.
Enforced at the appliance
Approval and step-up re-authentication run on the customer or tenant SHA, not on the SCA. The SCA observes, attributes an advisory note, and reconciles the outcome; it does not host the approval workflow or perform step-up.
Notifications And Audit
Delegated activity is made visible to the customer, and every action is recorded for later review:
- The appliance keeps its own notification and activity feed that surfaces provider-staff actions and approvals to the customer or tenant's local admin. This transparency-to-the-customer feed runs on the appliance, not on the SCA's own surface.
- Every delegated operation is recorded in an audit trail of the tenant, the acting user, and the request, so a delegated action is always attributable.
What It Is Not
- The SCA is not a data path; backup data never transits it. It carries telemetry, delegated requests, and read-through GETs only.
- The SCA does not host the approval workflow or mint the token that authorizes an action on an appliance. It observes, attributes, and reconciles while the appliance enforces.
- The SCA is not a replacement for the SHA. It adds provider capabilities on top of each customer or tenant SHA, which remains the hub and the enforcement point.
Related Docs