Specialist agents need database credentials and third-party API keys at runtime. Today secrets are environment variables baked at deploy time and rarely rotated. How should you design secrets management?
Select an answer to reveal the explanation.
Short Explanation
You should retrieve secrets at runtime from Azure Key Vault using the agent’s managed identity, enforce RBAC, and enable rotation. That keeps credentials out of Git, images, and prompts, and gives each agent just-in-time access to only what it needs.
Full Explanation
Correct answer: Retrieve secrets at runtime from Azure Key Vault using the agent’s managed identity, enforce RBAC, enable rotation, and avoid baking long-lived secrets into images or prompts.
Secrets management for multi-agent solutions uses Azure Key Vault for secrets and certificates, with rotation, RBAC, and encryption—retrieved via identity, not embedded in code or prompts.
Committing secrets to the agent Git repository in secrets.json is wrong: Secrets in Git are severe exposure and audit failure.
Putting API keys in system prompts so the model can “remember” them across sessions is wrong: Keys in prompts leak via logs, traces, and context exfiltration risks.
Sharing one Key Vault secret named “all-keys” as a single concatenated string for every agent is wrong: One shared blob prevents least-privilege secret access and clean rotation.
Exam tip: Key Vault + managed identity + RBAC + rotation; never prompt- or Git-embed secrets.