Customer-managed keys may be valuable when the objective is to control which services decrypt stored data. Changing the key owner alone is usually insufficient when the objective is to keep a running AI service from seeing its input. Define who must be excluded from which data, and when access must stop, before selecting an encryption layer. This analysis is for enterprise technology, security and procurement teams using conventional decrypt-then-compute systems. It describes design choices, not features promised by any particular product, and does not replace a deployment-specific compliance assessment.
Turn key ownership into an access requirement that can be tested
An AI request can create an original file, parsed text, a retrieval index, model input, generated output and operational records. These need not share a storage system or controlling party. Asking only whether the database is encrypted misses exported text. Asking only who holds the master key misses the service identity authorized to request decryption. Start procurement with a data-flow inventory: for every copy, record its location, encryption coverage, decrypting identity, recipients and disposal process.
Separate three objectives. The first is preventing an unauthorized holder of stolen storage media or backups from directly reading their contents. The second is allowing the enterprise to revoke subsequent decryption for a particular business domain independently. The third is ensuring that a particular operator or model processor never receives plaintext. These are different claims. The third especially requires examining where computation occurs and how input reaches the model; evidence for the first cannot establish it.
Google Cloud's CMEK documentation describes protection for data at rest in supported services, with encryption and decryption handled transparently by service agents.[1] A user lacking direct key permissions is therefore not necessarily unable to read the resource through an application. If the agent can decrypt and the application permits access, normal delivery can continue. Review business authorization and service identities alongside key control, rather than accepting a console screenshot as the entire proof.
Write a narrower, testable agreement: after disabling the specified contract-domain key, newly started reads that do not reuse decrypted caches must fail, while other domains continue working; after restoration, the specified data version must be readable again. Give old requests, in-memory plaintext and downloaded files separate treatment. This is more precise than claiming complete customer control of data and makes it possible for the supplier to submit evidence for the actual boundary.
Envelope encryption explains both control and its limits
Envelope encryption uses a data encryption key, or DEK, for the content and a key encryption key, or KEK, to wrap the DEK. The stored objects are ciphertext and a wrapped data key. Reading involves unwrapping before processing inside the computing environment.[2] The central key remaining inside a key-management service does not mean business data remains encrypted throughout processing. Mark the key-management boundary and the plaintext-processing boundary separately.
This yields two procurement questions. Can wrapped data keys and content always be matched to the correct key versions during migration and recovery? Where can the application write content after obtaining plaintext? Encryption of objects at rest, encryption in transit and use inside a process cover different stages. A mechanism at one stage does not automatically cover the others. These are engineering deductions, not a claim that every envelope-encryption implementation has identical weaknesses.
AWS KMS encryption context binds non-secret key-value information to ciphertext and can support authorization conditions. Its documentation warns that this information can appear in plaintext logs and must not contain sensitive data.[3] Consider controlled purpose codes or identifiers that reveal no business secret, and test that the wrong context cannot decrypt. Do not put customer names, contract clauses or original questions into that context under the mistaken impression that it is another encrypted store.
Key granularity determines the scope of failures and exit actions. One control point for every domain reduces administration but can interrupt several departments at once. Separating domains limits the affected scope while increasing policy, version, recovery and inventory work. Neither one key per user nor one inseparable boundary for customers needing independent exit is automatically appropriate. Define the smallest unit that must be independently disabled before estimating maintenance.
Three feasible paths require different organizational capabilities
Path one retains existing managed encryption and prioritizes identity permissions, the copy inventory and output controls. It fits teams whose confirmed problems are broad accounts, uncontrolled exports or missing data classification. This allocates resources to the observed exposure rather than abandoning security. Acceptance must establish denied unauthorized access, traceable records and working backup recovery. Deferring customer-managed keys does not excuse skipping checks on the supplier's encryption and operational access.
Path two adopts customer-managed keys in services that actually support them. It requires a coverage inventory, named key administrators and on-call responsibilities, recovery across environments, and knowledge of every dependent workflow. It fits a need for independent key lifecycle control or domain-level shutdown. The added control brings failure costs: a wrong policy, unavailable key or missing recovery dependency can prevent legitimate users from reading their data.
Path three encrypts and decrypts within a controlled application boundary, leaving external storage with ciphertext; whether model input is sent outside that boundary is a separate decision. This can better match a specific plaintext-isolation objective, but changes search, indexing, deduplication and troubleshooting. Decrypting inside the same external runtime before invoking a model does not keep plaintext from that runtime. Stronger isolation requires changing the trusted computing path, not renaming the solution.
Do not compare these paths using only the key-service bill. The first requires access and copy governance, the second adds policy and recovery operations, and the third can add application changes and lost functionality. If an external processor must never receive a particular kind of plaintext but a candidate service requires it, reduce the input or change the processing boundary. A customer-managed-key option does not resolve that conflict by itself.
Use a worked budget to identify what the added cost purchases
The following decision case is constructed. All amounts, hours and frequencies are assumptions, not vendor quotations, customer outcomes or incident forecasts. An enterprise has three data domains; only the contract domain requires independent disabling. It compares incremental spending over twelve months at an assumed fully loaded internal rate of CNY 300 per hour. Existing compute and access-governance costs common to all paths are excluded from the difference, but must still be budgeted separately.
Keeping the current arrangement while adding a contract inventory and access tests is assumed to need 40 initial hours and four maintenance hours per month. That is 40 + 4 × 12 = 88 hours, costing CNY 26,400. The customer-managed-key path assumes 80 initial hours, eight hours per month and an additional hypothetical service charge of CNY 1,000 per month. Its 176 hours cost CNY 52,800; adding CNY 12,000 produces CNY 64,800 for the year.
The application-isolation path assumes 240 initial hours, 16 monthly maintenance hours and CNY 2,000 per month in extra running costs. Its 432 hours cost CNY 129,600, plus CNY 24,000, totaling CNY 153,600. Against the first path, the second adds CNY 38,400 and the third adds CNY 127,200. This structure estimates expenditure; it does not establish an equivalent reduction in risk.
What does the difference buy? If independent shutdown of the contract domain is mandatory, the cheapest path does not meet that requirement. The second can qualify if its actual scope and recovery behavior pass the agreed tests. If the objective changes to preventing an external model ever receiving contract plaintext, the second budget no longer represents a sufficient solution. Reassess the third path and its functional feasibility instead of choosing the middle price.
Test sensitivity as well. If the second path needs 20 maintenance hours per month, its annual cost becomes 320 × CNY 300 + CNY 12,000 = CNY 108,000, which is CNY 43,200 above the original estimate. A controlled half-hour shutdown exercise, at an assumed business impact of CNY 6,000 per hour, adds another CNY 3,000. Keep that known exercise cost separate from unsupported annual incident probabilities; combining them does not create a credible security-return percentage.
Disable tests must cover cold reads, warm caches and recovery
In an isolated test scope, prepare two fictional documents protected by the contract-domain key and another domain's key. Record resources, versions, service identities and times. Both normal reads should succeed. Disable the contract key and start a path holding neither old plaintext nor an old plaintext data key: the contract read should fail as designed while the other remains available. Identify whether failure occurred at decryption, resource access or application authorization, rather than mistaking a network fault for successful isolation.
Then test the warm path. AWS Encryption SDK documents cached cryptographic material and limits based on age, message count and byte count.[4] That establishes one concrete caching mechanism, not a universal policy across cloud services. Ask the supplier what the deployed system caches, when entries expire and who controls them. A failed cold read cannot establish that previously decrypted information immediately becomes unusable.
If a warm cache still returns old content, compare that result with the actual promise: stopping new decryption differs from stopping content release at controlled outputs. The latter also needs invalidation, request termination and egress coordination. The existing analysis of RAG revocation consistency helps distinguish checks from output, but key disabling and user revocation remain separate controls. Identify already delivered content that cannot be recalled, and leave unbounded timing as an unpassed requirement.
Recovery is not complete when a key is enabled in a console. A fresh process must read the original version and check its content, then read a newly written version. Inspect accumulated work, duplicate tasks and any silent switch to a different key during the outage. Falling back to unprotected storage is not an availability improvement. Valid degraded operation stops affected processing, returns a clear state or uses a previously approved function that excludes restricted data.
Two counterexamples can change an apparently sensible choice
First, the dominant exposure may occur after decryption: an authorized analyst exports generated content to an uncontrolled destination. Added key ownership does not directly repair that exit. Establish the path through data flows, export evidence and controlled tests, not speculation about staff motives. Reduce input, constrain exports and recipients, and repeat the prohibited-output test. A key project may continue, but should not claim to have eliminated this separate risk.
Second, the organization may lack maintenance capacity. If one occasional administrator also owns recovery and has never rehearsed handover, control becomes an operational dependency on that person. Warning evidence includes incomplete dependency lists, old backups that fail after rotation and unreviewed access changes. Establish separated responsibilities and recovery evidence, or limit the deployment to a manageable domain. Universal availability promises are not credible without an operating arrangement.
Exit procedures must distinguish disabling from deletion. AWS describes key deletion as irreversible and potentially making data unrecoverable, suggesting disabling when uncertain.[5] On that basis, inventory ciphertext, backups and independent copies, establish retention responsibilities and then use an approved disposition process. A successful deletion operation proves neither that external plaintext copies disappeared nor that backups protected by other keys became unreadable.
Rotation also does not automatically establish that historical content has been re-encrypted. Ask which version protects new writes, which versions old ciphertext depends on, what recovery needs and how migration completeness is reconciled. If the objective is containing an existing exposure, changing future writes alone may be insufficient. Examine exposed data keys, plaintext copies and permissions, then define remediation for the actual scope.
Deliver an evidence card that supports proceed, narrow or defer
Include six concrete entries: protected objects and their copies; excluded parties and permitted service identities; encryption layer and plaintext location; independently disabled unit and affected workflows; cold, warm, in-flight and recovery tests; and annual incremental cost with continuing owners. Each entry needs an evidence location, check date, uncovered scope and responsible person. A product name or a bare supported/encrypted checkbox is not sufficient.
Proceed when the objective is explicit, coverage is traceable, disabling and restoration meet the written promise, and someone owns maintenance costs. Narrow the scope when only some services support the design or only one domain needs independent control. Defer when plaintext processing conflicts with the goal, recovery fails or dependencies remain unknown. These conditions support different decisions rather than prescribing one key-service tier to every enterprise.
Logs and alerts are data copies on this card. The enterprise AI log-redaction method helps determine which diagnostic evidence is necessary and which original text should not be copied again; key management does not replace collection minimization. State who controls keys, who may read business data and when new reads stop as separate claims. Attach real test evidence and unverified boundaries so that the investment can be independently assessed.