30 April 2025 / Applied AI / 8 chapters

Limit what the agent can read, at the source

From Deciding what a tool-using agent can read and change

Read-only access can still leak sensitive information. Unrestricted retrieval can also pull irrelevant instructions into the model's context. So I'd limit what can be queried, which fields come back and how much material goes into a single task.

Where you can, use task-scoped lookups instead of general search. If the case contains an approved account identifier, the tool can fetch that one account after checking the invoking user's relationship to it. Free-text search across every account gives the agent far more to discover, and a mistaken query does a lot more damage.

Row and tenant boundaries should be applied in the source system or a trusted gateway. Don't rely on the model to remember a tenant ID. The gateway can work out scope from the authenticated user and the task, then reject any conflicting identifier that turns up in the tool arguments.

Which fields come back matters just as much as which rows. A task that writes a response might need contact preference and case history, and have no use for bank details, identity documents or internal risk notes. I'd build a response object for that purpose instead of passing through the full record the source API returns.

Attachments need their own handling. File names can give information away, the contents can be large, and uploaded documents can contain instructions written to steer the agent. Check file type, size, malware controls, classification and whether the file is relevant to the task before you extract anything. Keep the attachment marked as untrusted source material, and never let its text be treated as a system instruction.

Set result limits and pagination rules as well. If a lookup comes back with hundreds of matches, the agent should stop and ask for a narrower identifier, not pick one from a truncated list. Make truncation explicit in the tool response, because if the interface presents a partial result as complete, the model has no way of knowing records are missing.

Log which source objects were read, but don't copy their full contents into the audit log. Object identifiers, field groups, query classification and the access decision are usually enough for a review, and you avoid creating yet another store of private data.

All articles