# Deployment modes and data flows This guide describes where media and signing keys go in each Encypher deployment profile. It is a data-flow guide, not a security certification or a promise that a pending product is available. ## At a glance | Profile | Availability | Media payload sent to Encypher | Trust service | |---|---|---:|---| | Hosted | Available | Yes | Encypher hosted | | Local hashing, hosted trust | Available on Enterprise | No | Encypher hosted | | On-premises appliance | Coming soon | No production flow exists | Pending Seal 8.1 | C2PA hard binding and soft binding apply at the asset level. In the local-hashing path, the customer computes the binding digest and applies the returned carrier edit without sending the media payload to Encypher. ## Hosted Hosted mode sends the source asset to the Encypher media-signing service over TLS. The service builds and signs the C2PA manifest and returns the signed asset. ### What leaves the customer network - The complete source media asset. - The selected signing options and customer-supplied manifest metadata. - Authentication, request, and organization context required to authorize the operation. The 96 MiB local-hashing ceiling does not apply to hosted byte-mode signing. The hosted route's upload limits apply instead. ### Signing custody and key location - `hosted` is the default. The non-exportable production claim-signing key remains in Google Cloud KMS HSM. The customer application and browser never receive it. - `customer_kms` uses the organization's GCP KMS key reference after `org_kms` enrollment. Server-side use requires the deployment opt-in `ca_hosted_subscriber_signing_enabled`. The key remains in the organization's KMS. The shipped certificate path uses the organization's 366-day enrollment certificate. - `customer_external` is not signed server-side. A key held outside the supported hosted and organization-KMS paths cannot be selected through this deployment profile. ### Retention controls Organization retention policy, data mode, legal holds, exports, and controlled deletion are available under the `/api/v1/data` retention-controls router. These controls govern service records created by the hosted workflow. Review the active organization policy before sending an asset. ### Subprocessors The current list is published at [encypher.com/subprocessors](https://encypher.com/subprocessors). That live page is authoritative. This guide does not copy the vendor list because it can change independently of a deployment profile. ## Local hashing, hosted trust This profile keeps media processing on customer infrastructure while Encypher supplies the claim-signing trust service. The Encypher signing agent or an SDK extracts the permitted container structure, receives a binding recipe, hashes locally, finalizes the manifest remotely, and applies the returned carrier edit locally. ### What leaves the customer network Only the prepared-signing protocol fields leave the customer network: - Container structural bytes needed to plan the carrier, such as box, chunk, or segment headers, offset tables, and any existing C2PA manifest containers. Structural bytes can include EXIF or XMP metadata already present in those structures. - Signing options and customer-selected manifest metadata. - Cryptographic digests and the plan identifier used for finalize and manifest verification. - When a soft-binding provider is used, the allocation identifier, method identifier, nonce-bound attestation, provider key version, and binding digest. Media payload bytes, including image entropy data, `mdat`, and IDAT contents, do not go to Encypher. The client does not upload the full asset. Across prepare, finalize, and verify-manifest, cumulative HTTP request bytes for one asset have a 96 MiB on-wire ceiling. The 48 MiB prepare raw-body limit is parser headroom within that contract, not another 96 MiB allowance. ### Soft-binding boundary For hash-only execution, media bytes stay on the customer host. The same is true when a registered soft-binding provider uses a `protected_host` boundary: detection, hash-program execution, and attestation signing run together inside an HSM or TEE on that host. A provider using a `provider_hosted` attestation boundary is different. The watermarked media goes to that provider for detection and attestation. It does not go to Encypher. The provider returns a nonce-bound attestation over the binding digest, which Encypher verifies before finalizing the pre-planned manifest. SonicOrigin's production attestation boundary remains subject to the provider workshop and registration requirements. ### Signing custody and key location - `hosted` uses the Encypher hosted claim signer. Its non-exportable production claim-signing key remains in Google Cloud KMS HSM. - `customer_kms` uses the organization's enrolled GCP KMS key when `org_kms` enrollment is complete and `ca_hosted_subscriber_signing_enabled` is enabled. The claim-signing key remains in the organization's KMS. - `customer_external` is not signed server-side. - The local signing agent holds an organization API key in memory, but it holds no claim-signing key. - A soft-binding attestation key stays at its registered boundary: with Encypher for `encypher`, at the provider endpoint for `provider_hosted`, or inside the customer-host HSM or TEE for `protected_host`. ### Retention controls Prepared media plans expire after 1 hour. Terminal or expired plans are purged to tombstones after 24 hours, and tombstones are hard-deleted after 48 hours from the terminal or expiry point. Organization retention policy, legal holds, exports, and controlled deletion remain available through `/api/v1/data`. ### Subprocessors Use the current [subprocessor page](https://encypher.com/subprocessors) for the hosted trust service. Do not infer the provider's own processors from that list. A `provider_hosted` boundary sends media to the named soft-binding provider under the customer's separate provider terms. ## On-premises appliance The on-premises appliance is coming soon and is not available for production use. Availability depends on the pending Seal 8.1 release and its deployment review. There is no production appliance data flow to describe. Encypher has not published appliance egress limits, custody choices, retention behavior, subprocessor scope, or key locations. Those terms will be documented and reviewed before the profile becomes available. The pricing catalog therefore lists availability only and carries no appliance price. Customers that need media payload bytes to remain on their own systems today can use local hashing with hosted trust. Whether a soft-binding workflow also keeps the watermarked bytes on the customer host depends on the registered provider boundary described above. ## Control checklist Before production use, the customer and Encypher should record: 1. The chosen profile and signing custody. 2. Whether `customer_kms` enrollment and the hosted subscriber-signing opt-in are complete. 3. The permitted egress destination and, for soft binding, the provider attestation boundary. 4. The organization's active `/api/v1/data/retention-policy`, legal-hold requirements, and deletion process. 5. The current live subprocessor list and any separate provider terms.