Customer-managed keys: what AI buyers should check

Evaluate customer-managed keys by tracing who can request decryption, which data the key covers and what happens after access is revoked. Ask for the supplier's key policy, service dependencies and recovery evidence. The ownership label alone leaves those operational questions open.

For an AI security platform, the protected material might include incident records, uploaded files or retained analysis. Each store can have different encryption and access paths. Start with the fields identified in your monitoring privacy review, then map their key dependencies.

Find the authority that permits decryption

AWS KMS documents key policies as the primary access-control mechanism. Permissions can involve a key policy, IAM policy or grant. A supplier's integration therefore needs an explanation of the principals and operations that its configuration allows.

For cross-account use, AWS requires both sides of the permission arrangement: the key owner's policy and the caller's IAM policy. Naming a supplier account can allow its administrators to delegate the granted permissions within that account.

Ask who can create grants, alter the policy or authorise a new service role. Record the account, region and environment for each principal. Separate routine service access from emergency support access, including who approves either route and where its use is recorded.

Define what revocation stops

KMS grants have eventual-consistency behaviour. AWS says a retired or revoked grant may remain usable briefly while the change propagates, sometimes for several minutes. A policy needs room for that interval and a way to observe its end.

There is a second boundary. Making a KMS key unusable causes new cryptographic operations using that key to fail. The effect on an already available data key is delayed until the service uses KMS again. A running service can therefore behave differently from a fresh process.

Ask for separate outcomes for new reads, ongoing processing, cached material and restored backups. A controlled pilot should state which operation must fail, how its failure is observed and what remains accessible. Agree those expectations with the supplier before any authorised exercise.

Treat rotation as its own procedure

KMS rotation changes current key material. AWS retains the material needed to decrypt older ciphertext. Rotation leaves the protected data and its data keys unchanged, so an access-removal plan needs its own authority changes.

This distinction helps avoid a procurement ambiguity. A supplier may offer scheduled rotation while retaining exactly the same service permissions. Ask for both procedures, their owners and their evidence: one for changing cryptographic material, another for withdrawing access.

Include a failure case in the runbook. If a service cannot use the new key version, identify its recovery route and the approval needed to restore operation. A broad fallback to another storage path can change the agreed data boundary.

Map encryption coverage through processing

Microsoft's Foundry guidance illustrates why coverage needs a service-level inventory. It distinguishes storage, connected services and runtime processing, where data is unwrapped for use. Its documented limitations also vary by feature.

Use that as a question for each shortlisted supplier: which databases, object stores, search indexes, caches, exports and backups depend on the customer key? Ask what protects the data while the service processes it and who can access it then.

Keep the answer beside your tenant-isolation evidence. Encryption, tenant separation and staff access are related controls with separate tests. Record any excluded store explicitly, including its retention period and access policy.

Preserve recovery and audit evidence

AWS key deletion is irreversible after its waiting period. Disabling a key offers a reversible alternative for appropriate authorised investigations. Never use destructive key deletion as an improvised procurement test.

The audit trail also needs both parties. AWS CloudTrail guidance says cross-account KMS operations are logged in the caller's and key owner's accounts, but access-denied requests are logged only in the caller's account. A customer may therefore need supplier evidence to establish a rejected call.

The acceptance pack should identify key ownership, permitted callers, covered stores, observed revocation behaviour and a reversible recovery procedure. Use synthetic records in an authorised pilot and retain operation outcomes without copying decrypted content into the evidence pack.

These are documentation-led buying criteria. We have not run a key-revocation exercise or assessed a vendor's private configuration. Any Promptective capability discussed during procurement should be established separately for the proposed deployment.

Discuss your AI security requirements with Promptective.