An organization stores Copilot agent memory in a cloud-hosted vector database to enable long-term context retrieval. A security audit finds that the vector embeddings and raw text chunks are stored unencrypted at rest, and the database is accessible using a single shared API key stored in a plain-text configuration file. Which two controls are most critical to implement immediately?
Select an answer to reveal the explanation.
Short Explanation
An unencrypted database with a plaintext shared key is like storing sensitive files in an unlocked cabinet with the key taped to the front. You need encryption at rest with customer-managed keys so stolen storage yields ciphertext, and you need per-service, short-lived credentials in a secrets manager so access is revocable, rotatable, and attributable. Those two controls cut two independent attack surfaces.
Full Explanation
The audit identified two distinct vulnerabilities that require independent mitigations. The correct control set is to enable encryption at rest for the vector database using customer-managed keys, and to replace the shared API key with per-service, short-lived credentials stored in a secrets manager.
Vulnerability 1: Unencrypted data at rest. Vector embeddings and raw text chunks may contain sensitive organizational content, such as code, internal discussions, and customer data. If the underlying storage is accessed by a threat actor, such as through a cloud storage breach, a rogue cloud provider employee, or a misconfigured bucket, plaintext data is immediately readable. Encryption at rest using AES-256, ideally with customer-managed keys in a key management service, ensures that even raw storage access yields unreadable ciphertext.
Vulnerability 2: Shared plaintext API key. A single shared key stored in a plaintext configuration file has several compounding problems: any process or person who can read the config file gets full database access; rotating the key requires updating every service simultaneously; and there is no per-service audit trail, so all access looks identical. Replacing this with per-service credentials from a secrets manager, such as GitHub Actions secrets, HashiCorp Vault, or AWS Secrets Manager, allows individual service revocation, rotation on schedule, and attribution in access logs.
The compression and pagination control addresses operational efficiency, not security. The TLS 1.3 and 256-character API key control improves transit security and credential entropy, but encryption in transit is already industry standard, and the audit found at-rest and access control gaps, not transit gaps; a 256-character key is better than a short one but still suffers all the problems of being shared and plaintext. The read-only access with human approval control addresses write authorization but doesn't encrypt the data or fix the credential problem.