Several Foundry agents retrieve third-party API keys and certificates at runtime. Today secrets are stored in a shared configuration map baked into container images, and rotation requires rebuilding every agent image. Which approach best meets secrets management requirements for multi-agent solutions on Azure?
Select an answer to reveal the explanation.
Short Explanation
You need to store secrets and certificates in Azure Key Vault, grant each agent identity least-privilege access, and automate rotation without rebuilding images. That's the Azure pattern for multi-agent secrets. Baking keys into images forces rebuilds and spreads copies, while email paste and Git branches are operational and security anti-patterns.
Full Explanation
Storing secrets and certificates in Azure Key Vault, granting each agent identity least-privilege access, and automating rotation without rebuilding images is correct. Multi-agent security skills specify Azure Key Vault for secrets, certificates, key rotation, RBAC to secrets, and encryption. Runtime retrieval by per-agent identities avoids baking secrets into images and enables rotation without redeploying code artifacts.
Keeping secrets in images but encrypting the Dockerfile with a home-grown cipher is incorrect because it does not provide centralized rotation, auditing, or proper secret lifecycle, and images still carry sensitive material.
Emailing new API keys to the on-call engineer for manual paste into production portals is incorrect because manual email distribution is error-prone, unauditable, and slow, and encourages secret sprawl.
Committing secrets to a private Git branch protected by a strong commit message convention is incorrect because source control is not a secrets manager; even private branches risk leakage through clones, forks, and CI logs.