A county records-management system holds both public deed records and restricted probate files. How should the clerk's office configure the data connection so the agent only surfaces the public subset to residents?
Select an answer to reveal the explanation.
Short Explanation
You wouldn't trust a locked filing cabinet's contents to a sticky note that just says "don't open the probate drawer" — the access control needs to live at the connection itself. A scoped data-source connection limits what the agent can even query in the first place, keeping the restricted files out of reach structurally.
Full Explanation
A scoped data-source connection enforces access limits at the connection layer, restricting which records the agent can query at all, which is the reliable way to keep restricted probate files out of reach while still surfacing public deed records to residents. Ingesting both record types together and relying on a system instruction to filter output puts the restricted files within the agent's reach and depends entirely on the model's behavior holding under every phrasing, which is a much weaker guarantee than the connection simply never returning that data. A no-match event handler that blocks any question mentioning probate is easily sidestepped by rephrasing and, worse, would also block legitimate questions that happen to reference probate in a permitted context, without addressing the actual access boundary. Few-shot examples showing the agent declining probate questions shape conversational tone but don't prevent the underlying data from being queried or surfaced if the behavioral guardrail fails on some unanticipated phrasing. Scope caveat: the scoping configuration should be reviewed whenever the records-management system's classification of what's public versus restricted changes. Operational check: attempt to query a probate-specific detail through the resident-facing agent and confirm the connection itself returns nothing rather than the model merely refusing to answer.