Two architectural questions determine whether a privacy layer is safe to deploy in regulated environments. How does traffic get intercepted? And where does the engine actually run? Here’s how Presential answers both.
Presential intercepts traffic at the infrastructure layer. The integration is an Envoy sidecar injected alongside your application pod, or deployed as a standalone gateway for non-Kubernetes environments. A WASM filter inside the sidecar captures outbound traffic, calls the Presential RSP engine over a high-speed side channel, and swaps the original payload for a pseudonymised version before it reaches the external service. On the return path, the filter reverses the transformation before the response reaches your application.
The sidecar model has four properties that matter for enterprise deployment.
First, zero code changes. The filter sits in infrastructure you already run. In Kubernetes environments, injection is automatic. In ECS, the same engine runs as an ECS sidecar. For bare-metal or legacy deployments, a standalone gateway process handles the same function.
Second, enforcement is structural, not procedural. Because the filter operates at the network layer, developers cannot accidentally bypass it. There is no wrapper to forget and no SDK to import. If traffic leaves the pod, it passes through the filter.
Third, observability comes with the gateway infrastructure. The sidecar inherits your existing high availability, load balancing, distributed tracing, and metrics. Audit logging and detection telemetry do not require a separate control system.
Fourth, coverage is bidirectional. The sidecar sits on outbound and inbound paths. Inbound webhooks get the same transformation treatment as outbound API calls. Most proxy-based privacy models cannot do this.
The RSP engine runs inside your environment. The sidecar and the engine both deploy as containers inside your infrastructure: on-prem, in your VPC, or as sidecars in your cluster. All real-time PII processing happens locally. PII never crosses your perimeter.
The engine connects to a cloud-hosted control plane for configuration, policy updates, detection model distribution, and audit log aggregation. Only operational telemetry flows to the control plane: health metrics, detection statistics, anonymised performance data. The control plane never sees raw customer data.
This split gives you on-premises data residency without the operational burden of running a fully self-managed deployment. Agent updates, model improvements, and new policy configurations are distributed through the control plane. You choose whether those updates apply automatically or gate behind your own change management process. For environments where control plane connectivity is not permitted at all, a fully customer-managed deployment of the same engine is available.
The core RSP engine is independent of both the integration mechanism and the deployment topology. The sidecar is the primary integration; an SDK is available as a secondary option for patterns the sidecar cannot cover, such as batch export pipelines. The on-prem agent is the primary deployment; fully customer-managed deployment is available for regulatory environments that require it.
Every axis of customer variation is absorbed by a different architectural layer. Language variation disappears at the integration layer, because the sidecar is language-agnostic: a Python shop and a Go shop integrate the same way. Deployment variation is contained by the agent model, because the same container image ships to every customer regardless of cloud. Provider variation is handled by a plugin registry, so a new external service becomes a plugin contribution rather than a core engineering change. Data-type variation is managed through policy configuration pushed from the control plane.
The result is that the architecture is designed so the marginal cost of a new customer is measured in configuration, not engineering weeks.
Enterprise architecture teams evaluating Presential are making a single decision. Does this vendor ship infrastructure that plugs into ours, or does it ship a product that asks us to change ours? The sidecar model is the former. The control plane separation is the former. The plugin registry is the former.
A privacy layer that requires your developers to call it is procedural. A privacy layer that intercepts at the network boundary is structural. Enterprise procurement approves one of those and rejects the other.
Technical deep-dive sessions with the engineering team are available for serious evaluations. We’ll walk your architecture team through deployment options for your specific environment.