IronCore developer docs

IronCore offers multiple products that work together to bring application-layer encryption, customer-managed keys, encrypted search, and end-to-end encryption to your application. Pick a product card below to jump straight into its docs, or scroll down for a side-by-side comparison and a short decision tree to help you choose.

SaaS Shield

Application-layer encryption with per-tenant customer-managed keys (BYOK / CMK) for multi-tenant SaaS apps.

See docs >

Cloaked AI

Encryption for vector embeddings, keeping nearest-neighbor similarity search working over encrypted data.

See docs >

Cloaked Search

A transparent proxy that adds encrypted full-text search to Elasticsearch or OpenSearch.

See docs >

Data Control Platform

End-to-end encryption SDKs with cryptographic access controls, sharing, and groups.

See docs >

IronCore Labs' products are built on innovative encryption technology, which we have patented.

Choose your IronCore product

This is the starting point for picking the right IronCore product, the right SDK within that product, and any add-ons your use case needs. Read the comparison table for orientation, work through the quick decisions if you want a yes/no path to a product, and check the use-case examples for a scenario that matches yours.

Compare at a glance

Quick decisions

The best fit for most IronCore customers is the SaaS Shield product family. It covers multi-tenant SaaS with customer-managed keys (the full SaaS Shield deployment of Alloy SDK + TSP + Configuration Broker), single-tenant apps that just need application-layer encryption (the same Alloy SDK in standalone mode), vector encryption for AI workloads (via Cloaked AI), encrypted full-text search (via Cloaked Search), and per-tenant S3 encryption (via the S3 Proxy). The main factor that would require you to leave the SaaS Shield family is true end-to-end encryption, which is what the last question covers. Work down the list in order; the first match points at the right variant or add-on.

1. Do you need per-tenant key separation? This can be either because your customers are asking to bring their own keys (BYOK/HYOK), or because you want to provide per-tenant keys yourself as the vendor to enforce separation of customer data.
   • Yes → use SaaS Shield with the Tenant Security Proxy and Configuration Broker. The TSP utilizes each tenant’s KMS to protect their data whether the tenant configures the KMS access or you provide it on their behalf as the vendor. Standalone Alloy does not give you per-tenant keys. Continue if you also have vector, encrypted-search, or per-tenant S3 requirements below.
2. Are you storing vector embeddings in a vector database and need nearest-neighbor search to keep working?
   • Yes → use Cloaked AI (the vector-encryption methods of the Alloy SDK). Pair it with the SaaS Shield TSP for per-tenant keys if multi-tenant; run Alloy standalone otherwise.
3. Do you need full-text search over sensitive fields stored in Elasticsearch or OpenSearch?
   • Yes → add Cloaked Search, either alongside SaaS Shield or standalone.
4. Are you encrypting objects in Amazon S3 with per-tenant keys?
   • Yes → add the S3 Proxy to SaaS Shield (not available for standalone mode).
5. Do you specifically need end-to-end encryption or to keep the server from being able to decrypt some data?
   • Yes → use the Data Control Platform.

Even if none of the specific cases above apply, the IronCore Alloy SDK is likely to satisfy your encryption needs. It can be paired with the Tenant Security Proxy and Configuration Broker (the full SaaS Shield deployment) for multi-tenant customer-managed keys, or used in standalone mode for single-tenant operator-controlled encryption.

Choosing the SDK within a product

SaaS Shield

SaaS Shield has three components. The Alloy SDK (or the legacy Tenant Security Client) runs in your application and never contacts the KMSes directly. Data stays in your application; only KMS key wrap/unwrap operations go to the Tenant Security Proxy (TSP) server, which runs in your infrastructure. The TSP is a Docker container you deploy that brokers every KMS operation whether it is directed to KMS(es) you provide or to a tenant’s KMS. KMS keys never leave their respective KMSes. The Configuration Broker is an IronCore-hosted web app where you provision tenants, and you and your tenants configure KMSes and configure logging / SIEM endpoints. The configuration data managed by the Configuration Broker is end-to-end encrypted so IronCore can’t view it. The Configuration Broker simply keeps all TSPs synchronized and up-to-date with the latest configurations. The Vendor API Bridge allows you to programmatically interact with the Configuration Broker. The Alloy SDK on its own (standalone mode) skips the TSP and Configuration Broker and uses operator-supplied secrets directly.

The IronCore Alloy SDK is the preferred SDK. Use it where your language is supported, and fall back to the legacy Tenant Security Client (TSC) only for languages Alloy does not yet cover.

There is no Alloy SDK for Go, Node, or PHP. Use the Tenant Security Client for those languages. There is no IronCore SDK for C# or Ruby today; contact us before building a wrapper of your own.

Cloaked AI

Cloaked AI is built on the same IronCore Alloy SDK as SaaS Shield, in the same four languages: Rust, Java, Kotlin, and Python. The vector-encryption operations are exposed alongside SaaS Shield’s more standard data encryption features through Alloy. There is no separate “Cloaked AI SDK” to install, just install Alloy and use its vector-encryption methods.

Cloaked Search

