What Data Should an AI Agent Be Able to See?
How much access should an AI agent have?
An AI agent should have the least access that lets it finish its task, and no more. If an agent matches supplier invoices to purchase orders, it needs to read invoices and purchase orders. It does not need payroll, customer contact lists or the whole shared drive. Access that is wider than the task adds risk and adds nothing to the result.
This is the same rule you already apply to staff and contractors. The difference is that an agent works quickly and at volume, so a loose permission can be used far more often than a person would use it.
How do you decide what an agent may read?
Start from the task, not from the system. Write down each decision the agent makes and the facts it needs to make it. Then list the fields and records that hold those facts.
| Question to ask | Why it matters |
|---|---|
| What does the agent need to read to do this step? | Defines the minimum read access |
| Could a narrower view do the job? | A single field or a filtered view is safer than a whole table |
| Does the data include personal or confidential information? | Decides whether it should be masked or left out |
| How long does the agent need to keep it? | Decides retention and what the logs may store |
Where a narrow view will do, use it. A database view or an API call that returns only the needed fields is easier to defend than broad access with a promise to behave.
How do you decide what an agent may write?
Writing is where mistakes become costly, so treat it separately from reading. Give the agent write access only to the records its task changes, and prefer actions that can be undone. Payments, ledger postings, messages to customers and deletions should wait for a person to approve them. We describe how to place that approval step in where the approval step belongs in an AI agent.
What should stay out of reach?
Some data is better kept away from agents unless there is a clear reason and a clear owner.
- Credentials, keys and tokens belonging to people
- Personal data that the task does not use, such as identity numbers or health details
- Records subject to legal hold or special handling
- Systems the agent does not need to touch at all
If a task seems to need one of these, ask whether the task can be redesigned so it does not. If it cannot, record the reason, name the owner of the decision and review it on a schedule.
What happens to data that is sent to a model?
If the agent uses a model hosted by a provider, what it sends leaves your system for processing. Before you go live, find out in writing how the provider handles your inputs: whether they are stored, for how long, and whether they are used to train models. Choose terms that match your own obligations. Where laws such as India's Digital Personal Data Protection Act, 2023 or the GDPR apply to you, the principles of purpose limitation, data minimisation and defined retention apply to what the agent processes. Ask your legal adviser to confirm what they require in your case.
Reduce what you send. Mask or remove personal fields the model does not need, and send the relevant section of a document rather than the whole file.
How do you keep access under control over time?
Access granted at go-live tends to be forgotten. Build a routine instead.
- Use separate credentials for each agent. Then one agent can be switched off without affecting the others.
- Make credentials revocable. You should be able to remove an agent's access in minutes.
- Log every run. Record the input, the records read, the tools called, the output and who approved it.
- Review access on a schedule. Compare what each agent can reach with what it actually used, and remove the difference.
- Review again before each expansion. When an agent takes on a new task, treat it as a new access request.
Where can you learn more?
A shared access model across all your agents is the job of the AI operating layer, which keeps permissions, credentials and logging in one place. Our security page sets out how we handle data and access in our own work, and the FAQ answers common questions about data and errors. For general background on protecting application data, the main ThynkBlox blog has a guide to data security in modern applications.
If you want to check what your first agent would need to see before anything is built, the AI audit includes a data and systems readiness check. You can get in touch to discuss it.