Understand the protection. Plan your integration.

Architecture

How InvisiCloud works

Data processing and key control are separated, enabling joint computation without giving any single component access to plaintext. Authorized applications can access data as usual.

Your AppYour Application

Existing S3 client

InvisiCloud

Payload Gateway

utilacy or partner

Encrypted TLS payload

Encrypted
SMPCEncrypted SMPC Computation

No plaintext
No single-party control

Key Gateway

You or partner

TLS encryption keys

Your Storage

S3-compatible service

Encrypted PayloadEncryption KeysTrust boundary

Encrypted SMPC Computation

Executes application logic on encrypted data, such as seamless TLS termination and encryption at rest, without exposing plaintext within the middleware or giving any party sole control.

Select a component for details.

Built on Secure Multi-Party Computation (SMPC) and our patented TLShare.

Security & Control

Who can access what?

Protected content

Sensitive information remains cryptographically protected across storage, transfer and middleware processing.

Payload Gateway

Encrypted TLS payloads, without the corresponding TLS encryption keys.

Key Gateway

TLS encryption keys, without the corresponding payloads.

Distributed control

Data processing and key control are distributed across independent components, so neither can access plaintext on its own.

Authorized access

Authorized users and applications access plaintext through existing workflows and access controls.

Security boundaries

Metadata may remain visible. Confidentiality depends on separate control of the Payload Gateway and Key Gateway.

Integration & Deployment

Fits your existing setup

Choose your deployment

Decide who operates the Payload Gateway and Key Gateway: you, utilacy, or a trusted partner. Deploy using provided containers or choose a managed setup.

Component operation

Payload Gateway Key Gateway

You · utilacy · trusted partner

Independent control of the gateways
Connect your storage

Configure InvisiCloud to use your existing storage services just like a regular client.

S3-compatible interface

InvisiCloud Your Storage
Connect your application

Point your application to InvisiCloud directly or via DNS. Your existing storage workflow remains in place.

Application connection

Your Application InvisiCloud

TLS handshake ↔ Key Gateway

Encrypted TLS payload → Payload Gateway

Compare approaches

Different approaches. Different trade-offs.

Common security architectures prioritize confidentiality, compatibility, and control differently.

Advantage Trade-off Higher effort or limitation

Expand an approach to compare architecture, operating responsibilities and trust boundaries.

Approach	Confidentiality	Trust & control	Compatibility	Setup complexity	Operational overhead
	Trade-off: Provider may access plaintext	Higher effort or limitation: Trust concentrated in provider	Advantage: Native integration	Advantage: Low	Advantage: Low
Server-side encryption: architecture & trade-offs The provider encrypts data for storage and decrypts it for authorized requests. Encryption at rest preserves native backend functionality, while plaintext remains accessible within the processing infrastructure. Server-side encryption Application Plaintext Provider infrastructure Plaintext processing & encryption Storage Encrypted at rest Boxes indicate processing stages; notes show where plaintext or keys are accessible. InvisiCloud · target architecture Application Authorized plaintext access Two independently controlled trust boundaries Payload Gateway Encrypted payloads ↔ SMPC Key Gateway TLS keys Neither gateway alone can reconstruct plaintext. Storage Encrypted content Architecture comparison InvisiCloud separates encrypted payload processing from key control across independently controlled gateways, instead of concentrating access in the provider infrastructure. Setup & operations Setup and ongoing operations typically follow the storage service’s native configuration. Customer-managed keys can add policy, rotation and recovery responsibilities. Assumptions & limits At-rest protection does not by itself prevent plaintext access during processing. Access boundaries depend on the service and its key-management configuration.
	Advantage: Encrypted before upload	Trade-off: Clients hold plaintext & keys	Higher effort or limitation: Client changes required	Higher effort or limitation: Per-application integration	Higher effort or limitation: Client & key lifecycle
Client-side encryption: architecture & trade-offs Applications encrypt content before uploading it and decrypt it after retrieval. Storage infrastructure receives encrypted content, while clients handle plaintext and the keys needed to recover it. Client-side encryption Client / application Plaintext, keys & encryption Transfer Encrypted content Storage Encrypted content Boxes indicate processing stages; notes show where plaintext or keys are accessible. InvisiCloud · target architecture Application Authorized plaintext access Two independently controlled trust boundaries Payload Gateway Encrypted payloads ↔ SMPC Key Gateway TLS keys Neither gateway alone can reconstruct plaintext. Storage Encrypted content Architecture comparison InvisiCloud moves cryptographic coordination into the gateway layer. Its target architecture preserves existing application workflows without integrating encryption into each client. Setup & operations Encryption integration, key distribution, rotation and recovery must be coordinated across participating applications and clients. Client updates and access changes add lifecycle work compared with central gateway management. Assumptions & limits Client security remains essential. Backend functions that require plaintext may be limited or require a different design; performance depends on the client implementation and workload.
	Trade-off: Gateway sees plaintext	Higher effort or limitation: Trust concentrated in gateway	Advantage: Supported apps unchanged	Trade-off: Gateway integration	Trade-off: Gateway & key lifecycle
