Counterparties and Egress
Every third party the platform can send data to, declared in one registry that is the egress inventory, the subprocessor list, and the only source of a credential, and the controls a workspace holds over it.
Every third party the platform sends data to is declared in one registry: the legal entity, the hosts traffic goes to, what leaves, whether it is retained, whether it trains, and which agreements cover it. The registry is the platform's egress inventory, its subprocessor list, and the only door through which a credential can be obtained. This chapter covers the model, the controls a workspace has over it, and how the sandbox side of egress completes the picture.
#Counterparties and Surfaces
A counterparty is a legal entity: the party to a Business Associate Agreement, the row on a subprocessor list. A surface is what code references: one credential, one set of egress hosts, one data flow. Many surfaces roll up to one counterparty; one cloud vendor is one agreement over several of its services.
Every surface declares:
| Field | What it says |
|---|---|
| Hosts | The exact hostnames traffic egresses to |
| Data classes | What leaves: URLs, identifiers, metadata, content, prompts, payment data, telemetry |
| Retention | Pass-through, stored, or covered by a zero-data-retention agreement |
| Training | Whether the vendor trains on what is sent |
| Exposure | core, reached by using the product at all, or elective, reached only by an action the user chose |
| Category | Model serving, search, scraping, payments, telemetry, and so on |
| Product scope | Which product's execution paths can reach it |
| Credentials | Where the operator's key lives, and whether a workspace may bring its own |
Every counterparty declares its legal name, country, and agreements: DPA, BAA, and their URLs. Retention and training are asserted from published terms, never guessed; a value the operator has not read is left unknown rather than filled in.
The registry lives in code, one file per counterparty, and a set of CI assertions keeps it whole: every model provider has a surface, every service the catalog can reach has a surface, every OAuth provider is covered, every third-party surface names at least one egress host, every adapter class declares the surface it egresses through, a retired counterparty holds no live bindings, and no code outside the registry reads a vendor key.
#What a Workspace Controls
The registry renders as the workspace's services page. For every elective surface, a workspace can:
- Disable it. A disabled surface refuses at the clearinghouse with a clear error before any request leaves. Disabling a provider disables every model it serves; a single model can be disabled on its own.
- Bring its own key. The workspace's key replaces the operator's for that surface, usage is billed as own-key events, and the adapter runs with the workspace's credential. A model can be kept on a workspace key while the rest of the provider is disabled.
Core surfaces cannot be disabled, because the product cannot function without them. The remedy for those is disclosure, which the registry provides.
#The Clearinghouse
One service answers whether a workspace may use a surface, and with which credential. Steps reach it through their execution context, the model factory reaches it when constructing an adapter, and routes reach it directly. The answer is a grant carrying a credential whose source is the operator or the workspace, or a refusal: the service is disabled by the workspace's choice, or no key is configured on either side. A model-level setting beats a service-level one. Disabled beats everything. A workspace key beats the operator's.
#Disclosure
Because every surface carries exposure, category, product scope, and agreements, the subprocessor list is a rendering of the registry: core infrastructure in one section, services used by features a customer enables in another, each with its data classes and its BAA coverage. The same records feed the model picker's data-boundary facts and the CAIQ attestation. See Compliance and Attestation.
#Sandbox Egress
The registry governs what the platform sends out. The other half of egress is what an app's own code may reach from its sandbox. That is decided by the network: a sandbox can reach the public internet and nothing internal. See The Trust Boundary. An app that calls a third party directly does so with its own secrets, from its own VM, and that traffic belongs to the app, not the platform.
Figure 20, "Counterparties and Egress": how a model call leaves, left to right. The reverse flow, and the point of the registry. A Remy app that wants to call a model or run an agent does not install a vendor SDK, and does not fetch a raw key to call the vendor itself (the app box carries the note "no vendor SDK, no raw key"). It asks the platform. Left to right along the spine: - Remy app: calls a model or runs an agent. - Public platform endpoint: the call arrives over the front door on an org-scoped hook token. - Clearinghouse (the heavy gate): may this workspace use this surface, and with which credential? It reads the counterparty registry, drawn beneath it, for the declared surface and its credential source, and returns a grant (from the operator or the workspace key) or a refusal (the surface is disabled, or no key is configured). - Meter and bill: the call is metered by user and model. - Then a dashed egress line leaves to the vendor host (for example OpenAI or Anthropic) under the resolved credential. The app has no edge to the vendor: it never holds the key or opens the connection. No trust boundary is drawn in this figure, so there is no crimson.