C. Store the service-account password in a dedicated secrets manager outside the prompt, and gate every delete action behind an explicit human-approval step that logs the approver identity and timestamp before execution.
Credentials must never appear in prompts. Prompt content can be logged by the application layer, cached by the API, echoed back in model outputs, or exposed through prompt-injection attacks—any of these paths would leak the password. A secrets manager keeps credentials entirely outside the conversation, injecting them only at the application layer when a specific, authorized action is about to execute. Separately, permanent deletion is a consequential and difficult-to-reverse action. Requiring an explicit human-approval step before each deletion—with the approver's identity and a timestamp recorded—creates the auditable, reversible-within-90-days trail the regulation demands. These two controls together satisfy both requirements. Hashing the password before embedding it in the system prompt does not protect the credential: the hash is still present in prompt logs and caches, and a hash of a known password can be used to verify guesses or, for weak passwords, reversed. The plaintext is also still needed by the database driver, so the application must store it somewhere anyway. Rotating the password daily reduces the window of exposure after a leak but does not prevent the leak itself. The password is still written into the prompt on every request and is therefore still exposed to every logging and caching pathway. Removing delete capability entirely eliminates the credential-in-prompt risk but also eliminates a legitimate operational function. The correct approach is to govern the capability with proper secrets handling and human approval, not to abandon it.