A housing CRM team wants GenAI letter drafting for caseworkers without embedding foundation-model credentials in the CRM user interface. Which architecture best supports that goal?

Adding GenAI letter drafting to a housing CRM is best done by exposing drafting through an internal microservice behind API Gateway so the CRM calls a GenAI API without holding foundation-model credentials in the UI. Caseworkers keep working in the familiar CRM; the backend service owns IAM credentials and invokes Bedrock under server-side controls, logging, and Guardrails. That architecture prevents browser bundles from becoming secret stores and keeps FM access attributable to a service role. Hard-coding Bedrock access keys in the CRM browser JavaScript bundle fails secret management: anything shipped to the browser can be extracted, reused, and attributed poorly. Emailing case notes to a shared inbox that a volunteer pastes into a public chatbot fails confidentiality, audit, and automation for housing case data. Granting every caseworker console access to Amazon Bedrock in the production account fails least privilege and creates unmanaged interactive use outside the CRM workflow and its logging. Exam caveat: the microservice must enforce tenant and case-level authorization—do not assume CRM UI checks alone protect the drafting API. Also version prompts and templates so letter tone stays consistent with housing policy. Prefer short-lived credentials via roles, not long-lived keys on disk. Operational check: Confirm the CRM calls only the internal drafting API; verify the service role can invoke required Bedrock actions and nothing more; ensure browser traffic contains no FM secrets; log draft requests with case IDs for audit; and spot-check letters for PII handling before wide caseworker rollout.