Skip to content

PATTERN Cited by 1 source

Orchestrator-provider-agent trust triangle

Intent

Describe the three-role trust topology that makes the agent-provisioning protocol work. Not an algorithm — a role decomposition that agent-facing integrations across multiple platforms converge on when the design goal is to let agents provision resources at arbitrary external providers without human-in-the-loop signup / token-paste / payment-entry steps.

The three roles

         ┌────────────────────────┐
         │      Orchestrator      │
         │  ── holds signed-in    │
         │     user identity      │
         │  ── holds payment      │
         │     method             │
         │  ── attests identity   │
         │  ── issues payment     │
         │     tokens             │
         │  ── stores credentials │
         │     returned by        │
         │     providers          │
         │  ── enforces default   │
         │     spending caps      │
         └─┬──────────────────────┘
           │ attests identity     │
           │ + ships payment token│
           ▼                      │
  ┌────────────────┐             │
  │    Provider    │             │ exposes catalog +
  │ ── exposes a   │             │ provisions resources +
  │    machine-    │             │ returns credentials for
  │    readable    │             │ the agent to use
  │    service     │             │
  │    catalog     │             │
  │ ── provisions  │             │
  │    resources   │             │
  │    (account,   │             │
  │    subscrip-   │             │
  │    tion, etc.) │             │
  │ ── redeems     │             │
  │    payment     │             │
  │    tokens via  │             │
  │    orchestrator│             │
  └─┬──────────────┘             │
    │                             │
    │ resources + credentials     │
    ▼                             │
  ┌────────────────┐             │
  │     Agent      │◄────────────┘
  │ ── discovers   │ drives protocol end-to-end
  │    services    │ via the orchestrator CLI
  │ ── picks what  │
  │    to          │
  │    provision   │
  │ ── consumes    │
  │    returned    │
  │    credentials │
  └────────────────┘

Role definitions

Orchestrator

The party that already has the signed-in user and a payment method on file. Responsible for:

  • Identity attestation. Asserting to the provider that "this session is the user with email X, subject Y". Typically OIDC-grade: a signed claim the provider can verify.
  • Payment-token issuance. Shipping a payment token with each paid request; redeeming settlement on the provider's callback.
  • Spend-cap enforcement. Applying the default-on cap per provider; raising it only on explicit user action.
  • Credential custody. Storing the access tokens / API keys providers return, exposing them to the agent through the CLI rather than handing them over directly. Single revocation target when the user wants to retract agent access.
  • Catalog aggregation. Pulling per-provider catalogs into a unified surface the agent queries.

Stripe Projects is the canonical launch orchestrator. Cloudflare explicitly frames any platform-with-signed-in-users as an orchestrator candidate: "Your platform acts as the Orchestrator, with the already signed-in user."

Provider

The party that runs the resource / service the agent is provisioning. Responsible for:

  • Catalog publication. Exposing a machine-readable JSON feed of services the agent can provision (see concepts/provider-service-catalog-api). "A simple REST API that returns JSON."
  • On-demand account creation. Given an orchestrator- attested identity for a user with no existing provider account, auto-creating one (see concepts/agent-provisioned-account).
  • OAuth consent gate for existing accounts. Matching the attested identity to an existing account and driving the user through a standard OAuth flow for agent-scope grants.
  • Resource provisioning. Standing up the actual resource (domain, account, subscription, storage bucket, compute sandbox) and returning credentials.
  • Payment-token redemption. Calling the orchestrator's settlement API to charge against the token for paid services.

Cloudflare Registrar and Cloudflare Workers are the canonical launch-time providers.

Agent

The party the user is actually collaborating with in-session. Responsible for:

  • Discovery. Reading the orchestrator's aggregated catalog; choosing services to provision.
  • Provisioning commands. Issuing <orchestrator-cli> add <provider>/<service>:<resource> calls.
  • Consumption. Using the returned credentials (stored in the orchestrator CLI) to call provider APIs, deploy code, operate on provisioned resources.
  • Human-escalation on consent. Prompting the user when an OAuth consent or a payment-method entry is required.

Not coupled to a specific agent framework — any coding agent, IDE integration, or CLI-driven LLM loop can play the role.

What makes the topology symmetric

A platform can be both an orchestrator and a provider, on different integrations:

  • Cloudflare as provider in the 2026-04-30 Stripe Projects integration.
  • Cloudflare as orchestrator in the existing "create PlanetScale Postgres databases directly from Cloudflare" flow — "Cloudflare acts as the Orchestrator, letting you connect to your PlanetScale account, create databases, and use the user's existing payment method for billing." The partner-managed native binding pattern is the pre-formal- protocol shape of this orchestrator-side behaviour.

The symmetry is deliberate. Cloudflare's framing: the protocol "starts to standardize the types of cross-product integrations that many platforms have been doing for years, often in ways that were one off or bespoke to a particular platform."

Trust assumptions

For the triangle to close safely:

  • Orchestrator authenticates the user reliably. Session- hijack of the orchestrator compromises every participating provider. This raises the stakes on orchestrator MFA, anomaly detection, and session management.
  • Provider trusts orchestrator's attestation within a bilateral channel. Attestation is only as good as the out-of-band setup (API keys exchanged between orchestrator and provider, or a common JWT-signing CA). At launch these are bilateral contracts; a formal spec + trust anchor would broaden the ecosystem.
  • Agent is the least-privileged role. It holds no raw credentials — only the ability to invoke the orchestrator CLI. Compromise of the agent binary doesn't directly expose tokens if the CLI's credential store is process-isolated.
  • User consent is agent-scoped. OAuth consent grants agent-scope access; per-agent revocation + audit is expected (aligned with RFC 9728 framing).

What this topology is not

  • Not a two-party OAuth flow. OAuth is two-party (client
  • resource owner + authorization server, collapsed into user-driving-browser). Here the orchestrator is a fourth party that carries identity + payment across providers, not just a client.
  • Not a federation. Federation implies a common identity provider trusted transitively. Here each provider still owns its identity store; the orchestrator just provides attested claims that providers match (or auto-create against).
  • Not a payment-processor passthrough. The orchestrator does more than relay a charge — it enforces spend caps, curates the catalog, and retains credentials. A pure payment gateway would do none of those.

Seen in

Last updated · 433 distilled / 1,256 read