A parks mobile app embeds a WebView that posts prompts to an undocumented staging LLM endpoint. What architecture problem should security raise?
Select an answer to reveal the explanation.
Short Explanation
That hidden staging LLM in the parks app is a side door nobody put on the city map. Shadow endpoints skip logging, auth, and data rules that production earned. Kill it or graduate it into the governed path — do not leave residents talking to a ghost server.
Full Explanation
Undocumented staging or shadow GenAI endpoints embedded in a parks mobile WebView typically lack production-grade authentication, monitoring, data-handling agreements, and change control. Architecture governance should remove those endpoints or formally bring them under the approved civic GenAI platform so resident prompts do not bypass municipal controls. Shadow AI creates untracked data flows, unpredictable retention, and an incomplete threat model for parks services that believe traffic only hits governed APIs.
Staging endpoints always provide stronger encryption than production is false; staging is often weaker, shared, and less monitored than production. Undocumented endpoints are required for App Store review screenshots is incorrect—app stores do not require secret LLM backends for screenshots. WebViews cannot send prompts unless the user is a city employee is false; any resident with the installed app can post prompts to whatever URL the WebView embeds.
Exam caveat: "staging" in a shipped mobile binary is effectively a production data path for residents who use that build, regardless of the hostname. Operational check: inventory WebView URLs in the parks app, block or delete undocumented LLM endpoints, point the client only at governed municipal APIs, and confirm staging hosts are network-restricted and unreachable from public app traffic.