A city mobile 311 app needs foundation-model answers but must not hold long-lived Bedrock credentials on residents’ phones. Which FM API integration pattern is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
Phones are leaky pockets—never stash the city’s Bedrock keys there. The app talks to a city backend, and that backend makes the synchronous Bedrock call with proper server credentials.
Full Explanation
Synchronous Bedrock API calls for interactive 311 on a city mobile app should originate from a trusted backend service that holds IAM credentials, not from residents’ phones. The mobile client calls the city’s API; the backend performs the synchronous foundation-model invocation and returns the answer. That pattern keeps long-lived Bedrock credentials off devices, enables server-side Guardrails and logging, and centralizes rate limits for civic traffic. Embedding IAM user access keys in the mobile app binary and calling Bedrock directly from the device fails secret protection—binaries are extractable and keys spread with every install. Shipping a hard-coded bearer token in the app’s resource bundle for Bedrock Runtime fails the same way: static tokens in clients leak and cannot be scoped per session safely. Opening an anonymous public Bedrock proxy on the internet with no authentication fails abuse control and would let the world burn the city’s FM budget and data path. Exam caveat: the backend still needs tight IAM, input validation, and per-user auth from the mobile session. Synchronous UX implies timeouts and loading states; for longer jobs prefer async patterns (see batch summarization questions). Do not confuse “synchronous invoke” with “invoke from the phone.” Operational check: Confirm the mobile app only calls the city backend; verify Bedrock credentials exist solely on server roles; enforce end-user authentication before invoke; log and throttle per user; and run a secret scan of the mobile bundle to prove no FM keys or tokens are present.