SaaS Shield
Multi-tenant key orchestration, BYOK/HYOK across any KMS, streaming audit trails, and crypto-agility. The platform underneath.
A practical guide for CISOs and security leaders: assume-breach architecture with application-layer encryption, customer-held keys, and AI data protection. OWASP, compliance, and defense-in-depth in one place.
Employees will misconfigure things. Unpatched vulnerabilities are a given. A first-level breach is impossible to completely defend against. Average time to exploit is now a week before a patch exists (M-Trends 2026). Average time to patch critical vulnerabilities is now 43 days following a patch being available, and the number of critical vulnerabilities has gone through the roof (Verizon DBIR 2026).
Taking steps to lower patch times may be worthwhile, but it's clearly insufficient. That's not a battle you can win in the current environment.
In practice, defense-in-depth is the only way to significantly reduce risk. The right questions to ask are, "when they get in, what can they do? What data can they take?"
This guide walks through how application-layer encryption, customer-held keys, and AI data protection allow you to survive an infrastructure breach without triggering customer notifications and legal fallout due to a data breach.
Snowflake, AT&T, Coinbase, Telemessage, MOVEit, and every other high-profile breach shares a pattern: the attacker found one credential, bug, or misconfiguration and walked out with huge amounts of sensitive data. The “encryption at rest” check box on AWS, Azure, and GCP did nothing because that only protects offline data, which means stolen hard drives. It’s important, but not a useful defense on a running server.
OWASP’s #4 risk is Cryptographic Failures:
Failures related to the lack of cryptography, insufficiently strong cryptography, leaking of cryptographic keys, and related errors.
The requirement for data-at-rest encryption is often interpreted to mean that data is sufficiently protected when transparent infrastructure-layer encryption is used.
But this is not enough. Application-layer encryption (ALE) is the needed complement to transparent encryption since it protects data in use. Even on compromised systems where the attacker has access to the data store.
With ALE, the application encrypts data before it reaches the database, the file store, or the search index. An SQL injection, an over-privileged service account, a compromised backup, or a curious admin sees ciphertext only. The attacker must compromise the application and the key management system to get plaintext. And keys are some of the best protected data in most infrastructures.
Snowflake and AT&T were preventable with ALE →
Breaches happen; data theft shouldn't →
One unchecked box, one billion records →
Application-layer encryption explained →
Once you encrypt at the application layer, a long list of risks collapses at once: a database admin can no longer browse customer data; a leaked read-replica or backup is useless; a subpoena to your cloud provider returns ciphertext; with per-tenant keys, an injection attack can't exfiltrate across tenants. Multi-tenant SaaS gets the trust posture of single-tenant on-prem deployments without the cost.
The attacker needs to gain access to the key and the data or the already decrypted data. Push it one step further with customer-held keys (HYOK) and you remove yourself and your employees from the trust boundary entirely, making an attacker's job exponentially more difficult.
Using ALE to restrict insider access →
Avoiding compelled access with encryption →
How SaaS handles sensitive data →
AI needs data; not just for training, but at inference time. Without auxiliary data, models are more prone to hallucinate. With supporting data, a model can cite its source. So we jam context like the contents of web pages or documents into prompts invisibly as part of interactions with AI. This is done in a process called RAG (Retrival-Augmented Generation), and it’s the path that introduces private data (company documents, our emails, calendar, SaaS data, etc.) into AI interactions.
Vector embeddings underpin much of the AI search and generation process. These embeddings are mathematical representations of data that can be used by AI, and especially RAG workflows, to find information relevant to a particular query. The vectors are typically generated by purpose-built AI models called embedding models, and they are typically stored in vector databases or vector-capable databases.
Vector database advocates have claimed that these vectors are unimportant from a security or privacy perspective, because they distill the information from the source data in a one-way process (like a hash). This is dead wrong.
Vector embeddings used in RAG and semantic search are not irreversible. They can be inverted back to near-perfect approximations of the original text, faces, or images. Every vector in your architecture is, effectively, another copy of your private data with weaker access controls, lowered visibility, and almost no protection.
IronCore’s Cloaked AI is the practical answer: encrypt vectors, keep them searchable, and stop creating unprotected shadow copies of your sensitive data.
RAG security risks explained →
There and back again: an embedding attack journey →
Talking to the business about AI risk →

Application-layer encryption is the rare control that simplifies many compliance conversations at once. PCI DSS v4 now mandates it for stored cardholder data. GDPR, Schrems II, and the Trans-Atlantic Data Privacy Framework all treat customer-controlled keys as a sufficient technical safeguard for cross-border data. HIPAA, FERPA, ITAR, GLBA, and SOX all reward you for it. If you operate within the purview of more than one regime, ALE can be the most leveraged control on your roadmap.
PCI v4 now mandates application-layer encryption →
Forbes: encryption in a Schrems II world →
Schrems II technical measures →
The single most important question in any encryption review is, "who can decrypt this, and what do they need?" Most ALE projects fail because key management gets bolted on afterward. IronCore's platform handles per-tenant keys, BYOK, and HYOK across any KMS. Difficult details like rotation, revocation, and crypto-agility (including post-quantum migration), are all handled.
A revoked key makes the customer's data unreadable everywhere it lives, immediately. No need to edit old backups or for certificate-of-destruction theater.
BYOK explainer →
HYOK / Hold Your Own Key →
Customer-managed keys →
Crypto-agility and post-quantum explained →
Key management is hard, especially when customers want it →
Engineering teams routinely underestimate the cost of building application-layer encryption in-house. Anyone can call an encryption algorithm, but designing a secure, performant, scalable system that handles the many edge cases is hard. Per-tenant key isolation, encrypted search, BYOK/HYOK across multiple KMSes, audit trails, performance tuning, key rotation, revocation, crypto-agility for post-quantum, and the SDK work to make all of it usable across services are all projects on their own. Get the architecture wrong and you'll be mired in maintenance hell.
IronCore has been doing this for a decade. The SDKs are open source and audited, the algorithms are documented, and the product is SOC 2 Type 2 certified.
Should you build your own ALE? →
Should you use MySQL's encryption? →
A checklist to quickly evaluate SaaS security →
Named a Cool Vendor in Data Security for vector encryption and AI data protection. Also cited in Gartner's quantum cryptography research.
Read the announcement →Original research on attacks against GenAI data and shadow data in fine-tuned models, with practical defenses.
DEF CON 32: Vector encryption →Hidden risks of integrating AI: how embedding inversion and shadow data turn AI features into data-exfil paths.
OWASP Global 2025 talk →CEO Patrick Walsh contributes regularly on AI privacy, post-quantum, and data sovereignty.
Forbes: AI vector DB privacy risks →Annually re-certified for SOC 2 Type 2, regular pen-tests, with code-audited open source SDKs and an active bug bounty program.
Trust Center →Building application-layer encryption since 2015. Used in production by household-name SaaS companies, including HubSpot, Zendesk, and Norwegian Cruise Line Holdings.
Our vision →Multi-tenant key orchestration, BYOK/HYOK across any KMS, streaming audit trails, and crypto-agility. The platform underneath.
Encrypt vector embeddings while preserving nearest-neighbor search and metadata filters. Removes the AI shadow-data risk.
Search encrypted fields in Elasticsearch or OpenSearch. Search keeps working; the search service never sees plaintext.
Patented re-encryption tech for cryptographic access control, true E2EE, and zero-trust sharing across organizations.
IronCore works with security leaders to map out where ALE belongs in your stack and what a rollout looks like. Conversations are technical rather than sales-y.