Only the data its task needs, cut by dataset, record and field. Read only access stops edits but not exposure, and a model can pass what it reads to any tool that sends. Start from the task, grant the smallest slice, and mask fields the task does not use.
Why read scope matters
A read tool returns data into the model's context. From there, the data can appear in a message, a log, a ticket or an outbound request. OWASP's guidance recommends executing extensions in the user's context with minimal privileges, so that an agent sees only what the requesting user could see. That alone removes a common failure: a shared service account that can read everything.
Ways to narrow a read
| Dimension | Broad | Narrow |
|---|---|---|
| Dataset | Whole database | Named tables or one queue |
| Records | All customers | The caller's own or assigned records |
| Fields | Full row | Only needed columns, sensitive ones masked |
| Time | All history | Recent window |
| Purpose | General | One named task |
Steps to scope a read tool
- Write the task in one sentence and list the fields it truly needs.
- Create a downstream account or view that exposes only those fields and records.
- Point the tool at that view, not the base tables.
- Where possible, pass the end user's identity through so the downstream system applies its own rules.
- Strip or tokenize identifiers the task does not need, such as full account numbers.
- Test with a request for another user's record and confirm it fails.
Watch the exits
Pair sensitive read tools with limits on what can leave. If an agent reads customer records, check what send tools it holds and limit recipients and volume. Treat the combination as the risk, not each tool alone.
Logging reads
Log which records were read and by which agent. Keep the data itself out of logs. Reads of sensitive data are often what an investigation needs to reconstruct.
Retrieval and untrusted text
If the agent reads content written by outsiders, such as emails or web pages, it may be told to use its read access in unintended ways. That raises the importance of narrow scope: an agent that cannot see the data cannot leak it.
Safeguard offers MCP Guardrail and agent identity for applying this kind of policy to agent tool calls, and you can run a free scan of your own repositories at gold.safeguard.sh/scan. Autonomous fix pull requests are off by default, and every category starts on Manual.
Quick check
Is a read only database account enough?
It prevents edits, but not exposure. Limit tables, rows and fields too.
Should the agent use a shared account to read?
Prefer the user's own context or a narrow dedicated account. Shared broad accounts are a common over grant.
Sources
Last reviewed: 19 October 2026.
