Encryption at rest protects storage media, not the application paths that legitimately decrypt data. If a compromised session, admin bug, or misconfigured API can reach plaintext, encryption has already been bypassed at the trust boundary that matters. Tenant-scoped key isolation is what prevents a storage leak from becoming a cross-tenant breach.
Why This Matters for Security Teams
Encryption at rest is often treated as a breach boundary, but cross-tenant SaaS incidents usually happen above the storage layer, where sessions, service accounts, and application logic can still reach decrypted data. That makes key management necessary but not sufficient. The real question is whether tenant isolation holds when a legitimate path is abused, not whether a disk, snapshot, or backup is encrypted.
NHI Management Group has repeatedly shown that credential and token abuse is a dominant breach path, including in cases like the Snowflake breach and the BeyondTrust API key breach. That pattern matters because SaaS tenants do not get separated by encryption alone; they are separated by authorization, key scope, and application control. Current guidance from the Anthropic AI-orchestrated cyber espionage report also underscores how quickly automated abuse can move once access is obtained.
In practice, many security teams discover cross-tenant exposure only after a trusted account, API path, or admin workflow has already been misused, rather than through any storage-layer failure.
How It Works in Practice
Encryption at rest protects data when storage media is lost, copied, or improperly disposed of. It does not stop an application, microservice, or support workflow from decrypting data after authentication succeeds. In a SaaS environment, the decryption boundary is usually the active trust path: request routing, tenant resolution, token validation, application authorization, and access to the KMS or envelope key. If one of those controls is flawed, encrypted data can still be served to the wrong tenant.
The practical defense is tenant-scoped isolation at every layer that can turn ciphertext back into plaintext. That usually means separate tenant context, strict object-level authorization, per-tenant key hierarchy, short-lived access tokens, and explicit checks before any decrypt operation. For a useful breach-pattern reference, see NHIMG’s 52 NHI Breaches Analysis and the Ultimate Guide to NHIs, both of which show how compromised non-human identities often become the path into otherwise well-protected systems.
- Use tenant-aware authorization before decryption, not after.
- Bind keys, tokens, and service credentials to a single tenant or workload scope.
- Rotate and revoke secrets quickly when a session or service account is suspicious.
- Log every decrypt event with tenant ID, principal, and request context.
- Test for broken object-level authorization, confused-deputy flows, and overbroad admin tooling.
Best practice is evolving toward continuous verification of who or what is asking to decrypt, with policy checks at request time rather than assuming storage encryption will absorb misuse. These controls tend to break down in multi-tenant platforms that share admin planes, cache decrypted records, or rely on broad service-to-service trust because the plaintext path is still reachable once one control fails.
Common Variations and Edge Cases
Tighter tenant isolation often increases operational overhead, requiring organisations to balance stronger blast-radius reduction against performance, cost, and administrative complexity. That tradeoff becomes more visible in high-throughput SaaS systems where shared services, customer support tooling, or analytics pipelines need broad read access.
There is no universal standard for this yet, but current guidance suggests treating any component that can decrypt customer data as part of the security boundary. That includes search indexes, message queues, caches, backups, and observability pipelines. If those systems can rehydrate plaintext, encryption at rest has already done its job and can no longer prevent misuse. In agentic or automated environments, the risk increases because non-human identities can chain calls faster than human operators can detect abnormal tenant switching.
Use cases with stronger isolation, such as dedicated per-tenant keys or even per-tenant encryption domains, reduce cross-tenant impact but are harder to operate at scale. Shared-key designs are simpler, but they raise the cost of a single auth failure. The 2024 ESG Report: Managing Non-Human Identities is a useful reminder that compromised non-human identities often lead to repeated incidents, which is exactly why decrypt-path hardening matters. For implementation detail, the Anthropic report reinforces how fast an abused identity can move once it has valid access.
These controls tend to break down in legacy SaaS architectures that centralise support access or reuse one privileged service account across many tenants because the decryption trust boundary becomes too broad to enforce cleanly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Per-tenant secrets and rotation are central to preventing cross-tenant decrypt abuse. |
| OWASP Agentic AI Top 10 | A2 | Autonomous abuse of trusted paths can bypass static access assumptions. |
| NIST AI RMF | Risk governance applies to systems that can expose plaintext through automated trust paths. |
Treat decrypt-capable components as high-risk assets and require continuous monitoring and human accountability.
