Hosted Plugins & Data Flow¶

Every hosted plugin endpoint is a trust boundary. This page states exactly what leaves a customer's network in each mode, and what must be true before a hosted endpoint should be approved.

The four operating modes¶

A plugin without a hosted endpoint runs in local mode. Installing it in a Horizon workspace creates a CLI-only record: the workspace tracks the version and permissions, scans stay local, and cs sync uploads the snapshot. No provider credential ever reaches CloudSlash.

What "hosted" means technically¶

A hosted release must satisfy all of the following before the worker will call it:

1. TLS gRPC endpoint — grpcs://host on port 443, no userinfo, no path or query. The registry stores one endpoint per release and the endpoint is bound into the release identity.
2. Pinned manifest digest — the exact version, capability set, connection methods, and endpoint hash to one sha256: digest. Changing any of them invalidates the approval.
3. Read-only capability contract — role: source, effect: read, and the hosted environment. effect: mutate and permissions.*.mutate are rejected by manifest validation.
4. Read-only connection method — every method carries "read_only": true; the operator approval catalog refuses a release without it.
5. Operator approval — the release must appear in the deployment-owned catalog (HORIZON_APPROVED_PLUGINS_FILE). Registry publication alone cannot approve a hosted release.
6. Scoped secret lease — the worker redeems a short-lived lease for the organization's connection and passes only that configuration to the plugin. The plugin never receives another organization's credentials.

The worker opens the endpoint, sends a v3 request bound to the job id, input digest, capability version, and plugin digest, and refuses responses that do not match. All of this is code-enforced; see the execution boundary.

Where the data actually goes¶

Publisher-hosted:
  provider APIs ──read──▶ plugin server (publisher) ──inventory──▶ Horizon worker ──▶ Postgres
  customer credentials ──────────────▶ plugin server (decrypted in memory, leased)

Customer runner:
  provider APIs ──read──▶ plugin runner (customer VPC) ──inventory over TLS──▶ Horizon
  credentials never leave the customer VPC

What the plugin can see in hosted mode: the connection configuration defined by its own method (prefer short-lived role credentials over long-lived keys), the read API responses, and the job metadata. What it must never see: another organization's lease, Horizon signing keys, or mutation permissions.

Is a per-plugin endpoint safe?¶

Only if the endpoint is treated as a publisher identity, not a URL. A different endpoint per plugin is normal; the risk is that the publisher's code holds the credential while it collects. Read-only IAM limits blast radius but does not prevent exfiltration. Therefore:

• For sensitive accounts, prefer customer runner (no credential leaves the VPC) or CloudSlash-hosted (one operator trust boundary, one approval path).
• For third-party publishers, require the checklist above, publish the source under an open license, and make the endpoint and publisher visible in the install dialog.
• Prefer short-lived credentials: role assumption with an external id and a session policy limited to the read actions rendered by cs permissions, rather than long-lived access keys.

Hosted status is per release¶

There is no global “hosted plugin” switch. Each release is approved or not:

• No endpoint → installable as a CLI-only workspace record.
• TLS endpoint + pinned digest + read-only method + operator approval → hosted scans and connections are enabled.

Customers choose the execution boundary when they add a connection; publishers choose what they can safely operate. See Run plugins for the deployment commands and Build a plugin for the source contract.