Encryption gateways: architecture & trade-offs A gateway encrypts and decrypts content between applications and storage. Supported interfaces allow applications to keep their existing workflows, but the gateway becomes a trusted plaintext intermediary. Encryption gateways Application Plaintext Encryption gateway Plaintext & key access Storage Encrypted content Boxes indicate processing stages; notes show where plaintext or keys are accessible. InvisiCloud · target architecture Application Authorized plaintext access Two independently controlled trust boundaries Payload Gateway Encrypted payloads ↔ SMPC Key Gateway TLS keys Neither gateway alone can reconstruct plaintext. Storage Encrypted content Architecture comparison InvisiCloud splits this intermediary into a Payload Gateway and a Key Gateway. Neither gateway independently has the payload and key access needed to reconstruct plaintext. Setup & operations Routing, gateway deployment and key integration are configured centrally. Ongoing work includes updates, monitoring, scaling and key recovery; the gateway adds a dependency and processing latency. Assumptions & limits Compatibility depends on the implemented interfaces and backend functions. A compromise of a conventional gateway can expose plaintext available to that gateway.
	Advantage: Protected inside enclave	Trade-off: Hardware & attestation trust	Trade-off: Workload adaptations	Higher effort or limitation: Enclave integration	Higher effort or limitation: Specialized platform lifecycle
Confidential computing: architecture & trade-offs Sensitive processing runs inside a hardware-protected execution environment. Plaintext exists within that boundary; attestation helps verify the environment before secrets are released. Confidential computing Application Protected connection to workload Trusted execution environment Plaintext inside hardware boundary Storage Encrypted output when configured Boxes indicate processing stages; notes show where plaintext or keys are accessible. InvisiCloud · target architecture Application Authorized plaintext access Two independently controlled trust boundaries Payload Gateway Encrypted payloads ↔ SMPC Key Gateway TLS keys Neither gateway alone can reconstruct plaintext. Storage Encrypted content Architecture comparison InvisiCloud uses joint cryptographic processing across separate gateways rather than relying on a hardware enclave to isolate plaintext from individual infrastructure operators. Setup & operations Deployment can require workload adaptation, attestation policies and secret provisioning. Hardware availability, platform updates and workload lifecycle become operational dependencies. Assumptions & limits Protection depends on the hardware, enclave code and attestation model. Integration effort and performance vary by platform and workload; storage and transport protection must also be addressed.
	Advantage: Neither gateway alone can access plaintext	Advantage: Control split across independent operators	Advantage: Existing applications & storage workflows unchanged	Trade-off: Gateway deployment & routing	Trade-off: Two gateways & key lifecycle
InvisiCloud: architecture & trade-offs The Payload Gateway handles encrypted TLS payloads, while the Key Gateway handles the corresponding TLS keys. They jointly process data using SMPC, without either gateway independently reconstructing plaintext. InvisiCloud Application Authorized plaintext access Independent gateways Separated payload & key control Storage Encrypted content Boxes indicate processing stages; notes show where plaintext or keys are accessible. InvisiCloud · target architecture Application Authorized plaintext access Two independently controlled trust boundaries Payload Gateway Encrypted payloads ↔ SMPC Key Gateway TLS keys Neither gateway alone can reconstruct plaintext. Storage Encrypted content Architecture comparison The product vision combines application compatibility with distributed control, extending from storage to additional infrastructure protocols and encrypted application processing. Setup & operations Setup includes gateway ownership, routing and storage integration. Operations cover both gateways, monitoring, updates, scaling and key recovery. Managed deployment can reduce customer effort; joint processing and network placement affect latency and throughput. Assumptions & limits The confidentiality model requires independent control of the gateways. Authorized endpoints still access plaintext and metadata may remain visible. Compatibility targets the planned interfaces and functions; both gateway roles introduce availability dependencies.

Ratings describe typical architectures; effort and protection depend on deployment. InvisiCloud reflects the target architecture and planned capabilities. See Technical Evaluation for current availability.

Technical Evaluation

Evaluate InvisiCloud for your environment

Validate the key requirements for your workload and infrastructure.

Understand → Evaluate → Test

Ready to evaluate your workload?

Verify your required interfaces, setup, security requirements and performance targets.

Explore the S3 Beta

Discuss your architecture

Technical FAQ

Your technical questions, answered.

Have a question about your workload? Contact us

Understand the protection. Plan your integration.

How InvisiCloud works

Your AppYour Application

InvisiCloud

Payload Gateway

EncryptedSMPCEncrypted SMPC Computation

Key Gateway

Your Storage

Encrypted SMPC Computation

Who can access what?

Protected content

Payload Gateway

Key Gateway

Distributed control

Authorized access

Security boundaries

Fits your existing setup

Choose your deployment

Connect your storage

Connect your application

Different approaches. Different trade-offs.

Server-side encryption: architecture & trade-offs

Server-side encryption

InvisiCloud · target architecture

Architecture comparison

Setup & operations

Assumptions & limits

Client-side encryption: architecture & trade-offs

Client-side encryption

InvisiCloud · target architecture

Architecture comparison

Setup & operations

Assumptions & limits

Encryption gateways: architecture & trade-offs

Encryption gateways

InvisiCloud · target architecture

Architecture comparison

Setup & operations

Assumptions & limits

Confidential computing: architecture & trade-offs

Confidential computing

InvisiCloud · target architecture

Architecture comparison

Setup & operations

Assumptions & limits

InvisiCloud: architecture & trade-offs

InvisiCloud

InvisiCloud · target architecture

Architecture comparison

Setup & operations

Assumptions & limits

Evaluate InvisiCloud for your environment

1CompatibilityInterfaces, applications, authentication and backend services.

2Security & trustConfidentiality requirements, trust assumptions and security boundaries.

3Deployment & operationsComponent ownership, hosting, monitoring, updates and key recovery.

4Performance & scalabilityLatency, throughput, concurrency and scaling requirements.

5Availability & resilienceDependencies, failure behavior, redundancy and recovery.

Ready to evaluate your workload?

Your technical questions, answered.

What can each InvisiCloud component access?

What are the trust assumptions and security boundaries?

How are encryption keys managed and controlled?

What changes are required in our existing infrastructure?

What happens if a component becomes unavailable?

What performance impact should we expect?

What are the current technical limitations?

Encrypted
SMPCEncrypted SMPC Computation