An agent tool layer nearly stored raw API keys inside Cosmos DB documents used for municipal workflows. What should the team do instead?
Select an answer to reveal the explanation.
Short Explanation
Cosmos is for civic data, not the key ring—park API secrets in Key Vault and let the agent tool layer fetch them there, not from document fields.
Full Explanation
Agent tool layers for municipal workflows must keep raw API keys out of Cosmos DB documents. Secrets should live in Azure Key Vault (or an equivalent secret store) and be retrieved by the tool layer at runtime with managed identity where possible. Cosmos holds civic operational data and tool metadata—not long-lived credentials in plain fields—so compromise of a document export does not automatically expose production keys.
Embedding production API keys as plain fields in every Cosmos DB tool document places secrets in the data plane and in backups, change feed, and support exports. Committing API keys into public GitHub gists linked from Cosmos items is an explicit leak. Printing keys on staff badges so containers can photograph them at runtime is not a secret-distribution control and fails basic hygiene.
Exam caveat: Key Vault references and managed identities are the expected Azure pattern; “store the secret next to the tool config in the database” is a common wrong answer. Operational check: scan Cosmos tool documents for high-entropy secret patterns, move any findings to Key Vault, grant the agent compute identity get/list permissions scoped to needed secrets, and verify tools retrieve secrets at runtime without embedding them in items.