Skip to lesson

MicrosoftMicrosoft Certified: Multi-Agent AI Solutions Expert2026-104.1 Design and implement security for multi-agent solutions

Rotate credentials without stranding encrypted data

Completed by the knowledge check

Learning objective

Design key rotation, secret versioning, and platform/customer-managed encryption controls.

Core idea

For an architect managing agent credentials and encrypted stores, rotation is a coordinated adoption process. Creating a replacement secret or encryption key is only one step. Consumers must adopt it, previous versions must remain available where required, and revocation must have an understood effect.

Separate authentication credentials from cryptographic keys. An API key stored as a Key Vault secret authenticates a caller to an external service. A customer-managed encryption key controls access to protected data at rest. Their lifecycles differ: revoking an API credential blocks calls that use it, while disabling encryption-key material can prevent access to retained data. See 4.1.5 for tool authentication and 4.1.6 for runtime retrieval roles.

How it works

Choose secret-version adoption deliberately

Key Vault identifies an object by vault, object type, name, and version. Creating another instance under the same name creates a distinct version. A versioned identifier selects one instance; an identifier without the version is a base identifier. These identifiers answer different operational questions: which value should the application use next, and which exact value did it use before?

In Python, SecretClient.get_secret(name, version=...) selects a version. Omitting version retrieves the latest version. A consumer pinned to a version does not adopt a replacement merely because someone created it. A consumer retrieving without a version can adopt the replacement on a subsequent retrieval, but your application still owns the timing of reads and cached-value refresh.

Choose version pinning when a controlled deployment must explicitly adopt a credential. Choose versionless retrieval when the application has a tested refresh policy and the provider supports the required transition. Record the consumed version identifier as operational evidence without recording the secret value. Neither strategy automatically updates a separate Foundry project connection that holds its own credential.

For a provider with two valid credential slots, rotate the unused credential, publish it as a replacement secret version, move consumers, verify their calls, and only then invalidate the previous credential. Microsoft’s dual-credential tutorial implements this pattern for Azure Storage account keys with Event Grid and an Azure Function. It does not establish that every SaaS provider supports two credentials or the same regeneration API.

In that Storage-specific pattern, Key Vault publishes a near-expiry event 30 days before the secret expires. The function regenerates the alternate account key and stores it as another version of the secret. The event subscription uses SecretNearExpiry, and the function receives Storage Account Key Operator Service Role for the storage-key operation. Prefer Entra authorization for Storage when the workload supports it; the pattern addresses workloads that still require account keys.

Configure cryptographic key rotation

Key Vault key rotation uses a per-key rotation policy. It creates another version with fresh key material. Key Vault Crypto Officer permits rotation-policy management and on-demand rotation. The consuming service’s permissions to use a key are a different responsibility from the operator’s permissions to rotate it.

The policy’s lifetimeActions define triggers and actions. An action with type: "Rotate" performs rotation; type: "Notify" supports near-expiry notification. Trigger fields include timeAfterCreate and timeBeforeExpiry, and attributes.expiryTime sets the expiration interval on subsequently rotated keys. The documented minimum rotation interval is seven days from creation and seven days from expiration time. Setting an expiry interval on the policy does not change the existing version’s expiry.

Use az keyvault key rotation-policy update to set the policy and az keyvault key rotate for on-demand rotation. These operations rotate a cryptographic Key Vault key, not an arbitrary external API credential stored as a secret. External credential regeneration still belongs to the issuing service and the automation coordinating it.

Keep the old cryptographic version available while dependent encrypted material still needs it. Microsoft’s rotation documentation describes data encryption keys being rewrapped rather than all underlying data being re-encrypted. Preserve versioned key references for decrypt or unwrap operations. Service adoption times vary, so do not choose a universal grace period or disable the previous version immediately after creating its replacement.

Map encryption controls to each store

