311 architecture allows the model to write directly to the case-management database through ORM tools. How should write paths be constrained?
Select an answer to reveal the explanation.
Short Explanation
Handing the chatbot an ORM with a blank check is like giving a helpful intern the master filing cabinet key. Mediate writes through skinny APIs with auth and approvals. Direct DB pens turn a typo or injection into a case-system incident.
Full Explanation
Allowing a 311 GenAI model to write directly to the case-management database through ORM tools grants excessive privilege and amplifies prompt-injection or tool-abuse impact into case integrity. Write paths should be mediated through constrained APIs that enforce authorization, schema validation, and human or policy approval appropriate to municipal casework—not open ORM access from the model runtime. Least privilege on mutations protects residents' cases when the agent is manipulated or simply wrong.
Giving the model full DBA privileges so it can optimize indexes mid-chat maximizes blast radius and conflates conversational tooling with database administration. Letting residents' prompts include raw SQL for transparency invites injection and wrongly treats transparency as a reason to weaken input validation. Disabling all auditing of database writes performed by GenAI tools removes the accountability trail required for civic case systems and incident response.
Exam caveat: tool-augmented agents need capability mediation; "the model has an ORM tool" is not an architecture approval for unrestricted database writes. Operational check: remove direct DB credentials from the 311 agent, expose only narrow mutation APIs with authZ and audit logs, require approval gates for sensitive case updates, and test that injected prompts cannot invent arbitrary SQL against case tables.