Cloaked Search is a transparent proxy in front of Elasticsearch or OpenSearch. No SDK is needed. Point your existing Elasticsearch or OpenSearch client at the Cloaked Search proxy URL and queries continue to work for supported query types and field configurations. See the Cloaked Search docs for the specific limitations (for example, range and comparison queries on protected numeric or date fields).

S3 Proxy (SaaS Shield CMK for Amazon S3)

The S3 Proxy adds per-tenant encryption to objects stored in Amazon S3 without changing application code. It deploys as a transparent proxy in front of S3 and is configured through SaaS Shield. There is no equivalent proxy for Google Cloud Storage, Azure Blob Storage, or other object stores. See the S3 Proxy overview for installation details.

Data Control Platform

The Data Control Platform is separate from SaaS Shield and therefore has different SDKs for browser, server, and native targets. Guide your choice by identifying where the encryption and decryption happens.

There is no DCP SDK for Go, Python, PHP, or .NET. Use IronWeb in the browser and IronNode for server-side Node; they are not interchangeable. There is no separate Kotlin SDK for Android beyond IronOxide Android.

Use-case examples

A multi-tenant SaaS app with per-tenant application-layer encryption

You are a SaaS vendor with customers who need some of their data protected at a higher level and resistant to hackers, to your employees peeking, from subpoenas, or for data sovereignty reasons. If you need to process this data on the server or make it available to any client without per-user keys, use SaaS Shield with the IronCore Alloy SDK and add other products as needed. If you don’t need or want to have access to keys that can unlock the data on the server, then use Data Control Platform for end-to-end encryption.

A multi-tenant SaaS app with customers who want to hold or control their own keys

You are a SaaS vendor and your enterprise customers want some of their data protected at a higher level and want to hold their keys in their own KMSes. Use SaaS Shield with the IronCore Alloy SDK in your application. If customers also store searchable PII in your search service, add Cloaked Search. The Data Control Platform does not integrate with KMSes and doesn’t apply here.

A multi-tenant SaaS app that would benefit from per-tenant key isolation, with the vendor providing the KMS

You want each tenant’s data encrypted under a different key for isolation, defense-in-depth, and a clear future path to tenant-managed BYOK, but your tenants are not yet asking to bring their own keys. As the vendor, provide KMS configurations yourself in the Configuration Broker and assign them to your tenants (one configuration assigned across many tenants, or per-tenant configurations you manage). Use SaaS Shield with the IronCore Alloy SDK, the Tenant Security Proxy, and the Configuration Broker. The same architecture lets each tenant take over their own KMS later by entering their own configurations in the Configuration Broker, with no application code changes. This rules out standalone Alloy because the upgrade path to tenant-managed BYOK requires the TSP and Configuration Broker, and it rules out DCP because your application server still reads tenant data.

A single-tenant app that needs application-layer encryption

You’re building a single-tenant product or internal tool that stores sensitive fields (PII, identifiers, free-form notes) in a database, and you want them encrypted at the application layer rather than relying solely on disk or column encryption. There is no second tenant who needs key control. Use the IronCore Alloy SDK in standalone mode with secrets you supply through your existing secret-management infrastructure, with no Tenant Security Proxy or Configuration Broker to deploy. The SDK supports standard, deterministic, and vector encryption in this mode, so you can grow into Cloaked AI or the full SaaS Shield deployment later without changing SDKs. This rules out the full SaaS Shield deployment because there are no per-tenant keys to broker, and DCP because your application server still needs to read the data on its own.

A multi-tenant SaaS app that stores user uploads in Amazon S3

Customers upload files into a shared S3 bucket and each customer expects its objects encrypted under its own keys. Use SaaS Shield with the IronCore Alloy SDK, and add the S3 Proxy so application code does not need to handle file-body encryption directly.

An LLM-backed assistant with private context

You are embedding sensitive customer data into vectors for retrieval-augmented generation (RAG), and plaintext embeddings should not sit in the vector database. Use Cloaked AI within the IronCore Alloy SDK. If the data is multi-tenant, layer Cloaked AI on top of SaaS Shield so each tenant’s vectors are encrypted using that tenant’s keys.

A peer-to-peer notes or to-do app where users hold their own keys

Each user encrypts data on their own device and grants access to other users without the server ever seeing plaintext. Use the Data Control Platform with the SDK matching the target: IronWeb in the browser, IronNode on the Node server, or one of the IronOxide SDKs (Rust, Java, Android, C++) for native targets. This rules out SaaS Shield, which is built for tenant-controlled keys where the server-side application decrypts on the user’s behalf. Here each end user needs to be the sole party that can decrypt their own data.

Still not sure?

Contact us and tell us:

• The languages and runtimes your application uses.
• Whether each end user needs to be the only party who can decrypt their own data (end-to-end encryption), or your application needs to read tenant data on a tenant’s behalf (customer-managed keys).
• Whether you have multi-tenant SaaS customers and any KMS or key-management requirements.
• Any specific compliance frameworks the deployment must satisfy (FIPS, FedRAMP, HIPAA, and similar; the right answer often depends on KMS choice and deployment topology, not the SDK).

For exploratory questions, Discord is a good place to start.