Microsoft Foundry encrypts persisted data by default with Microsoft-managed keys. Customer-managed keys (CMKs) add control over eligible data-at-rest key lifecycle. They do not replace runtime authorization or make every connected resource inherit one encryption configuration. Foundry CMK encryption is available only in select regions because of Azure AI Search capacity constraints; check region support before committing to a CMK design.

The Foundry CMK coverage table distinguishes capabilities and resource configurations. Prompt agents require bring-your-own resources for CMK, with encryption configured separately on Azure Cosmos DB, Storage, and AI Search. Hosted agents have partial coverage with those resources: their persistent session $HOME is backed by platform-managed storage and does not support CMK or bring-your-own storage. Connected services such as Logic Apps and Functions also follow their own encryption configuration.

Therefore, a requirement that every persisted agent artifact use a customer-controlled key needs a store-by-store review. Selecting CMK on the Foundry resource alone does not satisfy that requirement for a hosted agent’s $HOME. Keep regulated material out of an uncovered store or choose a design whose persistence meets the requirement.

For Foundry resource CMK configuration, the documented key store is Azure Key Vault or Azure Managed HSM in the same Azure region as the Foundry resource, with soft delete and purge protection enabled. Use an RSA key of at least 2,048 bits. The configuration guide assigns Key Vault Crypto User to the resource’s managed identity for Key Vault access. Managed HSM uses its separate local RBAC and Managed HSM Crypto User.

The resource’s encryption.keySource is Microsoft.KeyVault, with key store and key name in keyVaultProperties. Omit keyVersion or set it to an empty string to let the resource adopt replacement key versions automatically. If you specify a version, update the resource configuration when rotating. This adoption setting is separate from the Key Vault policy that creates the replacement.

Key distinctions and trade-offs

Platform-managed versus customer-managed: Default encryption avoids customer ownership of key availability. CMK provides lifecycle control but makes key permissions, recovery, and retirement part of your operational design. Foundry documents that projects can move from Microsoft-managed keys to CMKs but cannot revert, and project CMK updates must remain within the same key store.

Rotation versus revocation: Rotation introduces replacement material. Revocation removes access. Revoking before adoption or rewrapping completes can create an outage rather than a successful rotation.

At-rest protection versus running inference: Foundry documents that revoking a fine-tuning CMK blocks operations requiring encrypted assets, but previously deployed fine-tuned models continue inference because artifacts were loaded at deployment. CMK revocation is not a universal runtime kill switch.

Architecture / decision scenario

A regulated assistant uses a partner API credential and a Foundry prompt agent with customer-owned persistence. A proposed hosted-agent extension also writes files to session storage.

For the partner credential, verify that the provider supports overlapping keys, publish a replacement Key Vault secret version, and move the adapter according to its version-pinning policy. Test the replacement before revoking the previous provider credential. Update any separately stored project connection as part of the same transition.

For encrypted persistence, configure each supported backing store’s CMK rather than assuming resource-level inheritance. Set a Key Vault rotation policy and choose automatic or pinned Foundry keyVersion adoption explicitly. Retain previous encryption-key versions until dependent data can be read with the replacement arrangement. Reject the proposed storage of regulated files in hosted session $HOME if customer-key coverage is mandatory. Document separately whether key revocation blocks stored-data operations or the running workload.

Common exam traps

  • Expecting secret version creation to regenerate the provider’s credential.
  • Confusing get_secret version pinning with automatic replacement adoption.
  • Applying Key Vault key rotation policy to every secret.
  • Disabling the previous encryption-key version before dependent data is safe.
  • Assuming Foundry CMK covers hosted session $HOME and connected services.
  • Treating CMK revocation as immediate termination of deployed model inference.

What to remember

Design replacement creation, consumer adoption, validation, and retirement as separate steps. Secret versions identify credential values; cryptographic versions remain necessary for protected data. Verify CMK coverage per capability and store, and distinguish encryption-key control from runtime access control.

Knowledge check

References